Why not compatible with netcoreapp1.0?
mikeandersun opened this issue · 23 comments
Package RazorEngine 4.4.0-rc1 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package RazorEngine 4.4.0-rc1 supports: net45 (.NETFramework,Version=v4.5)
One or more packages are incompatible with .NETCoreApp,Version=v1.0.
Same problem here. Can't add RazorEngine 4.4.0-rc1 package to .NET Core console application, neither to .NET Core class ibrary
+1
Same Problem, do you have any plan to solve it ?
indeed not usable in xunit test project either
a PR would be welcome.
Why isn't it compatible? Some info would be helpfull
One needs to add support for it (ie build the project against the netcore target and possibly modify the code to support the new target).
- Edit the Build infrastructure to build against the additional target (netcore)
- Add the binary to the nuget package
I am looking into migrating RazorEngine to support .NET Standard 2.0. I ran RazorEngine through .NET Portability Analyzer and for the most part it is compatible. There are a few areas that would need to be looked at:
System.AppDomain: There appears to be some creating and management of AppDomains but .NET Core only has 1 domain.System.Reflection.Emit- The types/methods do not exist:
AssemblyBuilder.DefineDynamicModule(string,string)TypeBuilder.CreateTypeAssemblyBuilder.Save(string)TypeToken
- The types/methods do not exist:
System.Runtime.Remoting.RemotingServicesSystem.Security.Principal.WindowsIdentity: Impersonation
Hi @matthid ,
These are the PRs I hope to make in order to migrate this project to .NET Standard 2.0. Do these seem reasonable to you? Any feedback is appreciated.
In regards to paket, since the releases I had to use to make it work are RC and not stable, would you like me to remove the environment settings from the build.cmd/build.sh to set PAKET_VERSION="prerelease" and leave the CI builds broken until a stable release is released?
Tasks (PRs)
- Migrate tests to NUnit 3.6.0
- Replace Microsoft.Practises.Unity with Autofac.
- This is because Microsoft.Practises.Unity does not work on .NET Core and probably will not be migrated. This dependency is only used in the test projects.
- Update Microsoft.CodeAnalysis to 1.3.2 because it supports .NET Standard 1.3 and .NET 4.5.
- Microsoft.CodeAnalysis 2+ no longer supports .NET 4.5.
- Add compiler directive around code generation through CodeDom (ie.
RazorEngine.Core.CodeDom)- I may use compiler directives (ie. #if FEATURE_CODEDOM) to keep them in the same library
- Migrate or update Configuration model (because
System.Configuration) is not supported - Migrate RazorEngine.Core.Tests to .NET Standard 2.0
- Migrate RazorEngine.Core.Roslyn.Tests to .NET Standard 2.0
- Migrate RazorEngine.Core to .NET Standard 2.0
- Migrate RazorEngine.Core.Roslyn to .NET Standard 2.0
- Migrate RazorEngine.Hosts.Console and RazorEngine.Mvc
Questions
- How should I separate the CodeDom and Reflection.Emit from RazorEngine.Core? Would you want me to keep them in the same library and use compiler directives? Split into different projects? Something else?
- How should I work with the configuration model?
- I could write classes to try and replicate the same behaviour (ie. Create a ConfigurationSection, ConfigurationPropertyAttribute class, etc)
- Try to pull out similar pieces and use the Configuration model that ASP.NET team created.
- Exclude:
RazorEngine.Core\Configuration\Xml\*.csfor .NET Core compilation
Thanks!
Connie
@conniey Thanks for helping out.
leave the CI builds broken until a stable release is released?
No, prerelease is fine and Paket 5 will hit very very soon ;)
How should I separate the CodeDom and Reflection.Emit from RazorEngine.Core? Would you want me to keep them in the same library and use compiler directives? Split into different projects? Something else?
What do you mean with Reflection.Emit? Can't remember where we use that. If this is the part with the dynamic wrapper to cross appdomains then I think I'm fine with #if NO_APPDOMAIN (or whatever we miss there for example #if NO_REFLECTION_EMIT)
Regarding CodeDom, we already have the proper abstractions to split that out. Maybe the time has come to default to roslyn (I couldn't really do that at the time because stuff wasn't really stable when I added it). We would just add the proper dependencies to the NuGet package...
To be honest I'm not even sure it's worth to keep at all (it's quite an invest to split that out to a separate package, which probably noone will ever use)
How should I work with the configuration model?
To be honest I never really liked the configuration stuff, I'm happy with whatever improves the situation.
If it doesn't break the most common use-cases that's a plus... (We can discuss those in the PR)
Do you need any help with Reflection.Emit, or CodeDom extraction? Maybe the configuration stuff shouldn't be terrible hard (I assume). I just used RazorLight in a library and the performance was not very good.
@DeadlyChambers Hey, I was able to get it working on .NET Standard 2.0 because System.Reflection.Emit was brought back. If you are able to rewrite the DynamicWrapperService and RazorDynamicObject to not use System.Reflection.Emit, that would be awesome! (And we wouldn't have to target .NET Standard 2.0 potentially.) There are a lot of System.Configuration features used.. I added a compiler directive (NO_CONFIGURATION) to remove those for now.
Here is my branch if you wanted to look at it, try it out, make DynamicWrapperService work without System.Reflection.Emit, etc. https://github.com/conniey/RazorEngine/tree/updateToNetCore
My current approaches downsides:
- Consumers of this library will have to upgrade their solutions to .NETCoreApp2.0 or .NET Standard2.0
- Using dotnet-dev feed to build against .NET Standard 2.0. So consumers will have to add a reference to that feed as well until they update the package at RTM. (Unfortunately, System.Reflection.Emit NuPkg was not updated with .NET Core Preview 2.)
- As a result, I don't have a problem if this PR isn't merged in until .NET Core 2.0 is RTM'd. I would just want it open so folks could find the work.
TODOs:
- Revert projects from using NuGet package manager to paket.
- Merge the
RazorEngine.*.NetCore.csprojlogic back into their original csproj. - Update build scripts to consume/build the .NET Core projects
Excellent. I will look at it tonight when I get out of work.
Here's some instructions on how to use it so far:
Building in Visual Studio
- Open
./src/RazorEngine.NetCore.slnand build
Building Command Line
dotnet restore ./src/RazorEngine.NetCore.slndotnet build ./src/RazorEngine.NetCore.sln
Testing
This one is the most confusing one because of issues when using NUnit with dotnet-test.
- Running against .NET 4.6.2:
- This should be straight forwards because the Test Explorer populates with tests and runs them against .NET 4.6.2.
- Or,
dotnet test ./src/test/Test.RazorEngine.Core/Test.RazorEngine.Core.NetCore.csproj --framework net462
- Running against .NETCoreApp2.0
- Set the start up project as
Test.RazorEngine.NUnitRunner - F5 to start debugging
- I had to create this project because of this issue nunit/dotnet-test-nunit#108 and whenever I tried to use
dotnet test ./src/test/Test.RazorEngine.Core/Test.RazorEngine.Core.NetCore.csproj --framework netcoreapp2.0, I would get an exception about being unable to locate hostpolicy.dll
- Set the start up project as
I am currently getting a bunch of failures when running tests against .NETCoreApp 2.0. It may be a framework issue because the tests follow the same code path in .NET 4.6.2 and work still. I have to look more into it.
netstandard 2.0 is RTM. Any news on this issue?
Hi, I have a branch conniey/RazorEngine/updateToNetCore that has been updated to use netstandard2.0 RTM.
I am having a couple of new test failures that passed before but no longer due after the update. If you have time to look into it, that would be awesome. I have a couple of tasks I have to finish this week before I can take a look at it.
TODO
- Fix broken tests
- Issue67_CollectionOfAnonymous
- RazorEngineService_TestCastingToIEnumerable
- RazorEngineService_TestEnumeratingDynamicObject
- RazorEngineService_TestImplicitCastIEnumerable
- Issues submitted: https://github.com/dotnet/corefx/issues/23855, https://github.com/dotnet/corefx/issues/23856
- Migrate to use paket rather than NuGet (PackageReference)
- Delete *.NetCore.csproj projects
@conniey Issue67_CollectionOfAnonymous is Microsoft.CSharp bug dotnet/corefx#23512
@conniey Have you played around with upgrading the Microsoft.AspNetCore.Razor packages to 2.0? I used your project to successfully get some Razor templates compiling but I'm running into a dependency conflict with some projects that make use of AspNetCore 2.0 packages that create a hard dependency on Razor 2.0
It seems like they decided to completely rewrite the Razor libraries in AspNetCore 2.0 and I would love to help with the conversion but I have no idea where to start.
@deckertron9000 I have not been able to try it using Microsoft.AspNetCore.Razor 2.0. The thing holding me back is that I am not familiar with F# so the build (ie. FAKE) and package (ie. paket) system is touch-and-go for me.
[Edit]: Let me try and get back to you. I probably have to add the packages referenced here: aspnet/Razor#1855 (comment)
I tried to update to Microsoft.AspNetCore.Razor 2.0.1 and added all those libraries mentioned in the comment above. However it appears that they have done an overhaul of how it works and made classes like ParserBase internal. This would require some bit of work to rewrite the code.
@conniey yeah it looks like they changed quite a bit. I've been digging into the new way to extend but it's not well documented. RazorLight seems to have updated and gotten things working for the most part. I might dig into that code and see what I can figure out.
@conniey , @hermanho @matthid @deckertron9000 Any news on this issue?