DEBUG
and RELEASE
modeI'm messing around with .NET Core to see if I can make something that'll run on "linux".
In short, I got most things working (or added some lovely TODOs) but I can't seem to find support for razor. Is this planned at a later stage or a bug? Or do I need to enable support for razor views in another way?
Try to reference the Nancy.Viewengines.Razor package v2.0.0-barneyrubble.
Seems like all viewengines lack the support for netcoreapp1.0?
edit: Except the built-in one
Razor is now in Microsoft.AspNetCore.Razor for DOTNET Core. Currently looking at how to port the code in Nancy.
@gravypower Any success?
Unfortunately no at this point, there is a lot of code in the nancy razor project that I don't understand where some razor APIs have changed. Will need to work out what is going on before I could have a chance at porting the code. Might be best for a nancy team member to give direction.
I really need this but I'm not working on it until all the tooling is fixed for dotnet core, I've been avoiding the mess. I have my app working on dotnet core for APIs but not the razor stuff, hindering me hosting my app on Ubuntu.
nansy team is where?
Any update on this? I'd really like to stick to Nancy for my future projects :/
There is no simple way forward wit this. It is not an impossible thing to make happen, but it is a very difficult one and one that we've simply not had the time to invest ourselves up to this point. I think I've explained this multiple times, in many places so here goes again.
There is no such thing as a cross-framework or even standalone Razor view engine in the sense that most people expect there to be. Basically there is a Razor parse i.e the thing that can parse razor syntax into an executable piece of code. This part is used by most view engines (I say most, because I'm sure someone has implemented their own Razor lexical parser as well 馃槃). So far so good... almost.. this parser only understands core concepts in the Razor syntax and not all of the things that we've come to expect to use from our Razor views.. things like master pages, __viewstart etc are not concepts that the parser understands.. these are view engine concepts.
View engine you say? Yeah. The view engines is the piece of code that acts as the bridge between the razor parser and a framework. This is where it gets hairy.. the engines contains framework specific concepts. So the Razor engine that is shipped by Microsoft for ASP.NET * stuff, makes use of their concepts and abstractions (such as HttpContext and other bits and bobs).. while the Razor engine for Nancy makes use of Nancy specific features such as view location conventions, NancyContext and other stuff. We simply can't take one and plug into another.
To add on top of that, remember those things I mentioned earlier like master pages etc? If you want your engine to support those, you have to implement them yourself. That means we've had to implement them ourselves in the engine for Nancy. And trust me.. the documentation around both the Razor parser and the nuisances of the features found in the ASP.NET Razor engine is poor at best so there has been A LOT of time and spelunking involved.
Fast forward to now and there's been yet another leap forward in the provided functionality in both the Razor parser and the additional feature set that the latest incarnation of the ASP.NET Razor Engine provides. There are also a bunch of other internal changes that would be needed to work on ASP.NET Core.
That said.. this is something I really want to get working. Let's see if I can ping @NTaylorMullen and see if he can help us get the analysis phase going.. i.e what does the new razor surface API look like that we would need to consume.. from Nancy we need to provide an IViewEngine implementation that wrapped the new bits from Microsoft
any updates on this?
Most helpful comment
any updates on this?