Add support for .NET Core #300
Comments
|
Just to be helpful: OctopusDeploy release a tool to help with migrating to Core: |
|
@gijswijs Thanks, I'll check that out! I'm hoping to start this effort fairly soon. It looks like many of the libraries we depend on have either ported or are in the process. |
|
Yep, i'd love to use this inside docker/linux |
|
Any progress on this yet? |
|
I'd be willing to help out to add .NET Core support. |
|
Is there a list floating around somewhere of what has to be fixed for Wyam to run on core? Is it possible to generate one somehow? |
|
@daveaglick Can I get started on this now? I need to make wyam as a part of the build process, and I want to use a docker image for the build server :) |
|
I'd probably get the core/tests done first. Then, module-by-module, we will inspect dependencies and determine if we can support .NET Core. I remember seeing a few dependencies that didn't have .NET Core support. |
|
@pauldotknopf Be my guest! I haven't dug too deeply into it because I suspect some of the assembly context and application domain loading stuff may be a pain until those are introduced in netstandard 2.0. That said, if you're able to get around it, I'd be happy to make some progress here. |
|
@pauldotknopf Good call - most of the challenging stuff is going to be in |
|
@pauldotknopf @daveaglick Hi, is there any progress regarding Wyam on .NET Core? I didn't try it out, but the docs still say that Wyam runs on .NET Framework 4.6.2 |
|
@philippgille That's correct, it's still full-framework only. Work is progressing on .NET support but it'll still be another couple months. We need to convert all the extension libraries to netstandard first, then can convert the core Wyam libraries. netstandard 2.0 is a blocker for some of the core libraries given the way assemblies are dynamically loaded. Rest assured that .NET Core support is definitely high on the priority list. |
|
The blocking feature is probably Quote:
I didn't work with any of the two namespaces yet, so I don't know if it's a viable alternative for Wyam (or its dependencies). |
|
@daveaglick so.............. ? You waiting for the next major release buddy? 😉 😛 /poking |
|
@MaximRouiller Waiting on an enterprising developer to drop a full porting PR in my lap. Hasn't happened yet, but doesn't mean it won't 😉 😉 |
|
LOLLL So... apparently, I'm going to be taking vacations soon. How long do you think this is going to take? |
|
Or rather, what are the "steps" that are necessary to do and how many can I do in a weekend? |
|
To be honest, I'm waiting on netstandard 2.0 to drop. There's a lot going on under the hood with regard to assemblies, dynamic compilation, and binding and 2.0 should have the reflection parts to make that much easier to port. Don't want to spend a ton of time on workarounds now if it'll mostly work with minimal changes soon. |
|
So... it's officially "waiting on 2.0" status. |
|
Yeah. I just don't have the time to go chasing the bleeding edge. |
|
Yeah, no point in stabbing ourselves in the face with that edge. 😛 |
|
According to this: https://github.com/dotnet/core/blob/master/roadmap.md They drop a preview in Q2, with the thing going live in Q3. Assuming less code churn in v2 than in the initial alpha/beta/rc run for core, that means we could be hitting this fairly soon. |
|
Ya, I don't see any reason why this can't be started now. I have been watching the changes in corefx/coreclr. The work has been really adding back old api's that don't exist for coreclr yet. |
|
Many 3rd party libraries are now supporting .NET Core. The water feels good. Come in. |
|
What would be the process to do that with this codebase? I've coded in core, but haven't ported anything to it. Do we just pull down the solution and start switching project properties to use netstandard? My impression was that project structures changed significantly going to core and that Microsoft (probably) didn't provide any kind of migration tool. Has that changed? |
|
@daveaglick I pulled down Fleck and ran the portability analyzer. It appears that Fleck has full API compatibility for .NetStandard 2.0 and .NetCore 2.0. 🎉 I'm so happy for 2.0.
https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer |
|
@daveaglick created a pull request over on Fleck's side to support .NetStandard - statianzo/Fleck#220. |
|
@Silvenga Nice! And looks like they’re game to take it in quickly too. Based on your portability analyzer run, I also did some experiments with switching Wyam.Hosting to netstandard as-is. It looked promising, so may be able to switch even before a Fleck update is published. Just needs a little more testing. |
|
Should Wyam.Razor work on a .NET Core 2.0 app? I get this error when I try to use it:
As far as I see, RazorEngineHost is not part of Microsoft.AspNetCore.Razor on .Net Core 2: |
|
I am attempting to upgrade
I pointed all of the above to the latest package and it is still telling me that they depend on |
|
Owin is old technology that won't be updated. Consider it deprecated. |
|
@pauldotknopf Then what replaces Owin so I can get Wyam.Hosting ported? |
|
I’m hopefully circling back around on the porting effort starting next week (I’ve got a Big Thing launching that’s been taking much of my attention recently). In the meantime, can probably look at https://github.com/natemcmaster/dotnet-serve for an example of how to do this sort of thing under .NET Standard. It basically does exactly what Wyam.Hosting does, just as a global tool. I even ported some of the Wyam.Hosting functionality over to that project, so now we need to port it back to Wyam.Hosting. The bigger challenge is going to be the Live Reload bits. I think those are .NET Standard so might work out of the box under .NET Core, but we’ll need to be careful there. May end up swapping for SignalR at some point for that. |
|
@escobar5 Wyam.Razor is a bit of a mess right now. It uses the ASP.NET Core 1.x Razor stuff and the Razor API is totally different in ASP.NET Core 2.x. Not to mention there are a lot of tricky assembly conflicts and breaking changes between the Razor bits currently in Wyam.Razor and the more recent .NET Standard 2.x bits other Wyam module libraries are using. Presumably the new ASP.NET Core 2.x Razor APIs are simplified but I haven’t had a chance to look closely yet. As part of the port to .NET Standard/Core I want to rewrite the entire Wyam.Razor module to use the new bits before releasing Wyam 2.0 and saying Wyam is .NET Core ready. Right now Wyam is only tested on .NET Framework (though we’re inching closer to .NET Core support). |
|
@daveaglick Is your port public? I'm going to continue hacking at this, and try and help you out a bit. |
|
Awesome! 👍 yeah, everything in dotnet-serve is oss and my PRs have been merged |
@RLittlesII as far as I know, ASP.NET Core is supposed to replace OWIN. You can self host using Kestrel, and ASP.NET Core's middleware API is roughly based off OWIN's |
|
So what's the deal with using Tabular?
The last version came out 7 months ago and before that the last version was in Oct 2014. This project seems mostly dead and, as far as I can tell, is not hosted on GitHub, or anywhere public, and does not have a specified license associated with it. Proposal: Switch to EPPlus and CsvHelper. I have used these for multiple projects and have been very happy with them. Also, Tabular.Excel actually depends on EPPlus, so even they like it. CsvHelper and EPPlus both are
@daveaglick If you agree, I would like to replace Tabular with EPPlus and CsvHelper. |
|
@MisinformedDNA That would be awesome - haven't looked too closely at that one yet, so if swapping out Tabular for one of the other libraries is doable, a PR would be great. |
|
Cool. I'm on it. |
|
Took a look at Rant and he has no plans to support .NET Standard. As far as I'm concerned, that's equivalent to saying that the project is dead. So we either we do the port for him or fork it or we deprecate the @daveaglick Any thoughts on how you want to handle this? |
|
@MisinformedDNA Almost certainly deprecate it. It's a fun little module that produces life-like text following user-specified patterns, but AFAIK it never had any real use cases and no one is using it in production. I guess in theory it would have been used for mock-ups and placeholder text, but there are plenty of online generators for that. |
|
@MisinformedDNA BTW, thanks for jumping in with all the help recently. I've been off on a little tangent but my focus is back here now so I'll hopefully start reviewing PRs and finishing the push towards .NET Core in the next couple days (or next week at the latest depending on how soon I can get some OSS time). |
|
"little tangent" :) |
|
Getting closer everyone! @MisinformedDNA has helped unblock our remaining modules and @RLittlesII is helping with Wyam.Hosting which is the last remaining core library. The client story is coming together in #668. I'm going to focus on some bug fixing before getting another release in the 1.x line out the door later this week or next and then that'll probably be it until 2.0 betas (unless other major bugs crop up in 1.x). |
|
An update (I know it's been a while):
I'm going to do a release in the next couple days (maybe even later today) with the updated Wyam.Hosting and Wyam.Razor bits. At that point every supporting library will be targetting .NET Standard. The only thing left is the client. I have big plans for how Wyam should work in the future (#668), but I've decided to scale back Wyam 2.0 and make it a straight .NET Core release of what we've already got to get it out the door sooner. I expect the existing client won't take long to port (there isn't that much there) so expect a final Wyam 2.0 release with full .NET Core support in the coming weeks. Then I'll start working on the vNext client story for Wyam 3.0 - and I really hope that doesn't take as long as this did. |
|
Wyam 2.0 was just released, very happy to finally close this issue |
|
Congrats Dave, and everyone involved on making this happen. Very impressive feat. |
Converted to netstandard2.0/netcoreapp2.0:
Clients
2.x client strategy is discussed in #668
Core
Extensions
Recipes
Client Tests
Core Tests
Extension Tests
Integration Tests
The text was updated successfully, but these errors were encountered: