bizarre asp.net app loading failure

Discussion in 'ASP .Net' started by Mark, Jun 11, 2008.

  1. Mark

    Mark Guest

    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
     
    Mark, Jun 11, 2008
    #1
    1. Advertising

  2. Mark

    bruce barker Guest

    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
    >
     
    bruce barker, Jun 11, 2008
    #2
    1. Advertising

  3. Mark

    Mark Guest

    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/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
    > >
     
    Mark, Jun 11, 2008
    #3
  4. Mark

    Mark Guest

    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/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
    > >
     
    Mark, Jun 11, 2008
    #4
  5. Mark

    Mark Guest

    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
    > >
     
    Mark, Jun 11, 2008
    #5
  6. 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/2006/06/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/subscriptions/managednewsgroups/default.aspx#notif
    ications.
    ==================================================
    This posting is provided "AS IS" with no warranties, and confers no rights.

    --------------------
    >From: =?Utf-8?B?TWFyaw==?= <>
    >References: <>

    <>
    >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/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
    >> >

    >
     
    Steven Cheng [MSFT], Jun 12, 2008
    #6
  7. Mark

    Mark Guest

    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/2006/06/07/621501.aspx
     
    Mark, Jun 12, 2008
    #7
  8. Mark

    Mark Guest

    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/2006/06/07/621501.aspx
    >
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
     
    Mark, Jun 12, 2008
    #8
  9. 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/archive/2005/10/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/subscriptions/managednewsgroups/default.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/2006/06/07/621501.aspx
    >>
    >>
    >> Sincerely,
    >>
    >> Steven Cheng
    >>
    >> Microsoft MSDN Online Support Lead

    >
    >
     
    Steven Cheng [MSFT], Jun 13, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Matthew Louden
    Replies:
    1
    Views:
    388
    steve
    Oct 11, 2003
  2. Ilias Lazaridis
    Replies:
    0
    Views:
    578
    Ilias Lazaridis
    Feb 1, 2005
  3. Replies:
    0
    Views:
    475
  4. Headless Rider

    Control asp.net app from other asp.net app

    Headless Rider, Aug 18, 2003, in forum: ASP .Net Security
    Replies:
    0
    Views:
    110
    Headless Rider
    Aug 18, 2003
  5. Somit Goyal via .NET 247

    Urgent- .Net 1.1 - Failure in loading a dll on another machine

    Somit Goyal via .NET 247, May 7, 2004, in forum: ASP .Net Security
    Replies:
    0
    Views:
    130
    Somit Goyal via .NET 247
    May 7, 2004
Loading...

Share This Page