Thank you for responding.
The code using dtSearchNetApi2.dll is all managed code, compiled Any CPU.
Our code is used in a variety of different applications. Some of it gets
registered with COM interop, some is in ASP.Net .aspx pages, some parts are
in web services.
Specifically my problem building release is that the Visual Studio tasks are
sgen.exe fails because the webservice dll can't load dtSearchNetApi2.dll
(works in Debug because sgen isn't run).
We have a project with a post-build event to run regasm on the dlls exposing
COM interop, and in Release build regasm also fails trying to load
dtSearchNetApi2.dll. Interestingly, it works in Debug builds.
I tried using sxstrace while doing a build, but nothing showed up in the log
pertinent to this issue.
Using Reflector and Corflags, I determined that
1) The dtSearchNetApi2.dll I'm using is built for x64
2) The only unmanaged dependency in Reflector is MSVCR80.dll In my sxs
directory, I have 5 different x64 versions of this dll.
I don't have separate Release and Debug builds for dtSearchNetApi2.dll; I'm
using the same .dll in both builds. I don't know why regasm can load it in
the Debug build but not in the Release build.
""Jialiang Ge [MSFT]"" wrote:
> Is your host application (the applicaiton that loads the
> dtSearchNetApi2.dll) a managed application or an unmanaged application?
> When you say that you build in Debug|x64, are you building the host
> application? Does dtSearchNetApi2.dll target ANY CPU?
> I propose to first locate the dll that failed to be loaded. I list my
> frequently used skills below. Please try them.
> 1. sxstrace
> This only works for sxs binding failures.
> SxsTrace Trace -logfile:SxsTrace.etl
> SxsTrace Parse -logfile:SxsTrace.etl -outfile:SxsTrace.txt
> 2. dependency walker
> This only works for native modules. It has a very powerful function
> "Profile" that can trace the loading process and tell you if there's any
> errors. It can also check statically the dependencies of the application.
> Please try it in your application. It may not work for you.
> 3. Fusion event log
> This only works for .NET assembly binding process.
> 4. Procmon log
> Use this to trace the file system behaviors of your applicaiton. You can
> see from its log that your application loads different dlls. When you
> received the error, find in the log the last dll your applicaiton attempts
> to load.
> 5. windbg
> Use windbg to debug your application load process. This will definitely
> work for you, but it requires some debugging knowledge.
> Jialiang Ge
> Microsoft Online Community Support
> This posting is provided "AS IS" with no warranties, and confers no rights.