Moving T4MVC extensions to an assembly

Coordinator
Jul 7, 2012 at 4:58 PM
Edited Jul 7, 2012 at 5:02 PM

The way T4MVC works today is that the T4 template generates various helpers that are always the same (in addition to the project dependent things it generates).

This has been problematic in some cases when you have multiple projects that use T4MVC with different assemblies that end up in the same web app.

We used to generate the helpers as internal, and later changed them to public, but in either case it causes issues.

So the proposal is to move those to a separate assembly that will be included in the NuGet package, which will solve the sharing issue.

Please let me know what you think about that option.

Related threads:

Jul 7, 2012 at 7:58 PM

I'm absolutely for it but let's hear others too.

Jul 8, 2012 at 6:35 AM

I think this is a reasonable update. Html/Ajax helpers should be separated from the rest of the project.

I am not sure about ModelUnbinderHelpers since I did not really get a change to use these anywhere yet.

Coordinator
Jul 10, 2012 at 11:53 AM

Yes, it would apply to the new ModelUnbinder code as well.

Jul 10, 2012 at 8:37 PM

Sounds great!

When do you think these changes will be rolled out? I don't want to rush you or anything, I'm just very excited about these changes :)

Coordinator
Jul 11, 2012 at 9:17 PM

Sorry, I'm on vacation for a while, so I won't have time to do this till maybe August. However, you're more than welcome to start working on that and send a pull request! :)

Jul 24, 2012 at 6:47 PM

I did try to understand how your project is set up, but it is a bit over my knowledge. I can probably mess with the T4MVC.tt file to make it split generated code into two separate files. Let me know if I should try and do it or if this will be implemented some other way.

Coordinator
Jul 31, 2012 at 12:57 PM

The idea would be to take all the code that's under 'if (GenerateMvcT4Extensions)' (there are a couple blocks), and move it to its own assembly. Then that assembly would come as a regular DLL in the T4MVC NuGet package so that the logic is available to projects that use T4MVC.

One difficulty is that there is a little bit of conditional code generation there (e.g. search for GenerateSecureLinksInDebugMode), and we'll need to find a way to get rid of that.

Related thread here.

Sep 16, 2012 at 11:56 PM

David,

I got really close to the point where I could make a pull request with the change regarding the issue from this thread. However, I'm running into a weird build error, that I can't figure out. You think I could email you the updated solution for you to take a look at it?

Coordinator
Sep 17, 2012 at 12:12 AM

Rather than email it, can you just push to a branch (in a fork) that I can look at?

Sep 17, 2012 at 12:55 AM

Haven't done this before. Now, trying to follow directions on CodePlex... using TortoiseHg to pull the fork repository to local folder, but keep getting 404 error. I never saw a place where I'd set up my username and password. Probably that's the problem, but I can't figure out where I'd enter them. Any guidance is appreciated!

Coordinator
Sep 17, 2012 at 1:02 AM

The T4MVC project is using git, not Mercurial, so TortoiseHg is not going to work :) I know it's confusing, as it previously was part of MvcContrib, which uses Hg. If you haven't used git, it's worth going through some tutorial to learn the basics. It's used more and more widely, so I think it's a good time investment that will pay off for you later in other projects! :)

Sep 17, 2012 at 7:05 AM

All right, I think it's all in the fork now and you should be able to see the changes.

I have created a new project T4MVCExtensions, where I have placed all the html extensions and model unbinder stuff. For simplicity sake I have referenced that new project in T4MVCHostApp Project. However, when I try to build it, it does not see the interfaces that I created T4MVCExtensions project.

Please see if you can make sense of this and if changes that I made are appropriate.

PS Let me know if you can actually see the changes I made in the fork... perhaps I didn't create it correctly.

Sep 17, 2012 at 8:56 AM

Yeah, well, it's unfortunate everyone is switching to GIT, since Hg tools are so much better on Windows and especially Visual Studio integration. GitHub's application is light years behind TortoiseHg+VisualHg combo.

