RE: bizarre asp.net app loading failure
- From: Mark <mmodrall@xxxxxxxxxxxxx>
- 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/library/e74a18c4(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
- Follow-Ups:
- RE: bizarre asp.net app loading failure
- From: Steven Cheng [MSFT]
- RE: bizarre asp.net app loading failure
- References:
- bizarre asp.net app loading failure
- From: Mark
- RE: bizarre asp.net app loading failure
- From: bruce barker
- bizarre asp.net app loading failure
- Prev by Date: RE: bizarre asp.net app loading failure
- Next by Date: Re: When browser is closed i want to call the web method of the we
- Previous by thread: RE: bizarre asp.net app loading failure
- Next by thread: RE: bizarre asp.net app loading failure
- Index(es):
Relevant Pages
|
Loading