Calling VB.net from C++

In the past I have used VB 6 programs that I called from VS 2003 C++
by using the #import "Mydll.dll" no_namespace in my c++ program

I had the dll located in the c++ project where the c++ program
resided. This works for me.

However I can not seem to do this for a VB.net program

Here is my code

// VBCallfromC.cpp : Defines the entry point for the DLL application.


#include "stdafx.h"
//#include "iostream.h"
#include <comdef.h>


#import "VbCalendar.dll" no_namespace


clsclsVbcalPtr ptrclsVbcal(__uuidof(clsVbcal));

SAFEARRAY FAR* RTNGArray = NULL;

When I compile this I get the following message

fatal error C1083: Cannot open type library file: 'c:\testtheory
\vbcallfromc\vbcallfromc\vbcalendar.dll': Error loading type library/
DLL.

The dll is in that directory

The 2005 VB.net program is a com interop program and is registered
automatically when I compile the dll. I tried my calling code in VS c
+
+ 2003 and in VS c++ 2005 and nether compiles. I also tried playing
around with the around with the CLS but no luck. Any ideas?

thanks
Josh

Igor
Thu Oct 09 08:36:53 CDT 2008

"joshturner1967" <joshturner1967@gmail.com> wrote in message
news:a322ac59-3142-4960-a91a-e740c65aaf4d@25g2000prz.googlegroups.com
> In the past I have used VB 6 programs that I called from VS 2003 C++
> by using the #import "Mydll.dll" no_namespace in my c++ program
>
> I had the dll located in the c++ project where the c++ program
> resided. This works for me.
>
> However I can not seem to do this for a VB.net program

What you do is register your .NET assembly as a COM server. See

http://msdn.microsoft.com/en-us/library/zsfww439.aspx

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

joshturner1967
Thu Oct 09 09:39:21 CDT 2008

On Oct 9, 9:36=A0am, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> "joshturner1967" <joshturner1...@gmail.com> wrote in message
>
> news:a322ac59-3142-4960-a91a-e740c65aaf4d@25g2000prz.googlegroups.com
>
> > In the past I have used VB 6 programs that I called from VS 2003 C++
> > by using the #import "Mydll.dll" no_namespace in my c++ program
>
> > I had the dll located in the c++ project where the c++ program
> > resided. =A0This works for me.
>
> > However I can not seem to do this for a VB.net program
>
> What you do is register your .NET assembly as a COM server. See
>
> http://msdn.microsoft.com/en-us/library/zsfww439.aspx
>
> --
> With best wishes,
> =A0 =A0 Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925

Hello Igor thanks for your reply

I tried letting the compiler do it and by doing that it allowed me to
do com calls to it through a legacy system com call process - This
does nothing fancy other than make normal com calls based upon your
input

I also tried Regasm.exe but that did not do anything either. In fact
I first tried it on the location of the compiled dll and then put the
fully qualified path into the #import statement - I know something
that is not really a good idea - but I did it as a test - and that did
not work - same error message

I then tried to do a Regasm.exe on the dll that was put into the
project directory - so that I would only have to put the #import
statement with the name and type of the dll ie #import
"VbCalendar.dll" no_namespace - However that did not work either

In both situations I ended up with the same error C1083 - so I am
confussed and must be missing something.

any more ideas would be helpful

Thanks again Josh

Igor
Thu Oct 09 12:54:01 CDT 2008

joshturner1967 <joshturner1967@gmail.com> wrote:
> On Oct 9, 9:36 am, "Igor Tandetnik" <itandet...@mvps.org> wrote:
>> What you do is register your .NET assembly as a COM server. See
>>
>> http://msdn.microsoft.com/en-us/library/zsfww439.aspx
>
> I tried letting the compiler do it

Letting which compiler do what?

> and by doing that it allowed me to
> do com calls to it through a legacy system com call process - This
> does nothing fancy other than make normal com calls based upon your
> input

Are there "abnormal" COM calls, as opposed to normal ones? What else
besides "making normal COM calls" do you expect to be able to do?

