«

We've got a wierd failure happening on just one machine. One part of our
product uses a 3rd party search implementation (dtSearch). DtSearch has a
native core (dten600.dll), late-bound, and a managed wrapper
(dtSearchNetApi2.dll).

For reasons unknown our build and msi packaging process includes
dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
of assemblies that reference it, even though they are not used by all the
applications.

Recently we got an update for dtSearch, which a developer checked in. For
some reason I can't figure out, it cause the application as deployed by the
msi to bomb out on one specific machine with the error:

Exception message: Could not load file or assembly 'dtSearchNetApi2,
Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
dependencies. This application has failed to start because the application
configuration is incorrect. Reinstalling the application may fix this
problem. (Exception from HRESULT: 0x800736B1)

Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
application bin directory as dtSearchNetApi2.dll, even though our referencing
assemblies are not used by the app. The 1.0.3056.39769 version is the new
copy we just updated, and it's there.

I've used ildasm to get the managed dependencies on the new and old versions
of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
due to odd packaging the native dten600.dll has never been included but the
old dtSearchNetApi2.dll doesn't cause the app load failure.

I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
and old dtSearch. The machine in question has never had the msvc?80 dlls,
but again the old version never caused a load failure.

Depends on both new and old dtSearchNetApi2.dll complains about the missing
late-bound dll, but it hasn't caused a problem before.

I can't figure out why, on this one machine, either it can't find
dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
why it's just now complaining about not finding some dependencies where it
didn't before.

When an ASP.Net app starts up, does it sweep all the dlls in the /bin
directory and check for missing references, whether the app uses them or not?
Any tips at what I should look at next to figure out why it just started
happening and only on this one machine?

Thanks
Mark

when an asp.net application starts, all dll's in the bin folder are loaded.
most dll's have build references, so this dll's must be loaded. asp.net is
different than other apps, as it has limited search lists.

you shoudl enable fusion logs:

http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx


-- bruce (sqlwork.com)


"Mark" wrote:

> We've got a wierd failure happening on just one machine. One part of our
> product uses a 3rd party search implementation (dtSearch). DtSearch has a
> native core (dten600.dll), late-bound, and a managed wrapper
> (dtSearchNetApi2.dll).
>
> For reasons unknown our build and msi packaging process includes
> dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
> of assemblies that reference it, even though they are not used by all the
> applications.
>
> Recently we got an update for dtSearch, which a developer checked in. For
> some reason I can't figure out, it cause the application as deployed by the
> msi to bomb out on one specific machine with the error:
>
> Exception message: Could not load file or assembly 'dtSearchNetApi2,
> Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
> dependencies. This application has failed to start because the application
> configuration is incorrect. Reinstalling the application may fix this
> problem. (Exception from HRESULT: 0x800736B1)
>
> Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
> application bin directory as dtSearchNetApi2.dll, even though our referencing
> assemblies are not used by the app. The 1.0.3056.39769 version is the new
> copy we just updated, and it's there.
>
> I've used ildasm to get the managed dependencies on the new and old versions
> of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
> due to odd packaging the native dten600.dll has never been included but the
> old dtSearchNetApi2.dll doesn't cause the app load failure.
>
> I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
> msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
> and old dtSearch. The machine in question has never had the msvc?80 dlls,
> but again the old version never caused a load failure.
>
> Depends on both new and old dtSearchNetApi2.dll complains about the missing
> late-bound dll, but it hasn't caused a problem before.
>
> I can't figure out why, on this one machine, either it can't find
> dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
> why it's just now complaining about not finding some dependencies where it
> didn't before.
>
> When an ASP.Net app starts up, does it sweep all the dlls in the /bin
> directory and check for missing references, whether the app uses them or not?
> Any tips at what I should look at next to figure out why it just started
> happening and only on this one machine?
>
> Thanks
> Mark
>

Thanks Bruce... We'll give that a try. Hopefully that will turn something up.

By the by, when do native DllImports() get resolved? When the assembly is
loaded or when some code path need it?

