For dynamic compilation, there is a limited set of thing Orchard can
do to load assemblies referenced in .csproj files. With this checkin,
there are now 4 policies for resolving short assembly names to full
assembly names:
1. Try to load the assembly with its short name
2. Try to find the assembly in the list of assemblies in the AppDomain
3. Try to find the assembly in the list of assemblies referenced
by Orchard.Framework
4. Try to find the assembly in the list of assemblies commonly
installed in the GAC with .NET 4.0.
Work Items: 16940, 16946
--HG--
branch : dev
Orchard used to write to the "~/web.config" file to force an AppDomain
restart needed in some case of dynamic compilation.
Revised the policy to be like this:
1. If full trust, use HttpRuntime.UnloadAppDomain()
2. If Medium Trust, write to "~/bin/HostRestart/marker.txt"
3. If Medium Trust and 2. failed, write to "~/web.config"
4. If Medium Trust and 2.+3. failed, give an error message to
the user with appropriate measures to take on the web server.
Also removed a now unused "ResetSiteCompilation" method
--HG--
branch : dev
Don't try to load references that have been already loaded by
extension loaders. This bug was affecting compiling of modules
depending on other modules (e.g. Orchard.Widgets depends on
Orchard.Scripting). If Orchard.Scripting has been loaded by the
dynamic compilation loader, don't try to load the "Orchard.Scripting"
assembly.
--HG--
branch : dev
We were only monitoring existing directories only (not files).
Since asp.net supports monitoring missing files, but not missing
directories, we have to catch the HttpException and fallback
adequatly.
--HG--
branch : dev
Ensure batch compilation is on and that the number of recompilation
before appdomain restart is greater than the default (15), because
Orchard being a composable application where new modules can be installed
at any time, views can be re-compiled more often than for a typical
application.
--HG--
branch : dev