> I also tried Regasm.exe but that did not do anything either.

What did you expect it to do, and in what respects did it fail to meet
your expectations?

> In fact
> I first tried it on the location of the compiled dll and then put the
> fully qualified path into the #import statement

You don't #import a .NET DLL. You use TlbExp tool to generate a type
library from said DLL, and #import that.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

joshturner1967
Thu Oct 09 17:30:04 CDT 2008

On Oct 9, 1:54=A0pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> joshturner1967 <joshturner1...@gmail.com> wrote:
> > On Oct 9, 9:36 am, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> >> What you do is register your .NET assembly as a COM server. See
>
> >>http://msdn.microsoft.com/en-us/library/zsfww439.aspx
>
> > I tried letting the compiler do it
>
> Letting which compiler do what?
>
> > and by doing that it allowed me to
> > do com calls to it through a legacy system com call process - This
> > does nothing fancy other than make normal com calls based upon your
> > input
>
> Are there "abnormal" COM calls, as opposed to normal ones? What else
> besides "making normal COM calls" do you expect to be able to do?
>
> > I also tried Regasm.exe but that did not do anything either.
>
> What did you expect it to do, and in what respects did it fail to meet
> your expectations?
>
> > In fact
> > I first tried it on the location of the compiled dll and then put the
> > fully qualified path into the #import statement
>
> You don't #import a .NET DLL. You use TlbExp tool to generate a type
> library from said DLL, and #import that.
> --
> With best wishes,
> =A0 =A0 Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925


Well this is the line of code that ended up solving my issue as far as
compiling is concerned


#import "VbCalendar.tlb" no_namespace, auto_search,
rename("ReportEvent","VbCalReportEvent")

I put the tlb in the project directory and had to use auto_search and
rename to get rid of some compile errors and warnings

I guess I got confussed with the fact that I had to use the tlb
instead to of the dll. Like I said in non .Net versions I could use
the dll.

With the added issue of compile errors for the tlb it also threw me
off until I found out I needed to use additional #import attributes

Thanks for your help Igor

Josh

Igor
Thu Oct 09 17:45:27 CDT 2008

joshturner1967 <joshturner1967@gmail.com> wrote:
> I guess I got confussed with the fact that I had to use the tlb
> instead to of the dll. Like I said in non .Net versions I could use
> the dll.

You are still #importing a TLB, it's just embedded into that DLL as a
resource. You could do that with a .NET DLL too, if you are so inclined:

http://msdn.microsoft.com/en-us/library/ww9a897z.aspx

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

joshturner1967
Fri Oct 10 14:34:44 CDT 2008

On Oct 9, 6:45=A0pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> joshturner1967 <joshturner1...@gmail.com> wrote:
> > I guess I got confussed with the fact that I had to use the tlb
> > instead to of the dll. =A0Like I said in non .Net versions I could use
> > the dll.
>
> You are still #importing a TLB, it's just embedded into that DLL as a
> resource. You could do that with a .NET DLL too, if you are so inclined:
>
> http://msdn.microsoft.com/en-us/library/ww9a897z.aspx
>
> --
> With best wishes,
> =A0 =A0 Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925

Thanks again Igor

I do have one more question that has arisen from this process. I am
running into another issue now that I have created a c++ dll that is
unmanaged that calls the VB.net 2005 dll that is managed.

You see our legacy system is wrttten in in C and C++ within VS 2003
and what we do is make a call to LoadLibrary in one of the the 'C'
modules that looks similar to this

HMODULE hRetVal;

char *dllpath

hRetVal =3D LoadLibrary(dllpath);

The dll path is built internally but resovles to c:\myfile\Debug
\VBCallFromC.dll - the location of the c++ dll that is used to call
the VB.Net 2005 dll for the calendar. We do this so that we can use
smart pointers down the road within the 'C' programs

Anyway previously we have been able to do this with code that was
wrtten in VB6. I would suspect that maybe the problem is that the VB6
program was not a managed program and niether is the code that calls
it. However since the new VB.Net 2005 dll is written as managed and
the other code is not then I think that is my problem because I get
the following error message\crash when I try and run the hRetVal =3D
LoadLibrary(dllpath); line of code

