Accessing Unmanaged dll

[Guest]

I am running a client based application written in C#.

As part of the deveopment I am utilizing a set of dlls which is part of a
vendors application (not written in .Net). So I have written a managed
wrapper for the dll.

If the vendors dlls are put into the system32 folder the application works
fine, but I am going to be deploying this across a number of client systems
and copying code I don't own from the vedors application directory into the
system32 folder (as the vendors code may be updated) does not seem to be the
most sensible option, nor does copying the code into my applications
directory for the same reason.

The vendors code also accesses a proprietary database so any changes are
likely to be required by my application.

Is there any way of pointing to the vendors directory so that the dll's can
be picked up, without having to make an unsafe copy.

 

[Jamin Guy]

Why not put the dll in the same folder as your executable?

 

[Guest]

This would be a nice option but the problem is:

That the code is not owned by us.
The DLL has historically been backwardly compatible but can access a
differing underlying structure, which means a DLL copied into our directory
may be out of date and try to update a different structure.

 

[Richard Grimes [MVP]]

I am running a client based application written in C#.

As part of the deveopment I am utilizing a set of dlls which is part
of a vendors application (not written in .Net). So I have written a
managed wrapper for the dll.

If the vendors dlls are put into the system32 folder the application
works fine, but I am going to be deploying this across a number of
client systems and copying code I don't own from the vedors
application directory into the system32 folder (as the vendors code
may be updated) does not seem to be the most sensible option, nor
does copying the code into my applications directory for the same
reason.

The vendors code also accesses a proprietary database so any changes
are likely to be required by my application.

Is there any way of pointing to the vendors directory so that the
dll's can be picked up, without having to make an unsafe copy.

[DllImport] allows you to add a path, for example:

class TestClass
{
[DllImport("C:\\Vendor\\lib.dll")]
static extern void Test();
}

Of course, that hard codes the vendor's path in your assembly.

Richard

 

[Guest]

Thanks for that.

Unfortunately this is being provided to a commercial customer who may not be
so understanding about always using the same disk and path as I would, and as
I believe that the DLLImport is set at compile rather than runtime this could
not be changed.

Judging from the response to this issue it looks like my options are really
limited.

I am running a client based application written in C#.

As part of the deveopment I am utilizing a set of dlls which is part
of a vendors application (not written in .Net). So I have written a
managed wrapper for the dll.

If the vendors dlls are put into the system32 folder the application
works fine, but I am going to be deploying this across a number of
client systems and copying code I don't own from the vedors
application directory into the system32 folder (as the vendors code
may be updated) does not seem to be the most sensible option, nor
does copying the code into my applications directory for the same
reason.

The vendors code also accesses a proprietary database so any changes
are likely to be required by my application.

Is there any way of pointing to the vendors directory so that the
dll's can be picked up, without having to make an unsafe copy.

[DllImport] allows you to add a path, for example:

class TestClass
{
[DllImport("C:\\Vendor\\lib.dll")]
static extern void Test();
}

Of course, that hard codes the vendor's path in your assembly.

Richard