ANNOUNCEMENT: New maintainers wanted

[kevinkuszyk]

Some background...

@wwwlicious and I started this project with the support of @davidebbo back in the in the heady days of the K runtime, DNX, and the MVC 6 betas. Things were moving fast and we were unable to keep up with the changes.

We have some working code from the ~beta4 timeframe. Since then there have been many changes to the framework. Most notably for this project the ICompileModule hook was dropped at some point.

Where next?

Due to time constraints and other commitments @wwwlicious and I haven't had the time to dedicate to this project to move it forwards. Today we are officially asking for new maintainers to take it forward.

Please post a comment here if you're interested and I'll give you push access to the repro. Later I'll open admin access to the new maintainer(s).

Thanks to everyone who's shown interest in the project to date.

[wwwlicious]

For those interested, I think this project requires source generators which implements a package Microsoft.CodeAnalysis.SourceGenerator which afaik is not publicly available on any package feed yet.

[benjamin-hodgson]

Here at Stack Exchange we've built our own bit of infrastructure that provides more or less the same API as Roslyn's ICompileModule stuff used to. It might be fairly straightforward to port R4MVC to StackExchange.Precompilation, although since StackExchange.Precompilation is basically a separate executable which wraps Roslyn, it would mean users would have to be willing to use our executable in their projects. What do you think?

[artiomchi]

I've used T4MVC for a long while now, and am an avid fan. I'd like to contribute to the project, and help with the MVC Core support.

I spent some time mulling over the whole thing (starting with upgrading this project to the new .csproj format), and this is what I came up with so far:
I can see why the removal of ICompileModule has stalled the project, but I believe there's a much simpler way to achieve the end goal here. So far I've got two (working) options:

1. Run the code generator automatically before each build. This can be achieved by running it as a before build script. It's far from a perfect option (I only started today, and there are some drawbacks). As such, if that's even needed I'd leave it as an optional, secondary configuration. For reference, here's a snippet from my local prototype:

  <Target Name="T4MVCCore" BeforeTargets="Build">
    <Exec Command="&quot;$(MSBuildProjectDirectory)\..\..\src\T4MVCCoreLiteTool\bin\debug\net462\T4MVCCoreLiteTool.exe&quot; &quot;$(MSBuildProjectDirectory)&quot;" />
  </Target>

