Closed heaths closed 6 years ago
I would like to offer help improving this one and wondering if you'd accept changes to put this in line with modern projects' needs
@heaths I'd be interested in helping move this forward too. I've managed to port the project and have it building and running as a .NET Core 2.0 App, with code generation working. I've also done a spike with Roslyn integrated and while I'd love to discuss and submit a PR, I fear that I'll be falling on deaf ears given that you and @gyorgygulyas haven't gotten any response. Would you be willing to collaborate meanwhile on a fork until perhaps @mhutch gets a chance to catch her breath? The work can eventually make its way in here should it make sense.
I've submitted the trivial PR #9 to see if this thing's even on. If that gets merged then I know there's life and hope here. 😄
Sorry I haven't had much time to review & merge contributions recently.
I would definitely be happy to have this functionality as part of the project. Just need to get a CLA bot set up before I can start merging stuff.
I would definitely be happy to have this functionality as part of the project.
@mhutch That's good to hear. Meanwhile, this weekend I went ahead and worked on a fork called T5. It's working on .NET Core 2.0 using Roslyn's C# scripting to compile and run the generator. It's working perfectly against some simple templates (see Fold.g.tt
and ToDelimitedString.g.tt
from the MoreLINQ project). I have also cleaned-up/simplified the project organisation, added build scripts for Windows & Linux, including CI on AppVeyor & Travis. The TextTransform assembly is also setup to run via dotnet
CLI extensibility. I am almost at the point of pushing out a v1.0, or at least a beta pending some documentation.
The main reasons I went with a separately named fork are:
My goal was to get it on .NET Core and look forward, especially because, presumably, many details would have to be different (especially assembly references) and I am not sure x-plat templates is a possibility or even an interesting problem to solve. That all said, I am one who is against a single-weekend sprint (or hero efforts although T5 hardly qualifies as one) only to abandon the project downstream when one gets busy with other chores, so I'd rather team-up. Depending on how you see the roadmap for this project, I'd be happy to contribute interesting bits back or alternatively, we could develop T5 separately with the idea of porting back bits over time as lessons are learned and ideas for a .NET Core version are experimented/solidified there. Thoughts?
I don't want to drop Mono/.NET support. However, I'd be very happy to merge .NET Core / .NET Standard support into this repo.
I'd also love to add additional support and features:
dotnet tt
, maybe a global tools package)dotnet new t4 -precompiled
etc)I set up some infrastructure on this repo to kick things off:
msbuild /t:Pack
I filed / renamed a bunch of issues to track the various pieces:
#6 Support running on .NET Core #13 Make precompiled templates compatible with .NET Standard) #10 Add dotnet tool package #11 Add global dotnet tool package #11 #12 Add MSBuild targets package #12 #14Add file template package for tt files
With the Microsoft T4 engine not on NuGet, a lot of project templates are made more difficult because of insufficient or overly specific (e.g. XDT) transforms. But a lot of projects need it. I often write PowerShell cmdlets where the module manifest (.psd1 file) benefits from transforms such as short commit ID or version.
I would like to offer help improving this one and wondering if you'd accept changes to put this in line with modern projects' needs. This project is a great start and alternative to Microsoft T4.