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

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 689691 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 9/20/2011 3:05:52 AM
Access Restriction Public
Moderator Decision Sent to Engineering Team for consideration


I reported this bug

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.
Sign in to post a comment.
Posted by Clive Tong on 10/4/2011 at 12:11 AM
Posted by Microsoft on 10/3/2011 at 5:29 PM
Hi. We will fix this issue in 4.5, and I also asked VS guys whether they can provide a more straightforward way for you. So far doen't look very promising, though
Posted by Clive Tong on 9/29/2011 at 9:02 AM
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 - 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.
Posted by Microsoft on 9/28/2011 at 2:28 PM
Hi. Could you provide more info about your scenario and the reason you are using devpath? Since fixing this might be risky, we would like to see if there are different (and, perhaps, better) ways to get the functionality you want.
Posted by Colin G Little on 9/26/2011 at 3:59 AM
I have the same issue as reported however one of the other developers using the same solution does not have this issue. Therefore I wonder if something else has caused this - we are currently comparing service packs etc.
Posted by MS-Moderator09 [Feedback Moderator] on 9/21/2011 at 6:29 AM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for review. We will contact you if we require any additional information.
Posted by MS-Moderator01 on 9/20/2011 at 3:45 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(