DLL 'c:\myfile\Debug\VBCallFromC.dll' is attempting managed
execution inside OS Loader lock. Do not attempt to run managed
code inside a
DllMain or image initialization function since doing so can
cause the
application to hang.

From my research (http://msdn.microsoft.com/en-us/library/
aa290048.aspx#vcconmixeddllloadingproblemanchor6) it appears that
LoadLibary might not work properly or need work arounds in order to
work since the article claims LoadLibaray is specifically identified
as being unsafe inside a DllMain function under most circumstances

I have tried the using the \noentry switch in my properties\command
line \addtional properties section of my VBCallFromC.dll project -
This did not do anything

Do you know what I can do to get around this line of code? I am very
close to my proof of concept and just have this last hurdle to get
over.

Any suggestions would be appreciated

Thanks
Josh

Igor
Fri Oct 10 14:55:18 CDT 2008

joshturner1967 <joshturner1967@gmail.com> wrote:
> I do have one more question that has arisen from this process. I am
> running into another issue now that I have created a c++ dll that is
> unmanaged that calls the VB.net 2005 dll that is managed.

I'm not really an expert on these matters. You may want to direct
further questions to microsoft.public.dotnet.framework.interop

> You see our legacy system is wrttten in in C and C++ within VS 2003
> and what we do is make a call to LoadLibrary in one of the the 'C'
> modules that looks similar to this
>
> HMODULE hRetVal;
>
> char *dllpath
>
> hRetVal = LoadLibrary(dllpath);

I don't believe you can do this to a .NET DLL. What's that supposed to
achieve anyway?
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925

joshturner1967
Fri Oct 10 15:12:45 CDT 2008

On Oct 10, 3:55=A0pm, "Igor Tandetnik" <itandet...@mvps.org> wrote:
> joshturner1967 <joshturner1...@gmail.com> wrote:
> > I do have one more question that has arisen from this process. =A0I am
> > running into another issue now that I have created a c++ dll that is
> > unmanaged that calls the VB.net 2005 dll that is managed.
>
> I'm not really an expert on these matters. You may want to direct
> further questions to microsoft.public.dotnet.framework.interop
>
> > You see =A0our legacy system is wrttten in in C and C++ within VS 2003
> > and what we do is make a call to =A0LoadLibrary in one of the the 'C'
> > modules that looks similar to this
>
> > HMODULE hRetVal;
>
> > char *dllpath
>
> > hRetVal =A0=3D LoadLibrary(dllpath);
>
> I don't believe you can do this to a .NET DLL. What's that supposed to
> achieve anyway?
> --
> With best wishes,
> =A0 =A0 Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925

just wanted to keep options open for our customers until we got our
prodiuct completely written in .net - plus at the same time really try
and understand\practice with different methods for com dll's written
in .net You have been a big help thanks again Igor

Josh

Ben
Mon Oct 13 09:18:36 CDT 2008

Igor Tandetnik wrote:
> joshturner1967 <joshturner1967@gmail.com> wrote:
>> I do have one more question that has arisen from this process. I am
>> running into another issue now that I have created a c++ dll that is
>> unmanaged that calls the VB.net 2005 dll that is managed.
>
> I'm not really an expert on these matters. You may want to direct
> further questions to microsoft.public.dotnet.framework.interop
>
>> You see our legacy system is wrttten in in C and C++ within VS 2003
>> and what we do is make a call to LoadLibrary in one of the the 'C'
>> modules that looks similar to this
>>
>> HMODULE hRetVal;
>>
>> char *dllpath
>>
>> hRetVal = LoadLibrary(dllpath);
>
> I don't believe you can do this to a .NET DLL. What's that supposed to
> achieve anyway?

I think that line was loading a C++ wrapper DLL. That's all well and good,
but as mentioned you shouldn't make that LoadLibrary call or use any COM
objects (because that could require LoadLibrary) inside DllMain.