Mark Tucker asks this question:

<quote>

I have the need to place a resources-only assembly in a well-known directory location that is not the GAC or under the ApplicationBase.  I then use Assembly.LoadFrom to load the resource, assembly.GetManifestResourceStream() to get the ResourceSet stream, and new ResourceSet(stream) to create a ResourceSet from the stream.  This fulfills our requirement, but the assembly is now locked and can't be overwritten. 

When I do something similar using LoadWithPartialName and the assembly is in the ApplicationBase, then a Shadow copy of the assembly is made and I am able to update the assembly without tearing down the AppDomain.  Is this a deficiency with LoadFrom?  How can I get the same functionality as in ApplicationBase?  This is an ASP.NET 1.0 application.  I have read that you shouldn't use .resources files as they will be locked.  That is why I am using assemblies.

Your help is greatly appreciated.

</quote>

Only assemblies in AppDomainSetup.ShadowCopyDirectories will be shadow copied. And they will be shadow copied in both Assembly.Load() and Assembly.LoadFrom(). ASP.NET set the shadow copy directories to bin directory under the ApplicationBase. That is why your Assembly.LoadFrom() did not shadow copy the assembly since your assembly is outside of the ApplicationBase.

One possible workaround can be to add the interesting directory to shadow copy directories. The following code snippet should do it:

AppDomain.CurrentAppdomain.SetShadowCopyPath(AppDomain.CurrentAppDomain.SetupInformation.ShadowCopyDirectories+”;”+<the interesting directory>);

Alternatively, you can manually copy the assembly to a temporary location then call Assembly.LoadFrom() on the temporary location. That way you won't lock the original assembly.

If you only have one assembly to worry about, you may like the alternative more.

According to our developer on resource, the reason we tell people to use satellite assemblies in ASP.NET instead of .resources files,  is so that they get shadow copied automatically. Unfortunately your resource assembly is not under the default shadow copy directories.

Edit: Suggest an alternative. It is possible that we will mark AppDomain.SetShadowCopyPath as deprecated in the future.