Because of the way ASP.NET BuildManager works(*), we can't enable
dynamic compilation of a module if the module is already
present in ~/bin.
(*) When invoking the compiler, BuildManager automatically adds
references to all assemblies present in ~/bin. So, if you have module
"X" in "~/bin", there is no way to enable dynamic compilation of
module "X" by compiling "X.csproj", as there will be tons of
compilation errors with equivalent types defined in multiple
assemblies.
--HG--
branch : 1.x
Some of our assemblies in "~/bin" reference "System, Version=2.0.0.0".
During the first time site compilation in the command line scenario,
asp.net will sometimes decide to load that version of the assembly
from disk (from the GAC), even though the application is configured
to run on .NET 4.0. The workaround is to remove a couple of web.config
elements, so that ASP.NET will load the correct version of those
assemblies at startup.
Work Item: 17728
--HG--
branch : 1.x
Due to the way we nest cache context implicitly, there were cases
where we had 1,500+ tokens with only 200+ unique ones.
We now call "distinct" on the tokens when after an entry is created.
This decreases memory usage and also improve performance on cache
hits (fewer tokens to go though each time).
--HG--
branch : 1.x
This is to avoid a potentially un-wanted side-effect of having
an enumeration returned in a different order when executed
in parallel.
--HG--
branch : 1.x
We need a new service, IParallelCacheContext, which allows
tracking the current cache context across threads and tasks
running in the thread pool.
--HG--
branch : 1.x
Extension harvesting is a mix of independent operations requiring
file i/o and cpu usage, so they are good candidate for
parellelization.
Also make module harvesting in ~/Core a separate folder instance.
--HG--
branch : 1.x
Use composition over inheritance. This will be useful later to
improve performance of module/theme manifest harvesting.
--HG--
branch : 1.x
rename : src/Orchard/Environment/Extensions/Folders/ExtensionFolders.cs => src/Orchard/Environment/Extensions/Folders/ExtensionHarvester.cs
Before recompiling a dynamic module (.csproj), the BuildManager
verifies that the file hash (returned from the VPP) has changed
from the previous compilation. Instead of returning of the file
hash of the .csproj file and all its virtual dependencies (source
files and references), use the file hash value stored in the file
managed by IExtensionDependenciesManager.
This improves startup time by 10+ seconds on file i/o bound machines.
--HG--
branch : 1.x
to compute the file hash to store into the ExtensionDependencies
file. This allows skipping doing additional file I/O on dynamic
modules when they are activated.
--HG--
branch : 1.x
Loaders should only know about dependencies, not about modification
dates. This will help centralizing and abstracting away (for
performance reason) the algorithm used to pick the correct
module to activate (according to last modification dates).
--HG--
branch : 1.x
Monitoring virtual dependency files for modules takes requires a lot
of file I/O, and can be a significant bottleneck on heavily loaded
disk sub-system (5-10 secs). Making this process asynchronous during
startup decreases startup time by almost that amount of time.
--HG--
branch : 1.x
If processing the request immediately, use a dedicated
"DoneAsyncResult" class to avoid waiting on a handle.
Also make sure that we return false from "CompletedSynchronously" only
when in "Warmup" mode.
--HG--
branch : 1.x
* Remove dependency on Orchard.Framework assembly
* Fix issue where a host initialization failure would result in
'404' errors. We need to restart the host initialization and
make sure new incoming requests are queued.
* Fix concurrency issue when multiple requests are pending for the
host initialization to finish (only one request would notify
of a potentially error, the other ones would return a '404').
--HG--
branch : 1.x
extra : transplant_source : %3Dz%E4%ADEq%91%9D%17%D2%10jut%A6%93%09t%7CR
When a module changes, it's loader can change, which means the list
of dependencies can change to. Instead of trying to track the list
of dependencies, we now simply add a dependency on a file on disk
which describe the module compilation state.
As an aside, this also improves startup performance when
there were no changes to a site, since asp.net now only has
to check a single file instead of the list of dependencies.
--HG--
branch : 1.x
In particular, files from ~/Core should not be included in
the list of dependencies, are Orchard.Core.dll is assumed to be
in "~/bin", so any change to it will force a whole site recompilation
anyways.
--HG--
branch : 1.x
The file is similar to "dependencies.xml", except it contains file
hash of all virtual path stored in the file. This is to ensure that
the file content is updated when any file hash changes.
This will be used in an upcoming bug fix.
--HG--
branch : 1.x
Abstract away WebForms syntax knowledge from extension loader
implementations.
Rename the corresponding methods to be more semantically correct.
--HG--
branch : 1.x
Decrease constant cost of implementation:
* Don't check for file/directory existence. It is much more
expensive to systematically check for file existence through the
VPP than catching the occasional exception.
* Don't eagerly create ASP.NET cache entries when there are
already existing entries. This is so if there are multiple calls
for the same virtual path, we don't end up calling an expensive
API when there is no need.
--HG--
branch : 1.x
extra : transplant_source : %C8%C3t%5C%B3%DA%C4%98%E8%13%23%D1B%91%AF2%B7%01%E7%CE
This is so that the IVirtualPathMonitor implementation can
properly cache virtual paths in a single entry. This decreases
the number of entries by one or two order of magnitude when
complex solutions are loaded (i.e. modules with lot of references
to other modules).
--HG--
branch : 1.x
extra : transplant_source : %11%21n%FA%5Dy%E9%83%E3%86%86%D0%8Ba%FF%98%5C%8D/%22
SiteSettings are used very early and often in Orchard, so we
can't rely on having the user be able to run migration for
SiteSettings. The workaround for 1.1 is to move the changes
we did to SiteSettings into a new SiteSettings2 Part/Record.
With this change, database compatiblity from 1.0 and 1.1 seems
to be in a good working state on a real blog site.
--HG--
branch : 1.x
Renaud Paquay