Share via

DEVPATH

  • Article

Recently I have heard a great deal of confusion around DEVPATH. This blog tries to clarify a few things about DEVPATH.

 

  1. What is DEVPATH?
    DEVPATH is documented in MSDN (How to: Locate Assemblies by Using DEVPATH).

    In a nutshell, DEVPATH is a mechanism to enable debugging of private copies of shared assemblies without affecting running system during development time.

    To enable DEVPATH, add the following XML snippet to machine.config.

    <configuration>
    <runtime>
    <developmentMode developerInstallation="true"/>
    </runtime>
    </configuration>

    When DEVPATH is enabled, at runtime, fusion checks if environment variable DEVPATH exists. If it exists, fusion will probe the assembly in the path specified in environment variable DEVPATH before fusion probes GAC and AppBase.

    The path specified in DEVPATH can be anywhere in the system. Fusion does not enforce it to be under AppBase.

    When an assembly is found in DEVPATH, fusion still does Ref-Def matching check, but skips version check. In other words, fusion will compare name, culture, publicKeyToken and processorArchitecture, but will not compare version.

  2. Is DEVPATH supported?

    Yes. DEVPATH is supported by .Net framework v1.0, v1.1 and v2.0 in all the Operating systems. And it is likely to be supported in the foreseeable future.

    However, DEVPATH is only supported in development. It is not supported, and strongly discouraged in production, as it basically violates all the probing rules.

  3. When should I use DEVPATH?

    DEVPATH is typically used to override shared assemblies installed to GAC, without impacting the system.

    For example, a .Net framework developer on Windows Vista (where .Net framework 2.0 is built-in to the OS) does not want to overwrite the System.dll in GAC with his/her private copy of System.dll, as it may unstablize the operating system. He/She can use DEVPATH, and let his/her tests run against his/her private copy of System.dll.

  4. What is affected by DEVPATH?

    Fusion redirects both Assembly.Load() and Assembly.LoadFrom() to DEVPATH. Assembly.LoadFile/Assembly.Load(byte[]) are not redirected, as they don’t use fusion.

    When Assembly.LoadFrom() is redirected, fusion throws away the path, and only uses the file name to search in DEVPATH.

  5. What has changed between .Net framework v1.0/v1.1/v2.0 regarding DEVPATH?

    .Net framework v1.0 and v1.1 have identical implementation.

    However, there are significant changes between v1.1 and v2.0. Specifically.

    1. Multiple paths works in v1.1, but not in v2.0

      In v1.1, you can set environment variable DEVPATH to multiple paths separated by ‘;’. Fusion will search the assembly in every path specified in DEVPATH.

      This no longer works in v2.0 RTM. This is a regression, and we may fix in a future service pack for v2.0.
       

    2. Fusion redirects partial name assembly loading in v1.1, but no longer does so in v2.0.

      This change is to make the scenario close to production behavior, as fusion does not probe GAC for partial name assembly loading.

      If you are blocked by this change, you can work around the problem by using qualfyAssembly, as documented in MSDN.

      https://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfQualifyAssemblyElement.asp

    3. Probing behavior changes significantly within DEVPATH.

      In v1.1, fusion simply appends the assembly simple name, plus “.dll” extension to the DEVPATH, and looks for the existence of that file. For example, if DEVPATH is set to “c:\debug”, for Assembly.Load(“Foo, version=1.0.0.0, culture=en-us, publicKeyToken=0123456789abcdef”), fusion will check if “c:\debug\foo.dll” exists or not. If it exists, fusion will return it.

      In v2.0, the DEVPATH is treated as another AppBase. Fusion uses the normal probing rule to probe within DEVPATH. In our example above, fusion will probe the following files in the specified order:

      c:\debug\foo.dll
      c:\debug\foo\foo.dll
      c:\debug\en-us\foo.dll
      c:\debug\en-us\foo\foo.dll
      c:\debug\foo.exe
      c:\debug\foo\foo.exe
      c:\debug\en-us\foo.exe
      c:\debug\en-us\foo\foo.exe

      The primary motivation for the change is for localization --- Apparently the v1.1 behavior won’t be able to support more than one resource assemblies.

Comments

  • Anonymous
    December 13, 2005
    According to Suzanne Cook's blog (http://blogs.msdn.com/suzcook/archive/2003/08/15/57238.aspx) DevPath will soon be deprecated.

    Which post is more accurate on this matter?

  • Anonymous
    December 13, 2005
    Nice to hear, great article!

  • Anonymous
    December 13, 2005
    At the time of her blog, we briefly considered deprecating DEVPATH, and replace it with something else. The decision was reverted and we fully support DEVPATH in development mode.

    The ultimate authority is MSDN. If MSDN does not say it is deprecated, it is not deprecated.

  • Anonymous
    March 07, 2006
    We develop a large scale C# application to be run on a GRID.
    This application will be installed on dedicated HW.
    All assemblies are located in a centrlized FileServer, no assembly is installed on any single PC.
    DEVPATH environment is set dynamically when loading an EXE using Process.Start().

    The system was developed on V1.1 RTM and we are now porting it to V2.0.

    Problems we encountered with DEVPATH on V1.1:

    [a]
    the section
       <runtime>
           <developmentMode developerInstallation="true"/>
       </runtime>
    must be placed at the very end of machine.config, otherwise the RTM will ignore it.

    [b]
    When you set multiple paths separated by ‘;’ you MUST add ';' to the end of the string otherwise the last item will be ignored.


    Problems we encountered with DEVPATH on V2.0:

    [a]
    You MUST set only one path - multiple paths are ignored.

    [b]
    If you add the section
       <runtime>
           <developmentMode developerInstallation="true"/>
       </runtime>
    to machine.config but you don't define any DEVPATH environment variable, your EXE will crash.


    The DEVPATH concept is extremely crucial to our system.
    We can not use GAC, and if we don't have the DEVPATH option we will have to place all our code in one directory, and we talk about several hundreds of assemblies.

  • Anonymous
    March 07, 2006
    Isaac,

    DEVPATH is not supported on product environment.

    Your scenario should be well covered by the linkedConfiguration feature we introduced in v2.0.

    http://blogs.msdn.com/junfeng/archive/2005/02/08/369662.aspx

    If you can move to that it will be great, as our product support service team is able to officially help you.

  • Anonymous
    March 07, 2006
    Thank you junfeng!

    I will certainly explore the inkedConfiguration feature.

    In any case if you have influence on the FUSION development team, then I guess the bugs/problems I described should be addressed.

  • Anonymous
    July 04, 2007
    PingBack from http://blog.smart-ms.ordina.nl/Custom+IIdentity+And+The+ASPNET+Development+Server.aspx

  • Anonymous
    September 25, 2008
    PingBack from http://codingcsharp.wordpress.com/2008/09/25/advanced-net-concept/