HOW: Including native DLL in assembly?

  • Thread starter Thread starter Julie
  • Start date Start date
J

Julie

I'm currently working in a mixed mode project where the exe is C#, there is a
managed C++ (DLL) assembly, that in part, includes some calls into a native
(unmamanged) DLL.

I can build/link/run just fine, the question isn't about that.

What I'm after is, if I have another client that uses the C++ managed assembly,
I want the unmanaged DLL somehow to tag along. I've looked at /link in AL.exe,
and /assemblymodule, but either I'm not using it right, or it doesn't do what I
want.

Anyone have any experience w/ this? What I've had to resort to is manually
copying the unmanaged DLL where needed -- far from optimal.

Thanks
 
Julie said:
I'm currently working in a mixed mode project where the exe is C#, there is a
managed C++ (DLL) assembly, that in part, includes some calls into a native
(unmamanged) DLL.

I can build/link/run just fine, the question isn't about that.

What I'm after is, if I have another client that uses the C++ managed assembly,
I want the unmanaged DLL somehow to tag along. I've looked at /link in AL.exe,
and /assemblymodule, but either I'm not using it right, or it doesn't do what I
want.

Anyone have any experience w/ this? What I've had to resort to is manually
copying the unmanaged DLL where needed -- far from optimal.

Thanks
Click to expand...

No one has any comment on this?
 
Maybe you should clarify your questions, I tried to read it, but I still
don't know what you want to do.
If I understand this correctly, you want to link the dll into your
executable to become one executable?
 
Maybe you should clarify your questions, I tried to read it, but I still
don't know what you want to do.
If I understand this correctly, you want to link the dll into your
executable to become one executable?
Click to expand...

I'll elaborate on my specific problem:

I have a native DLL (call it 'tools.dll', exposing functions via dllexport, not
COM) that I've wrapped in a managed C++ assembly (call it 'mtools.dll').

Now, when I'm working elsewhere in the same (or different) solution on other
projects, and I include a reference in a C# project to mtools.dll, everything
compiles and builds fine, however, when I go to run the app, it fails because
the native tools.dll isn't located.

So, what is happening: when adding a mtools.dll reference to the C# project,
that dll is properly copied to the C# project output directory -- _but_ the
unmanaged tools.dll isn't. I must either manually copy over tools.dll to the
target folder, put it in some centralized location within the search path, or
create a post-build step to copy the tools.dll to the target folder.

None of these appeal to me as they are error prone, and very repetitive when
working with multiple projects/targets.

So, what I'm after: is there a way to 'bind' a native dll to a managed assembly
so that either: the native dll is embedded within the managed assembly dll; or
the native dll is automatically copied to the target whenever the wrapper
managed assembly is added as a reference.

It seems like there should be some way to do this, especially for mixed
mode/managed C++ (wrapper) projects.

?
 
Now I understand.

Wel I am encountering this same problem and is very anoying.
So far I have no simple sollution then to include a reference to that dll
even though my program does not use it directly but indirectly.
But this way I make sure that it is copied too.

One thing I discovered was that when you use a managed dll using MFC, and on
the target machine MFC is not installed, then you must put the mfc*.dll
files in the same folder as the managed dll that uses MFC. It does not
follow the .NET rules because MFC is not .NET code. Normally you can create
subfolders with the same name of the managed dll. This way you can have
different versions of managed dll's throughout your project.
 
Julie said:
I have a native DLL (call it 'tools.dll', exposing functions via dllexport, not
COM) that I've wrapped in a managed C++ assembly (call it 'mtools.dll').

Now, when I'm working elsewhere in the same (or different) solution on other
projects, and I include a reference in a C# project to mtools.dll, everything
compiles and builds fine, however, when I go to run the app, it fails because
the native tools.dll isn't located.

So, what is happening: when adding a mtools.dll reference to the C# project,
that dll is properly copied to the C# project output directory -- _but_ the
unmanaged tools.dll isn't. I must either manually copy over tools.dll to the
target folder, put it in some centralized location within the search path, or
create a post-build step to copy the tools.dll to the target folder.

None of these appeal to me as they are error prone, and very repetitive when
working with multiple projects/targets.

So, what I'm after: is there a way to 'bind' a native dll to a managed assembly
so that either: the native dll is embedded within the managed assembly dll; or
the native dll is automatically copied to the target whenever the wrapper
managed assembly is added as a reference.

It seems like there should be some way to do this, especially for mixed
mode/managed C++ (wrapper) projects.
Click to expand...

Yes, this is a problem in .Net. I am not aware of a "standard"
solution, mostly due to the requerement in .Net that you can have two
or more versions of the same dll active at any given time.

We faced this problem in our projects and the way I currently tackle
it is by using a common Binaries folder and then setting up all my
projects to output the final linked binaries to this folder.

So, because now the project executable and the dll are in the same
folder, and as each time I build the project, these bins get updated
automatically, we kind of have a solution that works all the time.

The one other option would be to include the path to your dll in your
PATH env variable...

-Vinayak
 
Back
Top