Code52
Run Pretzel under .Net Core?
This is more an alternative to #81 - instead of trying to support running on Mono, maybe go for .NET Core instead? You'll get the same ultimate goal (cross-platform) and you can keep it to a single code base (instead of having a .NET version and a Mono version).
Just a thought for an old, loved project that seems to have had some recent work. :)
I would love that, but it will need a lot of changes. That does not mean that will never happened, but not before a long time 😞
Do you mind if i fork it and push it over to core and release as a global tool?
I would love to see that! 😄 It has been in my work list for so long but never had the time to do it.
@laedit My plans are: bringing to dotnet core as a global tool and switch to azure devops.
You mean replace Appveyor by Azure devops? Do you know if it is possible to have an account for a Github organization? I'd prefer to avoid user-specific account to prevent any future issue to access it. I am trying to activate Github Actions but since I am not an admin I don't have access to the settings of this repo.
I am trying to activate Github Actions but since I am not an admin I don't have access to the settings of this repo.
@laedit apologies for that, I should have done it a long time ago. I've given you admin rights to this repository now, let me know if there's anything else you need.
@laedit Did not use Github actions so far, but for open source it would be a nice fit! Any suggestions on Microsoft Composition? Move to dependency incjection from dotnet core hosting model or to Microsoft.Composition (which seams dead). I'm currently trying to port to netstandard, but this seams hard so far. (got it compiling and tests running, but composing the catalog fails cause the lack of InheritedExportAttribute that is heavy used)
@shiftkey wow, I was planning to contact you but I have forgotten that you are omniscient 😄 Thanks a lot!
@biohazard999 I must confess that I haven't peek at the code for a long time, but I think that InheritedExport is used mainly for extensibility, so if that is the only major change we can remove it and contact every known plugin creators to inform them of the change.
And if it is impossible to migrate to MEF2 we could move to another dependency injection lib.
@laedit i think the codebase is good and it would be a shame to abandon the project. I look into migrating to MEF2 to move to project forward, but the long term goal to go to Microsoft's new DI would be a nice addition!
My main focus is to move it to an global tool first, and do afterwards some features as required.
@laedit can you look into the PR #328? I've tested and checked every command, and works (at least with my blog). Although the build is failing it seams like a problem with GitVersion in the install script on the build server. I don't know if I can fix this somehow?
@shiftkey sorry to bother you, I have access to GitHub Actions but it seems that I must be owner of the organization to activate it on pretzel. Can you signup for GitHub Actions for Code52? Thanks!
Cause the lack of support of many dependencies (AjaxMin, DotlessClient/Server, Aspnet.Razor) are we going .netcore only? Or do we prefer to keep .net451 as a minimum target and do #if NETSTANDARD?
I'd like to keep a full .net target for Chocolatey (net451 or later if it simplifies things), but the functionalities should ideally be the same with the netcore target.
So I think we should replace there dependencies by other that supports netcore, like WebMarkupMin.Core for minification, dotless.core for dotless and RazorLight or directly Microsoft.AspNetCore.Razor.Runtime for razore rendering, but it could be done in separates PR and do #if for now.
@laedit if we go at least net462 we can use a lot of the new stuff and still be full framework as well as cross plattform (aspnet core is >= 2.2) without writing tons of #if. The only thing is ScriptCS support. But I don't know how much usage there is 😉
Go for 462 😄
ScriptCs is used only to allow plugins from a .csx file. Since it does not support netstandard I think we could replace it by dotnet script or another solution.