DEVPATH is failing when running web applications under .NET 4

DEVPATH is failing when running web applications under .NET 4 by Clive Tong

Closed

as Fixed

Type:	Bug
ID:	689691
Opened:	9/20/2011 3:05:52 AM
Access Restriction:	Public
Moderator Decision:	Sent to Engineering Team for consideration

Workaround(s)

view

User(s) can reproduce this bug

I reported this bug https://connect.microsoft.com/VisualStudio/feedback/details/686863/devpath-is-not-respected-by-net-4-when-running-web-applications#details

I set up a directory containing an assembly, set the DEVPATH variable to point to this directory, and change the machine.config to enable the developmentMode.

If I then run a winforms application that references the assembly, I can see from Debug/Windows/Modules that the CLR has loaded the version in the DEVPATH directory.

If I run a web application inside Visual Studio, then the version loaded is one from inside the ASP.NET temp directory. It appears as if the DEVPATH has been ignored.

If I target .NET 2, then the DEVPATH is respected in both cases, and the DEVPATH directory version of the assembly is loaded. It seems that it is not respected under .NET 4.

This bug is marked as resolved even though I received no notification that you needed more data. If you need more information please just email me to let me know.

Details (expand)

.NET Framework 4

We'll write a web app that references an external assembly called ABuggyLibrary.dll.
The steps correspond to the attached pictures.
Step1: set the DEVPATH variable to point to a directory on the machine
Step2: Place a copy of the assembly into this directory
Step3: Modify all of the machine configs (for all framework versions and 32/64)
Step4: to add the developmentMode element
Step5: write a simple web application that references the assembly (in a different location)
Step6: Run and notice that the assembly has been loaded from the ASP.net temporary directory. The webdev that is running is Webserver40.exe
Step7: Change to retarget the .NET 3.5 framework
Step8: Run and notice the WebServer20.exe is being used, and the DEVPATH redirection has caused the assembly to be loaded from the DEVPATH location.

English

Windows 7

English

DEVPATH location is not used for loading the assembly on .NET 4, but it is in .NET 2

DEVPATH lcoation used in both cases.

File Name	Submitted By	Submitted On	File Size
step1.png	Clive Tong	9/20/2011	90 KB
step2.png	Clive Tong	9/20/2011	99 KB
step3.png	Clive Tong	9/20/2011	133 KB
step4.png	Clive Tong	9/20/2011	167 KB
step5.png	Clive Tong	9/20/2011	194 KB
step6.png	Clive Tong	9/20/2011	218 KB
step7.png	Clive Tong	9/20/2011	205 KB
step8.png	Clive Tong	9/20/2011	222 KB

Our company produces a tool that takes an assembly which it will decompile to source (VB or C#) and also produce an associated pdb file - http://www.reflector.net/vspro/ The pdb can be picked up by Visual Studio and you can then debug the decompiled code much like your own.

Visual Studio matches the pdb against an assembly using the debug signatures in the assembly and the pdb. Unfortunately, not all assemblies have this section, so we need to modify the assembly to add it. In previous versions, we signed this modified assembly and then transitively rewrote all of the project's referenced assemblies to point to this new assembly. This was a little error prone (and didn't work with Reflection), so in the later versions of the tool we have moved to using the DEVPATH instead. DEVPATH allows us to put the modified assembly in a tool controlled directory and have it loaded instead of the original. The DEVPATH is treated as part of the trusted assembly store (GAC) so we do not need to worry about re-signing the assembly. Most conveniently for us, we do not need to modify the solution/projects in Visual Studio that are being debugged.

DEVPATH is a little too global, but has been working for us.

Alternatives we have considered (but not found a way to get working) include:

(i) having a way to force Visual Studio to use a particular pdb for a given module, even if the debug header is not present. Is there a way to do this?

(ii) having a hook into Visual Studio so that we provide debugging information for a given assembly directly from our add-in without having to go via a pdb file. Is that possible?

(ii) allowing us to get a debugged process to load our modified assembly instead of the assembly it was originally going to load. DEVPATH works well as we don't have to control the debuggee (to force the load) from the point that it starts up ie we can subsequently attach and an assembly will have been loaded which allows us to provide a pdb for it. It has been suggested that the profiler API would allow us to do this, but that isn't as convenient as DEVPATH which will redirect from startup before any attach happens.