I recently posted an observation regarding the absence of msvcr71.dll from the Microsoft .NET 2.0 framework install. This causes problems when take a .NET 1.1 assembly that has a dependency on the DLL and run it on the .NET 2.0 CLR.
Naturally when mitigating this problem you want to try to deploy the DLL privately to your application instead of the .NET framework directory on the System32 directory so that you avoid potential DLL hell. Unfortunately I found another piece of trivia regarding ASP.NET.
Let's say your deploying a webservice that includes an assembly like I previously described. ASP.NET doesn't use your webservice\bin folder as the application directory, it instead copies your assemblies to a temporary folder and uses it. But it gets interesting.... ASP.NET only copies MANAGED assemblies to the folder, it leaves unmanaged dll's behind. What this basically means is that you can't really mitigate the problem in a clean way. You have to deploy the unmanaged assembly (msvcr71.dll) to the System32 folder, [WindowsFolder]Microsoft.NET\Framework\v2.0.50727 folder or even worse, another folder which you append to the system path. Yuck.
Now of course it gets even more interesting. ASP.NET will copy *ALL* managed assemblies to the temporary folder whether you actually use them or not. Your web service assembly doesn't actually have to have references to the assemblies, ASP.NET just assumes that you might be using reflection and makes them all available to you. It's just if your assemblies have dependencies on unmanaged code.... well your out of luck there.
Fortunately when it was getting really dark and ugly the ASP.NET developer tells me... `Oh, we don't use that assembly anymore anyways`. So I dropped the offending assembly from the webservice\bin folder and sure enough, everything works as expected without actually having to deploy msvcr71.dll to the System32 folder!
No comments:
Post a Comment