On my development machine, I have a slow system disk (SSD) and a fast (RAM Disk) development disk. Once Visual Studio is up and running, the develop/build/test cycle is extremely fast, but application start is much slower [I believe] because of the shadow copying of assemblies to the system disk where the CLR download cache lives.
I have already specified the Visual Studio debugging assembly cache location to be on the RAM Disk, so after the initial load from SSD most of the referenced assemblies are already on the RAM Disk.
I know I can add custom code to my application to affect this change. However, because this configuration is specific to my development environment, I don't want to make any code changes to modify the shadow copy behavior. This seems to leave me with 3 choices:
- Disable shadow copying in
Web.Debug.config - Somehow specify the
CachePathandApplicationNamesettings thatAppDomainSetuprequires inWeb.Debug.configonly - Somehow specify that the CLR's Download Cache Path point to my RAM Disk
I'm not familiar enough with the details of how the CLR uses Shadow Copy to know if disabling it would adversely affect my development and test cycle in either subtle or overt ways. (I'm using IIS Express on my dev box, not IIS, in case it matters.) So I think I'm left with 3 questions:
What are the effects of disabling shadow copying on a code/build/run locally development cycle?
Is there a configuration setting to specify the shadow copy location for an assembly?
Is there a way to change the global CLR download cache location OR the Temporary ASP.Net Files directory location?
(and of course 4: did I miss something else? :)
