DLL Troubles

  • Thread starter Thread starter Tom Andrecht
  • Start date Start date
T

Tom Andrecht

I'm trying to write two managed C++ .DLL files for use in a project, and am
running into some trouble that I'm not sure if it's something I'm doing
wrong (this is my first time trying this) or if it's something VS .NET 2k3
is doing to me. My problems are this:

1. The projects will not find standard functions like strcpy and new.
doesn't seem to even know what they are despite my having added the header
files for everything plus.

2. When I try to use these in my main project file (built in C#), it tells
me that my classes in the DLL's do not exist in my namespace and asks if I'm
missing an assembly reference. I know I have them referenced in the project
file, and the build order is such that both are compiled at the appropriate
times to ensure (theoretically) that everything that is depended on gets
compiled first, and in the case of my C# DLL projects, everything works
fine. Any ideas from anyone? Thanks

Tom
 
Short answer: Managed C++ DLLs don't work yet (as of Visual Studio 2003).

You probably don't believe this but, really, it's true.

Apparently, some people have done this but you have to:
1) Not link in any Managed libraries including the standard .NET
runtime which is basically impossible
2) Not link in any unmanaged libraries uncluding the standard C/C++
ryntime which is also basically impossible.
3) Deal with all kinds of bizarre errors since no static/global
variables work correctly. Even those used internally by unmanaged
libraries (including the runtime).

Visual Studio 2005 hopefully will have a better solution.
 
I don't have a lot of experience with this yet, but I experienced the same
thing. I got around it by just adding the library references for the
appropriate C/C++ runtime files. It seems that those are implicitly
available when compiling native, but have to be explicitly added just like
any other external libary when compiling managed.

They can be found (by default) under:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\lib
 
If you play around with compile/link settings for a while, you can get
an MC++ DLL project to build. The problem is, support for static/global
variables is broken.

Even if you don't use static/global variables directly, you probably
indirectly use some standard library functionality that does and that
will now be unstable and often crash.

http://www.codeguru.com/columns/Kate/article.php/c3643/
 
Tommy Vercetti said:
If you play around with compile/link settings for a while, you can get an
MC++ DLL project to build. The problem is, support for static/global
variables is broken.

Even if you don't use static/global variables directly, you probably
indirectly use some standard library functionality that does and that will
now be unstable and often crash.

http://www.codeguru.com/columns/Kate/article.php/c3643/
Click to expand...

Right. And Kate points her readers to the knowledge base article available
here:

http://support.microsoft.com/?id=814472

On the one hand I don't want to sound as though I am minimizing the problem
described there, but on the other I don't think that your characterization
of "unstable and often crash" is entirely correct, either.

The article points out that initializing the runtime and static variables
while processing the DLL_PROCESS_ATTACH notification IS a timebomb because
that is what happens by default.

However, it you mark the mixed-mode DLL as having no entry point then
prohibited actions do not take place while the loader lock is held when
loading the DLL. The article goes on to point out how to construct an
exported initializer function which clients can call _after_ having loaded
the DLL when it is safe.

Does that not tack work for you?

Regards,
Will
 
Back
Top