And that's one of the reasons I still didn't fork this project because I feel completely lost when opening up that new Github client for Windows.

Are there any alternatives, David?

Coordinator
Sep 17, 2012 at 9:36 AM

@cactusss: I see your branch, but it doesn't look like you pushed any changes to it yet. You may just need to 'git push' to your fork (after committing).

@markoh: I'd rather avoid sidetracking this thread with a git vs Hg debate, though we can start a separate one for that :)

Sep 17, 2012 at 9:51 AM

David,

Please take a look again. It might take me a few to get it right. Hopefully I got it this time though.

Coordinator
Sep 17, 2012 at 2:37 PM

Looking at this page, I still don't see your commits. :(

Sep 18, 2012 at 4:06 AM

I'm out of ideas...

I downloaded git, set it up with my email address and name, clone the fork using the git url on it... edit stuff up, and it shows in pending changes. Then I select all my changes, press commit and it looks like it's going, but when I check here I do not see any of my changes... perhaps an email would be easier. Unless I'm missing something really stupid.

Coordinator
Sep 18, 2012 at 7:45 AM

You need to push after committing (in that sense it's exactly like Mercurial). You may want to run through some basic git tutorials (e.g. this one), as DVCS can be confusing if you're new to them.

Sep 18, 2012 at 8:07 AM

Thank you so much for being patient with me. It's in now.

Coordinator
Sep 18, 2012 at 4:43 PM

I think the problem is that your library targets Fx 4.5. You should switch it to 4.0.

Sep 19, 2012 at 5:07 AM

Fixed that issue as well as one more... changed System.Web.Mvc reference from 4.0 to 3.0.

I think it only now needs your final word. Should I do a "pull request" or what's the process for this?

Coordinator
Sep 19, 2012 at 5:27 AM

Great! Yep, I think that's the next step. It would be good if you could also describe whether there are any catches that users will need to be aware of. e.g. Some options like ActionResultInterfaceName go away, and maybe that's not a bad thing :)

Did you get to test it well in multi-project scenarios where the library is used by multiple projects?

This is a pretty fundamental change to T4MVC, so I think it might be justified to call it version 3.0. We might start with a beta so we can get feedback without breaking too many people. We'll also need to update the NuGet package to include the assembly.

thanks!

Sep 19, 2012 at 5:36 AM

I see. I didn't test it well yet. Let me do that before I make that pull request. Indeed I have enough projects to test it with. After this is tested well I'll write up the list of changes and let you know. That might take a week or so.

Coordinator
Sep 19, 2012 at 5:38 AM

That's ok, it's an important change and we don't need to rush it. But I think unless we run into some unsolvable issues, we'll definitely want to get that in. It's a great step forward. Thanks for driving this change!

Coordinator
Oct 31, 2012 at 6:02 AM

This change in now is, thanks to @cactusss!

See here for details. Currently it's a NuGet Beta package (T4MVC.3.0.0-beta). I figured the change was fundamental enough to call it 3.0. Beta means you need to choose 'include prerelease' to see it in NuGet.

T4MVC users: please try upgrading to this beta package to make sure it doesn't break you in unexpected ways!

Nov 5, 2012 at 6:53 PM

David,

so if one wants to just get T4MVCExtensions reference in his project (not the whole thing), how would one do that? I can't find T4MVCExtensions in nuget.

Coordinator
Nov 5, 2012 at 6:57 PM

Hmmm, good question. So maybe we need to split them into two packages:

  1. T4MVCExtensions: just the assembly
  2. T4MVC: the T4 template, plus depend on T4MVCExtensions package so you get everything

Would that work?

Nov 5, 2012 at 6:58 PM

Sounds great to me!

Nov 5, 2012 at 10:58 PM

Yeah, splitting it up in two packages would be great!

Coordinator
Nov 8, 2012 at 1:43 AM

I have pushed T4MVC.3.0.0-beta2 to NuGet. Can you guys please give it a try to make sure nothing bad happens? It now depends on a new T4MVCExtensions package.