How to Get the Temporary ASP.NET Path

written by timweaver on Tuesday, February 07 2006

With the new compilation model in ASP.NET comes a new set of issues for developers who need access to the temporary assemblies generated by the VS 2005 IDE

If you are lucky enough to be running outside of the IDE and can get hold of the HttpRuntime then the answer is simple (via Reflector):

public static string CodegenDir { get; }
If you can't get hold of the HttpRuntime then your options are fairly limited

Custom Algorithm

You can figure out the algorithm Microsoft used to create the directory name.

Some pitfalls of that approach

  • Algorithm could change
  • You own the (complex) code
  • Your code breaks without warning
  • There might be more to it than you realize *

* Most of the time the files end up under %windows%\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\<hash>\<hash>\  but that isn't always the case. We had some discussions with MS and found out that under certain cases the temp files can end up under Local Settings\Temp. So this means you not only have to be able recreate the two hash values, you also have to know all cases when the files will be in a different location. There has to be a better way.

Someone here spent the time doing just that on one of the early CTPs. I recently ran the code and found that it no longer produces the same results that the IDE uses.

ClientBuildManager

During our discussions with MS about this we determined that the best way to deal with this is to use the v2.0 ClientBuildManager class (via Reflector)

public sealed class ClientBuildManager : MarshalByRefObject, IDisposable
public string CodeGenDir { get; }

The ClientBuildManager will handle determing where the files will endup and calculating the hash values for you. Now you are no longer subject to the pitfalls outlined above.

If you are using the ClientBuildManager [CBM] within the IDE there is one issue to be aware of. The CBM will utilize whatever AppDomain the IDE is using to host the runtime. If you don't create the CBM in its own Appdomain you will start to see random errors from the IDE:  attempted to access an unloaded appdomain

The way to prevent this problem is to create a new Appdomain and load the CBM into that domain. Then call the CodeGenDir property (or one of the other methods).

cross-posted from http://blogs.compuware.com/cs/blogs/tweaver/archive/2006/02/07/374.aspx

Similar Posts

  1. NUnit with ASP.NET Context
  2. VS 2005 Provider Pattern in V1.1 of the Framework
  3. FXCop and the Introspection Engine in VS2005

Comments are closed

Options:

Size

Colors