v2.0.0-beta9

#349 - Fixes #349 dotnet pack bug causes .netcoreapp3.1 TFM projects issues @(@jzabroski)

v2.0.0-beta8

#335 - Fixed spelling errors in the code (@SimonCropp)
#309 - Added regression tests for common Razorlight renderer cases (@weyert)
#346 - Introduce Verify for section approval tests (@SimonCropp)
#308 - Fixed "The name 'section' does not exist in the current context in .net core 3" (@jzabroski)

v2.0.0-beta7

• Fixes #322 via commit 2d9c031 (@jzabroski )

v2.0.0-beta6

• Fixes #311 (via @HakanL PR #312): Incorrect template key when using constructor that takes assembly.
• Release Management improvement: Cleaned up Sandbox, Sample and RazorLight.Precompile projects to have IsPackable=False

v2.0.0-beta5

• Fixes #287 via #310 (@matthewwren viz a viz @chancie86 )

2.0.0-beta2

What's new

• #123 Template now shares model with layout.
• #107 Embedded project can now accept Assembly + root namespace as a string, instead of Type of root object
• #152 Allow FileSystemProject to set Extension ( @KorsG )
• #180 Add ability to exclude assemblies from metadata references ( @mscrivo )
• #278 Add netcore 3.0 support ( @gjunge )

Bug fixes:

• #103 - Fixed race condition compilation bug
• #134 - Fixed rendering issues with included templates
• #135 - Fixed ViewBag doesn't work in nested templates (@deckertron9000)
• #141, #147, #133 - Resolve MetadataReferences without using DependencyContext on Full .NET Framework (@colinbull )
• #153 - Fixed MemoryCachingProvider file naming (@KorsG )
• @Raw() will not throw NullReferenceException on null or empty value (@ReinisV1 )

Breaking changes

• EngineFactory will trigger build error. Marked completely Obsolette. Use RazorLightEngineBuilder instead
• When template you want to render does not exist, TemplateNotFoundException will be throws instead of InvalidOperationException

2.0-alpha3

What is new?

String rendering is back!

We added rendering of the strings back! And now they are cached, so you will not be affected by bad performance.

Note: if you store your templates in database - it is recommended approach to define custom RazorLightProject that fetches templates from database and create RazorLightEngine passing your implementation to it. This way, engine will your RazorLightProject to resolve layouts. String rendering is just another option for some exclusive use cases when you have microservice structure and pass templates between nodes, so you might not need it at all.

Here is an example of RazorLightProject that uses EntityFramework to get templates from database- https://github.com/toddams/RazorLight/blob/dev-2.0/samples/RazorLight.Samples/Program.cs

string templateKey = "key";
string result = await engine.CompileRenderAsync(templateKey , "Hello @Model.Name", new { Name = "Johny" });

//Returns true, so next time you render template with this key - it will not be compiled, but taken from cache
engine.TemplateCache.Contains(templateKey); 

Additional metadata references

When RazorLight compiles your template - it loads all the assemblies from your entry assembly and creates MetadataReference from it. This is a default strategy and it works in 99% of the time. But sometimes compilation crashes with an exception message like "Can not find assembly My.Super.Assembly2000". In order to solve this problem you can pass additional metadata references to RazorLight.

var options = new RazorLightOptions();

var metadataReference = MetadataReference.CreateFromFile("path-to-your-assembly")
options.AdditionalMetadataReferences.Add(metadataReference );

var project = new FileSystemRazorProject("path-to-your-views");
var engine = new EngineFactory().Create(project, options);

2.0.0-beta1

What's new?

Breaking changes

• Added new type: RazorLightEngineBuilder that comes to replace EngineFactory, as too many overloads are annoying
• EngineFactory masked as Obsolete.
• EngineFactory.RazorEngine is moved to DefaultRazorEngine.Instance
• ICompilationService.CompileAndEmit renamed to CompileAsync and returns Task
• DefaultCachingProvider renamed to MemoryCachingProvider

Note: there was a major refactoring, you may find some classes are moved to another namespaces

New features

• Templates that are resolved from FileSystem are now invalidated from MemoryCache when you change it.

• You can now create an engine without a project, if you want to only create templates from strings - #110

• It is possible now to create engine without caching provider

• Add ability to set operating assembly (uses EntryAssembly if not specified)

• Disable encoding for the entire document with template property "DisableEncoding" - #106

Bug fixes

• Fix ViewBag not passed to the engine #97
• Close stream after read - #120
• Fix concurrent template build fails - #103

2.0-alpha2

What is new?

• Added support for includes via @{ await IncludeAsync("key", model); }
• Disable encoding

As always, you can avoid encoding using @Raw() function

@Raw(Model.Data)

Or disable encoding for entire document

@{
    DisableEncoding = true;
}

Breaking change

• GetTemplateAsync is now called CompileTemplateAsync

2.0-alpha1

2.0 alpha version is out

This is not a full list of changes, only key notes about the changes and important info

• There are a lot of breaking changes. Project literally has been made from scratch
• IRazorLight interface is still there. There is no "Parse" method. Use "CompileRenderAsync" instead (method names might change in future releases)
• EngineFactory no longer static
• No IEngineConfiguration yet.
• No MVC version with @Inject yet.
• No ViewStarts yet
• FileSystem templates are not tracked and therefore are not invalidated from cache yet when you change them
• No string caching (Most people used it to for templates that are taken from database. Recommended approach is to create custom RazorLightProject class that will load your templates from database. That's all you need and this way, your templates will be cached). I will create a sample tomorrow with EntityFramework and NpgSql

So what is implemented?

• Basic Razor support
• Model
• Layout,
• Sections
• Caching