Microsoft di and roslyn compiler #77
Conversation
…ependencies - Now using constructor injection instead of auto-initializing properties - Removed ISparkServiceInitialize and ISparkServiceContainer (and it's implementation) - New IBatchCompiler interface so that we can use different compilers - ~2x performance improvement when compiling views with Roslyn - CodeDom compilation can still be used at the moment (class marked as obsolete) - CastleMonoRail still using codedom (rosylin doesn't like the assembly name when compiling in that project)
…ewEngine/spark into microsoft-di-and-roslyn-compiler
- CodeDom complilation cannot target .net core - BatchCompiler.cs contains the code to complile with codedom and/or roslyn
|
I found a problem when using roslyn to compile the views: each time a view is compiled, an assembly is loaded into memory and never released. This means spark eats up all the memory available and eventually |
|
Good catch! I'll take a look again when you've found a workaround for this.
…On Tue, 13 Feb 2024 at 11:00, Benjamin ***@***.***> wrote:
I found a problem when using roslyn to compile the views: each time a view
is compile an assembly is loaded into memory and never released. This means
spark will eat up all the memory available and eventually
OutOfMemoryException are thrown.
—
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABFDZJW4B5NUDTOOE24Z7DYTNBWNAVCNFSM6AAAAABCIVX6P2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBRGIYTIMRUGI>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
- Improved readability of RemoveSuffix method
- Renamed ISparkSettings.PageBaseType to BaseClassTypeName - An instance of ISparkSettings is used instead of duplicated properties on the ViewCompiler base class - New ISparkSettings.ExcludeAssemblies property that can be used to the prevent the view compiler from loading .DLLs that would containt precompile views (and would might already be loaded)
- Replaced by a callback in the IoC configuration - See ServiceCollectionExtensions.cs
- InMemoryCacheService cache can be used in any .net standard project - CacheExpires class not longer has depenency on System.Web.Caching.Cache - Renamed DefaultCacheService to WebCacheService - Moved NullCacheService to Castle.MonoRail.Views project (it's the only place using it) - Moved some classes back to Spark project when possible - Moved markdown dependency back to spark
- Use of a new SparkRouteData class - Avoids having a dependency on Microsoft.AspNet.Mvc
|
I can't think of a fix for .net framework. I think the best it to carry on using the non roslyn compiler. For .net core, loading the assemblies into a |
|
Is it worth going down the Source Generation route during compile time maybe? |
Definitely something worth exploring. It would be ideal to have the same options/behaviour as with MVC Razor (e.g. the choice to compile the views are build time (default) or to leave it for later at runtime). I couldn't find any docs explaining how Microsoft does compile their razor views at build time... |
Using the Microsoft.Extensions.DependencyInjection apis to resolve dependencies
ISparkServiceInitializeandISparkServiceContainer(and it's implementation)IBatchCompilerinterface so that we can use different compilers#if NETFRAMEWORKblockICacheServicethat is works on .net standard (InMemoryCache)