- Added an ICachingProvider interface to support user defined caching strategies: #47
- Redesigned the API in this process.
- Added Legacy classes to support the old API by using the new API (marked as obsolete).
- Within the redesign support for streaming the output of templates was implemented: #27, #169
- With the new API one can exactly control where the templates come from (ITemplateResolver) and how they should be cached (ICachingProvider).
- The old API works for the complete test framework.
ICachedTemplateService -> IRazorEngineService
ITemplateServiceCore -> IRazorEngineCore (and now internal)
Razor class is now obsolete and replaced with RazorService.
Depending on the information we have about a template we improve the debugging experience:
- When the TemplateSource has a not null file path we tell Razor to generate Line pragmas (which leads to better stacktraces on exceptions)
- In the other case when we are in Debug mode we leave the temp files so we can debug into the templates.
- In the future we want to give the Caching layer the possibility to save the generated assemblies, this means we need to have a byte[] member in ICompiledTemplate for the assembly. (Currently this is only possible in Debug mode by copying the generated assembly). We will provide this in the CompilationData class.
- Improved the CompilationException by providing more details and explaining common pitfalls.
Implement IsolatedRazorEngineService. This allows to run the templates in an isolated appdomain. Fixes #144, #96, #32
Fix the .net40 tests:
Wow. Razor2 has an SecurityTransparent assembly attribute, which later versions do not have. This is/was the root for a lot of confusion. This also means that now our .net40 lib is not binary compatible anymore with Razor3 (and the other way around).

See http://msdn.microsoft.com/en-us/library/dd233102.aspx for details. We now need to ensure that RazorEngine and (especially) Razor are loaded with full trust.
Improve classname generation: This should fix #135, #38.
Test the sandbox on IsolatedTemplateService (obsolete) as well.
modelType == null -> typeof(DynamicObject) instead of typeof(object). This will only change the "new" IRazorEngineService API. I think using "null" for "dynamic" is kind of nice (as typeof(dynamic) will not work).
better handling of the @model directive (cache the template under the dynamic and its static type).
Fix for #67 and #103.
We now support any kind of anonymous type (list of anonymous for example):
When we use dynamic (modelType == null) and wrap our object in RazorDynamicObject the object never leaves its appdomain (because it is wrapped in a MarshalByRefObject) at the same time we dynamically fetch all Invocations and transfer them to the original. Then we execute the Invocation on the original object and return the result (which is itself wrapped when it is not a primitive).

This way we can also support types that are not serializable even when we are in the IsolatedRazorEngineService case (at the cost of performance)!

This commit copies some classes from the Impromtu project (https://github.com/ekonbenefits/impromptu-interface). We copied them so we have no additional dependency (and because some classes are not marked as serializable in the original code).
Maybe we can make a seperate nuget package in the future with an opt-in API for this (RazorDynamicObject) and an Impromtu dependency.
Fix .net40 build, wrap IRazorServiceEngine and move the anonymous type support  into the wrapper (so that it works on the normal and the sandbox case). Added IConfigCreator so we can configure the IsolatedService.
We now dynamically implement all interfaces (create a type that implements all interfaces)... This will make Linq Extension methods (and all extensions based on interfaces) work. We also search for explicit members now.
Huge cleanup commit.
- Add comments.
- New FSharp.Formatting supporting <see cref="" />
- RunCompileOnDemand -> RunCompile
- CompileAndCache -> Compile
- RunCachedTemplate -> Run
Fix #91, update documentation.
fix some minor build things
small doc fix.
cleanup temp files when possible.
Fix some sandbox bugs: #35.
Give the test assembly full trust and add some unit tests.
On mono we can delete assembly files even when they are loaded.
Because we cannot know when GC removes our objects we cannot know when those files are deleted.
This means we will just ignore assemblies that are compiled by us as a workaround.