2. Run the generator code on demand, when the developer needs it (in a way, that's what we have to do with T4MVC anyway). This can be easily achieved with a Powershell command registered as a tool. Same as the EF Migrations can be created using the Package Manager Console in VS by running Add-Migration. Except in this case it would be Update-T4MVCCore

Both options would require a compiled executable that contains the generator code.

---

I've decided to toy with a prototype to check the feasibility of the project, and so far it is quite successful. The prototype consists of two projects:

• T4MVCCore - this is similar to the T4MVCExtensions project, has the base IT4MVCCoreActionResult, extension methods, etc
• T4MVCCore.Tools - This is the generator nuget package that will be installed on end projects, and will provide the code generation functionality. It contains a executable that has the code generation, as well as the powershell scripts to register it as a tool and the optional pre-build MsBuild Target.

With this in mind, I'd suggest renaming this project to T4MVCCore. The main reason for that is that it makes it much more easily discoverable (similar name to T4MVC, will be found in search results when searching for it, and easily identifies as the package for ASP.NET MVC Core). Compared to that, R4MVC is unknown, and while it technically does use the Roslyn code analysis tools, it's by far the least important feature of the project.

---

So far I have a very basic prototype that I started several hours ago just to test the theory. Going forward, I'd merge the general principles of what I have so far with the R4MVC source, since it already contains a good chunk of the groundwork.

Looking forward to your feedback, would love the opportunity to help with the project

[artiomchi]

@benjamin-hodgson First of all, love the great work that Stack Exchange is doing!

I've only recently stumbled upon the StackExchange precompiler, and while I'm considering using it in some projects, I don't think that tying T4MVC/R4MVC to it is a great idea, for the same reason you listed. I think an alternative way to trigger the code gen would be much better, as I outlined above

[artiomchi]

Oh yeah, I forgot to mention. The new project format is different, the file nesting is now happening automatically, based on the filename.

As such, I think the best option here would be to keep the .generated.cs controller files next to the controllers themselves. This way this solves the issue of all the .generated files being visible in the project.

One thing I didn't mention was the TagHelpers to generate the anchors in the razor files, but that's a trivial task. I'd probably create a <a mvc-action="…"> tag helper, which won't clash with the current asp-action tag helpers

[kevinkuszyk]

@benjamin-hodgson @artiomchi thanks for your comments.

I'd be reluctant to take any external dependencies for the hook to invoke R4MVC. I was thinking it should move to exposing a dotnet cli command, something like dotnet r4mvc generate or similar.

This would have the advantage that it's xplat, cli / build server friendly and can be built on in VS / VS Code etc.

@artiomchi re. renaming the project. I take your point. Let's leave it as is for the moment. That gives some time to think it through before we publish the first beta on NuGet. We all know how hard naming things can be!

I just updated the App Veyor config to use the VS 2017 image. If you're able to open a PR early then we will get some CI feedback on it. A good start would be updating the solution to VS 2017 and MVC Core 1.0 so that it builds again. Once that's done we can take contributions again and hopefully get a working beta out.

[artiomchi]

@kevinkuszyk Sure, makes sense.

Also, I've been digging more into it this weekend, and I have some bad news and some good news. My initial plan was to go the cli / powershell route. I started with removing the dependency to the ICompileModule and just using the CSharpSyntaxRewriter to do the job. It would only work for restricted scenarios, with massive limitations since this would only analyse the syntax, but can't get the runtime details of methods (so I can't get the namespace of any classes passed as arguments to actions, for example).

As such, the only way to get this to work is to init a Workspace and run the project through the compiler to get these results. Which is definitely possible, but would be a heavier process.

A simpler option would be to write this as a VS extension. From the context of a VS extension I can get access to the VisualStudioWorkspace instance, so I can get the same runtime analysis without having to start an out of process compiler - should be considerably faster, but requires a VS extension.

I've also peeked at Code Analysys extensions, which can be brought into a project through NuGet, but I don't think there's a simple way to trigger them to change the files. I'll take a deeper look into this, and what powers them.

Now to the good news - since with RTM Microsoft brought back the .csproj format, T4 templates are working just fine! So the simplest solution would be to just upgrade the t4 template that is used in T4MVC, and just use that. It will be comfortable and familiar to use for existing users of T4MVC, and you can have a (at least partial) code reuse between the projects.

This is what I concentrated on in the last couple of days - analysing the existing t4 template. Currently it hangs when being triggered against a ASP.NET MVC Core project, but it's just a matter of time until I get it working.

In any case, I've made some changes to the R4MVC codebase with an upgraded project structure and it's compiling against the latest runtime, but it doesn't do much of course. I'll commit my changes anyway to my artiomchi/R4MVC fork

I've started some experiments with a clean project at artiomchi/T4MVCCoreLite to test some concepts before I apply them in the R4MVC project, so you can see what I was talking about. I've added Lite to the end of the title just to separate it in my project list, and to indicate it's far from the full solution :)

The T4MVCCoreLite project is basically the future rewrite of T4MVCExtensions, the T4MVCCoreLiteTool was supposed to the the cli / PowerShell command, but would have to be upgraded to start a new MsBuildWorkspace. The TestMvcApplication project is a clean MVC project when I just pasted the .t4 template (or was running the tool project against), and is my current experiments target.

P.S. You have a good point about the cli route being build server friendly, but since generating T4 templates is a design time task, I think it's not important at all, since all the generated files have to be created in advanced and committed to the repo for the project to compile in the first place.

Compatibility with VS Code on the other hand is a very strong factor in this, which makes the cli option more appealing. The nice thing is that cli / VS Extension would use (mostly) the same codebase. As such, both of these options can be provided with almost no extra effort at all. The cli option would be made available through a Nuget T4MVCCode.Tools package, and if the VS extension is installed (completely optional), the regeneration task could also be accomplished from VS, and would also be slightly more efficient.

---

To be perfectly honest, I'm OK to continue with either path that you think would work better (cli that starts a MsBuildWorkspace / VS Extension / T4 template), and I've got some experience with each of them, so I'm confident that I can bring at least some help to the project. I look forward to your thoughts on this.