I usually have a companion class library project for all the code for my MVC web project. The class library has extension methods, action filters, initialization code, etc.

I've been wanting to also move my controllers there, but haven't been able to because of T4MVC. Specifically, the class library project cannot reference the T4MVC code-gen output, as it resides in the web project. I also cannot move T4MVC.tt to the class library project as it then finds no views.

If I were to come up with a solution, it would likely be to introduce configurable base paths for source and view/static files, allowing either of those to be located in a project different from the .tt file.

I'm not sure if this would work for the source files too, but at the very least I would like to be able to have stuff like IT4MVCActionResult emitted elsewhere, so that one can define services or other logic that consume them. For instance, I recently added a mail-sending service that included a bunch of links, and would have liked to pass these in as action results. Because of the T4MVC code location I had to pre-format these to URLs before passing them on to the service layer.

Please let me know if you've run into the same problem or have an opinion about the suggested fix.

I'd also appreciate a heads-up on whether the suggested solution is something that might get merged into T4MVC itself, assuming that it is purely opt-in and configurable.

I think this is something that has certainly come up a few times. From a quick search:

• T4MVC in multi-project solutions
• T4MVC support for controllers in a separate assembly
• T4MVC with separate view and controller projects

The third one claims to have some solution to the problem, though I haven't read through the details.

But anyway, quick summary is that it's something that indeed could use improvement in T4MVC :)

The third one seems to have implemented something akin to my own thoughts - nice link. He does say that the solution isn't how he'd expect it to be done in T4MVC, but then never points to any downsides of his approach. From what I can tell the required changes are fairly simplistic and straightforward to apply.

If I grab his changes and merge them into the current T4MVC, would you consider including them? It'd probably be wise to skim his solution before answering that :) 

If you think you might, how would you like the code served? repo to pull from, full file or patch files? (please also specify repo or patch file type, depending on your answer)

Definitely, if you send a pull request with the change and it looks safe and non-breaking, I'll get it in! I had said the same to the post author is the issue, but didn't hear back. I pointed him to this thread in case he wants to shine in. It'd be interesting to know if he's still using that and ran into any issues.

Great! I'll see if I can reach the other guy for comments before pursuing this, but I should be able to have a look at this some time next week. I'll be back...

I've grabbed Geoff's changes and applied them to the latest version of T4MVC. It looks like it works, but failed in my use case because of duplicated view names. I'm not sure exactly why this might be, as I didn't really touch the views, but am suspecting that its a scoping problem of some sort.

The biggest problem is actually working with the template - there's just too much going on inside a single file for me to wrap my head around it. It would help immensely if the template relied on a GAC-installed helper assembly instead of having code-generating bits intertwined with settings and core logic and IDE interaction. So, full circle :)

I may return to this eventually but am shelving the idea for now. The changes are fairly simple and probably easy to fix for someone who already understands how the template does its job (hint, hint ;), but I am not confident that I would be editing it in the right places.

Thanks for trying and reporting back. Indeed, I can see how the template is a bit overwhelming.

Can you push your changes to a fork, for future reference?

Hey guys, Geoff Hudik here - I wrote one of the posts mentioned above for this topic. As an FYI I updated the template today (and the post) to handle resolving the views project when it is contained in one or more solution folders; previous logic only handled top-level projects. Also I changed static file processing to use the views project.

I'm not seeing the duplicated view names on my end but I can maybe look into that later. Stepping through the debugger is a huge help with tackling the T4 along with Tangible's T4 editor.

http://www.geoffhudik.com/tech/2011/10/31/t4mvc-with-separate-view-and-controller-projects.html

Gah... I should probably add that I didn't reapply my changes to the current T4MVC.tt so it wouldn't include any recent changes made to T4MVC.tt. Maybe later.