# Sunday, 16 December 2012
« New Development Snapshot | Main | Raspberry Pi »
A Hack To Make CLR's DEVPATH Suck Less

The CLR's DEVPATH feature has always been broken and its brokeness varied over the years, but for my purposes it was a very useful feature. However with .NET .4.5 Microsoft decided to up the ante. If you have configured your .NET 4.5 runtime as a "developer installation", ngen will fail to generate native images for framework assemblies. This means that after Windows Update services mscorlib.dll, no native images will be used anymore.

Obviously you can work around this by editing the machine.config and re-running ngen, but that is a bit of a pain so decided to hack together a workaround.

The basic idea is to have a DLL that gets injected into (nearly) every process and patches mscoree.dll to make CreateConfigStream read developer-machine.config instead of machine.config if the DEVPATH environment variable is set.

The source and binaries are available here. Like the Microsoft DEVPATH code, this is untested so there is no warranty and use at your own risk. Bug reports are welcome of course.

There is no installer and there are no installation instructions, because frankly, if you don't know how to install it you probably shouldn't be doing so anyway..

The overhead is fairly low. If you don't have DEVPATH set the DLL will immediately unload again. The file size is only 3KB and in memory it will only use a single 4KB page.

Sunday, 16 December 2012 11:47:50 (W. Europe Standard Time, UTC+01:00)  #    Comments [3]
Wednesday, 07 August 2013 19:31:49 (W. Europe Daylight Time, UTC+02:00)
Why would you put the DevelopmentMode entry in the machine config? Although the MSDN documentation mentions that location in passing, in my testing, the element is supported in application configs without issue. Sure it is a bit more work to add the code to each app config, but it ensures that applications you are trying to use, (instead of develop/debug) are not inadvertanly affected by the contents of the DEVPATH.
Joe smith
Wednesday, 07 August 2013 20:28:18 (W. Europe Daylight Time, UTC+02:00)
Interesting. In .NET 1.1 it only worked in the machine.config and I never noticed it changed.

Saturday, 06 February 2016 03:42:01 (W. Europe Standard Time, UTC+01:00)
It looks broken in .Net 4.5 with CLR 4.0.30319. I have developerInstallation set to true in machine.config and DEVPATH environment variable set. I can also see the DEVPATH value logged in Fusion log, but in the end it just returns the assembly from the GAC without looking into DEVPATH.

Below is the fusion log.
=== Pre-bind state information ===
LOG: DisplayName = ProductCode, Version=, Culture=neutral, PublicKeyToken=6b6a45a9f6fa2e7a
LOG: Appbase = file:///C:/temp/NoSysGac/TryingAppDomainsToBypassGac/TestCodeDllAndLatestProductCodeDll
LOG: DEVPATH = C:\temp\NoSysGac\TryingAppDomainsToBypassGac\TestCodeDllAndLatestProductCodeDll\
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = te.processhost.managed.exe
Calling assembly : TestCode, Version=, Culture=neutral, PublicKeyToken=null.
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TestWindow\te.processhost.managed.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: ProductCode, Version=, Culture=neutral, PublicKeyToken=6b6a45a9f6fa2e7a
LOG: Found assembly by looking in the GAC.
LOG: Binding succeeds. Returns assembly from C:\windows\Microsoft.Net\assembly\GAC_MSIL\ProductCode\v4.0_1.0.0.0__6b6a45a9f6fa2e7a\ProductCode.dll.
LOG: Assembly is loaded in default load context.
Sandeep Kumar
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Comment (HTML not allowed)  

Live Comment Preview