By the other by, I ran into something apparently a number of people have -
running dumpbin.exe doesn't work initially; it needs msvcp80.dll. But if you
copy msvcp80.dll from one of the other VS8 directories into VC\bin,
dumpbin.exe will run but basically everything else craps out after that (IIS
crashes, VS won't build anything, etc). What's up with that?

Thanks
Mark

"bruce barker" wrote:

> when an asp.net application starts, all dll's in the bin folder are loaded.
> most dll's have build references, so this dll's must be loaded. asp.net is
> different than other apps, as it has limited search lists.
>
> you shoudl enable fusion logs:
>
> http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
>
>
> -- bruce (sqlwork.com)
>
>
> "Mark" wrote:
>
> > We've got a wierd failure happening on just one machine. One part of our
> > product uses a 3rd party search implementation (dtSearch). DtSearch has a
> > native core (dten600.dll), late-bound, and a managed wrapper
> > (dtSearchNetApi2.dll).
> >
> > For reasons unknown our build and msi packaging process includes
> > dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
> > of assemblies that reference it, even though they are not used by all the
> > applications.
> >
> > Recently we got an update for dtSearch, which a developer checked in. For
> > some reason I can't figure out, it cause the application as deployed by the
> > msi to bomb out on one specific machine with the error:
> >
> > Exception message: Could not load file or assembly 'dtSearchNetApi2,
> > Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
> > dependencies. This application has failed to start because the application
> > configuration is incorrect. Reinstalling the application may fix this
> > problem. (Exception from HRESULT: 0x800736B1)
> >
> > Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
> > application bin directory as dtSearchNetApi2.dll, even though our referencing
> > assemblies are not used by the app. The 1.0.3056.39769 version is the new
> > copy we just updated, and it's there.
> >
> > I've used ildasm to get the managed dependencies on the new and old versions
> > of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
> > due to odd packaging the native dten600.dll has never been included but the
> > old dtSearchNetApi2.dll doesn't cause the app load failure.
> >
> > I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
> > msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
> > and old dtSearch. The machine in question has never had the msvc?80 dlls,
> > but again the old version never caused a load failure.
> >
> > Depends on both new and old dtSearchNetApi2.dll complains about the missing
> > late-bound dll, but it hasn't caused a problem before.
> >
> > I can't figure out why, on this one machine, either it can't find
> > dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
> > why it's just now complaining about not finding some dependencies where it
> > didn't before.
> >
> > When an ASP.Net app starts up, does it sweep all the dlls in the /bin
> > directory and check for missing references, whether the app uses them or not?
> > Any tips at what I should look at next to figure out why it just started
> > happening and only on this one machine?
> >
> > Thanks
> > Mark
> >

Hi Bruce...

Well, I gave it a try but unfortunately the fusion logs didn't show
anything. I see a bunch of assembly load logs for application 3e70de80
(presumably the name for the app pool). The fusion log for
dtSearchNetApi2.dll says the load was successful; all the assembly loads show
as successful. But then the web page itself blows up saying that
dtSearchNetApi2.dll failed to load.

The test page doesn't reference the assembly at all, so there's not any code
being exercised.

I've never had much luck with Fusion logs; haven't found any useful
information in them.

I did try swapping a bunch of other assemblies in and out of the \bin
directory. It's definitely the dtSearchNetApi2.dll that IIS isn't liking,
but no clue as to why.

Not sure where to look from here.

Thanks
Mark

"bruce barker" wrote:

> when an asp.net application starts, all dll's in the bin folder are loaded.
> most dll's have build references, so this dll's must be loaded. asp.net is
> different than other apps, as it has limited search lists.
>
> you shoudl enable fusion logs:
>
> http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
>
>
> -- bruce (sqlwork.com)
>
>
> "Mark" wrote:
>
> > We've got a wierd failure happening on just one machine. One part of our
> > product uses a 3rd party search implementation (dtSearch). DtSearch has a
> > native core (dten600.dll), late-bound, and a managed wrapper
> > (dtSearchNetApi2.dll).
> >
> > For reasons unknown our build and msi packaging process includes
> > dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
> > of assemblies that reference it, even though they are not used by all the
> > applications.
> >
> > Recently we got an update for dtSearch, which a developer checked in. For
> > some reason I can't figure out, it cause the application as deployed by the
> > msi to bomb out on one specific machine with the error:
> >
> > Exception message: Could not load file or assembly 'dtSearchNetApi2,
> > Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
> > dependencies. This application has failed to start because the application
> > configuration is incorrect. Reinstalling the application may fix this
> > problem. (Exception from HRESULT: 0x800736B1)
> >
> > Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
> > application bin directory as dtSearchNetApi2.dll, even though our referencing
> > assemblies are not used by the app. The 1.0.3056.39769 version is the new
> > copy we just updated, and it's there.
> >
> > I've used ildasm to get the managed dependencies on the new and old versions
> > of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
> > due to odd packaging the native dten600.dll has never been included but the
> > old dtSearchNetApi2.dll doesn't cause the app load failure.
> >
> > I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
> > msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
> > and old dtSearch. The machine in question has never had the msvc?80 dlls,
> > but again the old version never caused a load failure.
> >
> > Depends on both new and old dtSearchNetApi2.dll complains about the missing
> > late-bound dll, but it hasn't caused a problem before.
> >
> > I can't figure out why, on this one machine, either it can't find
> > dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
> > why it's just now complaining about not finding some dependencies where it
> > didn't before.
> >
> > When an ASP.Net app starts up, does it sweep all the dlls in the /bin
> > directory and check for missing references, whether the app uses them or not?
> > Any tips at what I should look at next to figure out why it just started
> > happening and only on this one machine?
> >
> > Thanks
> > Mark
> >

PS - I'm guessing that Depends is not side-by-side component aware, is that
true? On machines where it's working and the one where it's not, a number of
the native dependencies (msvcp80.dll for example) only exists under winsxs.

Presumably the binding is getting served from there, but Depends doesn't
seem to see those when it's reporting missing dlls...

Thanks
Mark


"bruce barker" wrote:

> when an asp.net application starts, all dll's in the bin folder are loaded.
> most dll's have build references, so this dll's must be loaded. asp.net is
> different than other apps, as it has limited search lists.
>
> you shoudl enable fusion logs:
>
> http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
>
>
> -- bruce (sqlwork.com)
>
>
> "Mark" wrote:
>
> > We've got a wierd failure happening on just one machine. One part of our
> > product uses a 3rd party search implementation (dtSearch). DtSearch has a
> > native core (dten600.dll), late-bound, and a managed wrapper
> > (dtSearchNetApi2.dll).
> >
> > For reasons unknown our build and msi packaging process includes
> > dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a couple
> > of assemblies that reference it, even though they are not used by all the
> > applications.
> >
> > Recently we got an update for dtSearch, which a developer checked in. For
> > some reason I can't figure out, it cause the application as deployed by the
> > msi to bomb out on one specific machine with the error:
> >
> > Exception message: Could not load file or assembly 'dtSearchNetApi2,
> > Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one of its
> > dependencies. This application has failed to start because the application
> > configuration is incorrect. Reinstalling the application may fix this
> > problem. (Exception from HRESULT: 0x800736B1)
> >
> > Our assemblies that reference dtSearchNetApi2.dll are in the same ASP.Net
> > application bin directory as dtSearchNetApi2.dll, even though our referencing
> > assemblies are not used by the app. The 1.0.3056.39769 version is the new
> > copy we just updated, and it's there.
> >
> > I've used ildasm to get the managed dependencies on the new and old versions
> > of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I said,
> > due to odd packaging the native dten600.dll has never been included but the
> > old dtSearchNetApi2.dll doesn't cause the app load failure.
> >
> > I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
> > msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for new
> > and old dtSearch. The machine in question has never had the msvc?80 dlls,
> > but again the old version never caused a load failure.
> >
> > Depends on both new and old dtSearchNetApi2.dll complains about the missing
> > late-bound dll, but it hasn't caused a problem before.
> >
> > I can't figure out why, on this one machine, either it can't find
> > dtSearchNetApi2.dll in the same dir (even though the app doesn't use it) or
> > why it's just now complaining about not finding some dependencies where it
> > didn't before.
> >
> > When an ASP.Net app starts up, does it sweep all the dlls in the /bin
> > directory and check for missing references, whether the app uses them or not?
> > Any tips at what I should look at next to figure out why it just started
> > happening and only on this one machine?
> >
> > Thanks
> > Mark
> >

Hi Mark,

For .NET web application, all the managed referenced assemblies are
expected to be in private bin dir (or GAC if strong-named). If you have use
PINVOKE to call some unmanaged dll, those dlls are expected to reside in
the same directory with the managed assembly that call it, or it can be put
in the global system32 folder.

For the fusion log bruce mentiond, it is used to trace how .net runtime
locate managed assembly, if there is problem with loading the unmanaged
dlls, fusion log won't be able to capture them. If you have run fusion log
and it displayed all the managed assembly loaded correctly, then, the
problem is likely occurinsg when loading the unmanaged one, have you tried
putting the unmanaged dll into system32 folder to see whether it can be
correctly loaded?

Here is a blog entry which also mentioned that such error is generally due
to some linked dependency of the existing reference that are not found or
if the path is not correct.

https://blogs.msdn.com/eldar/archive...07/621501.aspx


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:
.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
>From: =?Utf-8?B?TWFyaw==?= <>
>References: <C63A994A-6FAB-41F8-AA0D->
<B16EAD5D-C283-483B-8C6C->
>Subject: RE: bizarre asp.net app loading failure
>Date: Wed, 11 Jun 2008 14:46:01 -0700

>
>PS - I'm guessing that Depends is not side-by-side component aware, is
that
>true? On machines where it's working and the one where it's not, a number
of
>the native dependencies (msvcp80.dll for example) only exists under winsxs.
>
>Presumably the binding is getting served from there, but Depends doesn't
>seem to see those when it's reporting missing dlls...
>
>Thanks
>Mark
>
>
>"bruce barker" wrote:
>
>> when an asp.net application starts, all dll's in the bin folder are
loaded.
>> most dll's have build references, so this dll's must be loaded. asp.net
is
>> different than other apps, as it has limited search lists.
>>
>> you shoudl enable fusion logs:
>>
>> http://msdn.microsoft.com/en-us/libr...c4(VS.80).aspx
>>
>>
>> -- bruce (sqlwork.com)
>>
>>
>> "Mark" wrote:
>>
>> > We've got a wierd failure happening on just one machine. One part of
our
>> > product uses a 3rd party search implementation (dtSearch). DtSearch
has a
>> > native core (dten600.dll), late-bound, and a managed wrapper
>> > (dtSearchNetApi2.dll).
>> >
>> > For reasons unknown our build and msi packaging process includes
>> > dtSearchNetApi2.dll but not dten600.dll in all packages, as well as a
couple
>> > of assemblies that reference it, even though they are not used by all
the
>> > applications.
>> >
>> > Recently we got an update for dtSearch, which a developer checked in.
For
>> > some reason I can't figure out, it cause the application as deployed
by the
>> > msi to bomb out on one specific machine with the error:
>> >
>> > Exception message: Could not load file or assembly
'dtSearchNetApi2,
>> > Version=1.0.3056.39769, Culture=neutral, PublicKeyToken=null' or one
of its
>> > dependencies. This application has failed to start because the
application
>> > configuration is incorrect. Reinstalling the application may fix this
>> > problem. (Exception from HRESULT: 0x800736B1)
>> >
>> > Our assemblies that reference dtSearchNetApi2.dll are in the same
ASP.Net
>> > application bin directory as dtSearchNetApi2.dll, even though our
referencing
>> > assemblies are not used by the app. The 1.0.3056.39769 version is the
new
>> > copy we just updated, and it's there.
>> >
>> > I've used ildasm to get the managed dependencies on the new and old
versions
>> > of dtSearchNetApi2.dll; they're all the same MS framework dlls. As I
said,
>> > due to odd packaging the native dten600.dll has never been included
but the
>> > old dtSearchNetApi2.dll doesn't cause the app load failure.
>> >
>> > I used dumpbin to get the rest of the dependencies (kernel32, msvcr80,
>> > msvcp80, msvcm80, advapi32, oleaut32, mscoree). They are the same for
new
>> > and old dtSearch. The machine in question has never had the msvc?80
dlls,
>> > but again the old version never caused a load failure.
>> >
>> > Depends on both new and old dtSearchNetApi2.dll complains about the
missing
>> > late-bound dll, but it hasn't caused a problem before.
>> >
>> > I can't figure out why, on this one machine, either it can't find
>> > dtSearchNetApi2.dll in the same dir (even though the app doesn't use
it) or
>> > why it's just now complaining about not finding some dependencies
where it
>> > didn't before.
>> >
>> > When an ASP.Net app starts up, does it sweep all the dlls in the /bin
>> > directory and check for missing references, whether the app uses them
or not?
>> > Any tips at what I should look at next to figure out why it just
started
>> > happening and only on this one machine?
>> >
>> > Thanks
>> > Mark
>> >
>

Thanks, Steven...

I'm not that familiar with how things are resolved into the winsxs
hierarchy. I understand it's kind of like the GAC for unmanaged code and
that multiple versions of a dll may be in there, but when the loader is
resolving a dll reference, is it now paying attention to the version linked
to? I'm used to the old dll hell where it picks up the first one it stumbles
over.

One of the things I noticed on this box that's not working is that it
doesn't have a lot of the newer versions of the msvc?80.dlls on it that the
other boxes do. I was wondering if the winsxs system was somehow resolving
versions too, that it might be a mismatch there as well.

The dtSearch unmanaged dll is not present on some machines where IIS is
working, so the only other unmanaged references I could think where having
problems would be the msvc?80.dlls.

Thanks
Mark


"Steven Cheng [MSFT]" wrote:

> Hi Mark,
>
> For .NET web application, all the managed referenced assemblies are
> expected to be in private bin dir (or GAC if strong-named). If you have use
> PINVOKE to call some unmanaged dll, those dlls are expected to reside in
> the same directory with the managed assembly that call it, or it can be put
> in the global system32 folder.
>
> For the fusion log bruce mentiond, it is used to trace how .net runtime
> locate managed assembly, if there is problem with loading the unmanaged
> dlls, fusion log won't be able to capture them. If you have run fusion log
> and it displayed all the managed assembly loaded correctly, then, the
> problem is likely occurinsg when loading the unmanaged one, have you tried
> putting the unmanaged dll into system32 folder to see whether it can be
> correctly loaded?
>
> Here is a blog entry which also mentioned that such error is generally due
> to some linked dependency of the existing reference that are not found or
> if the path is not correct.
>
> https://blogs.msdn.com/eldar/archive...07/621501.aspx

Hi Steven, Bruce...

Figured it out eventually. The problem was that the 3rdparty component was
dependent on newer versions of the CRT than we had on the machine. I wasn't
familiar with the winsxs pre-emption of the path search, so attempts to put
newer versions of dlls in the deploy directory weren't working.

I found a newer vcredist, installed it, and the problem went away.

thanks
Mark


"Steven Cheng [MSFT]" wrote:

> Hi Mark,
>
> For .NET web application, all the managed referenced assemblies are
> expected to be in private bin dir (or GAC if strong-named). If you have use
> PINVOKE to call some unmanaged dll, those dlls are expected to reside in
> the same directory with the managed assembly that call it, or it can be put
> in the global system32 folder.
>
> For the fusion log bruce mentiond, it is used to trace how .net runtime
> locate managed assembly, if there is problem with loading the unmanaged
> dlls, fusion log won't be able to capture them. If you have run fusion log
> and it displayed all the managed assembly loaded correctly, then, the
> problem is likely occurinsg when loading the unmanaged one, have you tried
> putting the unmanaged dll into system32 folder to see whether it can be
> correctly loaded?
>
> Here is a blog entry which also mentioned that such error is generally due
> to some linked dependency of the existing reference that are not found or
> if the path is not correct.
>
> https://blogs.msdn.com/eldar/archive...07/621501.aspx
>
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead

Thanks for your followup Mark,

I'm glad that you've figured out the issue. So after installing the newer
version of the vc runtime, the side by side system is able to find the
expected version.

BTW, yes, currently windows OS is adding more support for unmanaged dll to
leverage side by side deployment so as to avoid dll hell. And for the
latest visual studio, its unmanaged C++ project will also generate binary
output that add such support(different from old version's outputs). Here
are some articles which may also be helpful:

#Side-by-side Assemblies
http://msdn.microsoft.com/en-us/library/aa376307.aspx

#Why does VC8 install libraries to WinSxS?
http://blogs.msdn.com/martynl/archiv...13/480880.aspx

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:
.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------

>Subject: RE: bizarre asp.net app loading failure
>Date: Thu, 12 Jun 2008 08:20:00 -0700

>
>Hi Steven, Bruce...
>
>Figured it out eventually. The problem was that the 3rdparty component
was
>dependent on newer versions of the CRT than we had on the machine. I
wasn't
>familiar with the winsxs pre-emption of the path search, so attempts to
put
>newer versions of dlls in the deploy directory weren't working.
>
>I found a newer vcredist, installed it, and the problem went away.
>
>thanks
>Mark
>
>
>"Steven Cheng [MSFT]" wrote:
>
>> Hi Mark,
>>
>> For .NET web application, all the managed referenced assemblies are
>> expected to be in private bin dir (or GAC if strong-named). If you have
use
>> PINVOKE to call some unmanaged dll, those dlls are expected to reside in
>> the same directory with the managed assembly that call it, or it can be
put
>> in the global system32 folder.
>>
>> For the fusion log bruce mentiond, it is used to trace how .net runtime
>> locate managed assembly, if there is problem with loading the unmanaged
>> dlls, fusion log won't be able to capture them. If you have run fusion
log
>> and it displayed all the managed assembly loaded correctly, then, the
>> problem is likely occurinsg when loading the unmanaged one, have you
tried
>> putting the unmanaged dll into system32 folder to see whether it can be
>> correctly loaded?
>>
>> Here is a blog entry which also mentioned that such error is generally
due
>> to some linked dependency of the existing reference that are not found
or
>> if the path is not correct.
>>
>> https://blogs.msdn.com/eldar/archive...07/621501.aspx
>>
>>
>> Sincerely,
>>
>> Steven Cheng
>>
>> Microsoft MSDN Online Support Lead
>
>