What is the point of using attribute routing then storing lots of constants in a separate file?

[PonchoPowers]

It makes more sense to me to include the constants inline just before the actions.

[RehanSaeed]

We use constants because using strings everywhere is bad practice. If you rename a string in one place, you have to hunt around for all the other copies and change them too. Using a constant lets us use the rename feature in an IDE.

[PonchoPowers]

That wasn't the question, the question was why not define the constants inline with the actions? I get that using strings everywhere is bad practice as I am a seasoned programmer. I would group the constants with the actions so that if you remove an action all the code is together, there is no need to create separate classes to store these constants as on a large website the classes will just become a nightmare to maintain.

[RehanSaeed]

It seems I have misunderstood. It's personal preference really, there is no correct answer. I use StyleCop, so I can't add a constant just above the action but I can add it at the top of the class. Also, controllers tend to get quite large if you have a lot of actions, even if you use something like a command pattern. Quick comparison:

public class FooController : Controller
{
    public const string GetBarRoute = ControllerName.Foo + nameof(GetBarRoute);

    [HttpGet("", Name = GetBarRoute)]
    public IActionResult GetBar() {}
}

public class FooControllerRoute
{
    public const string GetBar = ControllerName.Foo + nameof(GetBar);
}

public class FooController : Controller
{
    [HttpGet("", Name = FooControllerRoute.GetBar)]
    public IActionResult GetBar() {}
}

The choice is yours.

[PonchoPowers]

I've found a good alternative which I think will benefit both the cleanliness and the robustness of the boilerplate and solves the problem of making it a matter of user preference, I'm wondering what your thoughts are on the following solution:
https://github.com/T4MVC/T4MVC

If you like it I can integrate it and create a pull request.

[RehanSaeed]

T4 is interesting but it's not cross platform, does not work on VS code and may be replaced by another C# based scripting language who's name I can't remember right now. A T4 expert raised an issue you can search for in this project suggesting the same thing, the verdict was that we would wait and see what Microsoft does before committing to adding it as a feature.

[RehanSaeed]

http://daveaglick.com/posts/announcing-scripty

[PonchoPowers]

Can we reopen this and I'll look at a way to integrate Scripty so that it does a similar thing to what T4MVC is doing?

[RehanSaeed]

Scripty doesn't work with .NET Core based projects yet (See daveaglick/Scripty#30)

You also want to read this issue (#66). @mcquiggd put forward T4 as an option a few months ago. Sayed Hashimi (Microsoft developer) didn't know what the future of T4 would be because there is too much stuff changing.

This whole area is in a state of flux. I think we just need to wait out the storm and see what tool to use when things have settled. Scripty sounds very promising though.

[PonchoPowers]

Given what you have said, sticking to constants seems to be the safest option for now. Thanks.

[RehanSaeed]

I'm keeping an eye on it but if I miss any new developments, feel free to re-open this issue.

[mcquiggd]

Just to add a little to what @RehanSaeed has already stated:

1. Although T4 is available and supported in Visual Studio 2015, there is no built-in support in VS Code.
2. T4 is actually available cross-platform, and has been for years. It is supported by Xamarin Studio, has a Mono implementation etc.
3. There is already an open source project that enables T4 to work with .Net Core.
4. However, Microsoft have put zero effort into this, and do not guarantee any level of support. There is some talk of revisiting this, and possibly creating a Razor based code generation engine; in fact - indeed, once again, an open source project to do this already exists, but Microsoft don't seem to see code generation as any sort of priority at all.

I personally have invested a lot of time and effort in this, but with .Net Core tooling in a constant state of flux and no buy-in from Microsoft, I am staying with what I have right now with existing T4 support. Unless there is a concrete commitment from Microsoft on code generation, I will probably just continue to support my own T4 projects and maintain my own engine and runner.

I don't want to pollute MVC Bolierplate with further discussion on this topic (not being rude, but we have covered this topic pretty extensively) @RehanSaeed - maybe best to close this thread.

[RehanSaeed]

@mcquiggd Thanks, this issue is already closed. This is a new issue raised by someone who has very similar ideas to yourself. Out of curiosity, have you looked at Scripty yet? Looks very cool, seems like another possible option if they add xproj support but too soon to tell.

[mcquiggd]

@RehanSaeed

Yes I have - and I might contribute. There are a few others... @sayedihashimi - maybe Microsoft would consider creating a spike on GitHub as a focal point for the community re: Code Generation... ? Just a suggestion that might reduce duplicated effort... and lead to something at least semi-official.

And actually .xproj is going away, with a return to .csproj and MSBuild:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

Always fun with .Net Core... :)