I have an asp.net application (C#) that calls a web service that uses
several c++ dlls which are loaded with DllImport. I put these dlls in a
sub-directory off of the bin directory. For example, lets say the web
service dlls reside in c:\<myservice path>. The imported dlls are in
c:\<myservice path>\importeddlls. Therefore, the DllIImport declaration
looks like this:
[DllImport(@"importeddlls\import1.dll", EntryPont="functionName")]

This is working fine for production. But when I try to debug, it can't find
the dll. I did notice that the executing assembly location would be like:
c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files\myservicevdir\7e128e00\3fa09952\assembly\dl3\48f477a3\2aa7278e_0628c901\import1.DLL

If it is looking there for the sub directory importeddlls, it won't find it
which would explain the error. If this is the case, how do I get it to find
the dll? I'm sure that I've done this previously when I've attached to a
service on a remote machine and I'm pretty sure that I've done it with the
service on my own machine, but now something has changed it the dll's can't
be found. I might have just changed a setting that messed it up, but not
sure.

Any ideas?

Hi Larry,

From your description, I understand that one of your ASP.NET webservice
application use some managed and unmanaged dlls(managed assembly use
unmanged ones for PINVOKE). However, at debugging time, the application
will report error that cannot load the unmanaged dll, correct?

Based on my experience, this is a common issues which is caused by the
shadow copy feature of .net application. While the ASP.NET application will
always shadow copy managed asembly to temporary folder(but not for the
unmanaged dlls).

And there used to be many other guys reporting the same issue(even when
running the application without debugging) which use managed and unmanaged
dlls together.

So far there are several means which can help resolve the unmanaged dll's
probing/locating issue:


#- Pre-load the native dll using LoadLibrary (make an early call to
LoadLibrary([full path to the DLL]), so that the DLL is already correctly
loaded later when it is needed.

http://blogs.msdn.com/junfeng/archiv...14/181932.aspx
http://blogs.msdn.com/junfeng/archiv...20/599434.aspx)

this will require us to change code.


#Disable shadow copying (<hostingEnvironment shadowCopyBinAssemblies="false
/>), so the assembly runs directly from bin (with the obvious rawback that
it's locked until the app shuts down)


#Put the assembly somewhere on the system PATH (environment variable) such
as system32 folder. Or you can manually add your own folder(contains those
unamanged dlls ) to the PATH environment variable.


and here is a web forum thread discussing on the similar issue:

http://forums.asp.net/p/939729/1121085.aspx#1121085


Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(E-Mail Removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subs...#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/...tance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
>From: "Larry" <(E-Mail Removed)>
>Subject: asp.net and dllimport
>Date: Mon, 6 Oct 2008 22:26:14 -0600

>
>I have an asp.net application (C#) that calls a web service that uses
>several c++ dlls which are loaded with DllImport. I put these dlls in a
>sub-directory off of the bin directory. For example, lets say the web
>service dlls reside in c:\<myservice path>. The imported dlls are in
>c:\<myservice path>\importeddlls. Therefore, the DllIImport declaration
>looks like this:
>[DllImport(@"importeddlls\import1.dll", EntryPont="functionName")]
>
>This is working fine for production. But when I try to debug, it can't
find
>the dll. I did notice that the executing assembly location would be like:
>c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
>Files\myservicevdir\7e128e00\3fa09952\assembly\dl3\48f477a3\2aa7278e_0628c9
01\import1.DLL
>
>If it is looking there for the sub directory importeddlls, it won't find
it
>which would explain the error. If this is the case, how do I get it to
find
>the dll? I'm sure that I've done this previously when I've attached to a
>service on a remote machine and I'm pretty sure that I've done it with the
>service on my own machine, but now something has changed it the dll's
can't
>be found. I might have just changed a setting that messed it up, but not
>sure.
>
>Any ideas?
>
>
>