5

I have written a few razor helpers and these helpers use functions that include the extension methods generated by T4MVC. I now want to move these to a control library so that they can be used across multiple mvc applications. The initial idea that I have used is that I can put a copy of the template into the control library, and this works, the downside is that the template used in the application then regenerates the same extension methods in the same namespace. Because I am using some of the extension that require the interface for the ActionResult I do need that the namespace remains the same.

What I am wondering is, is there a known way to use the extensions in a control library as well as an application that references the library, or is a change to the template required such that the static extension methods can be either generated or not via a flag in the settings file? I am also wondering if the static extensions could be included in a separate cs file that lives along side the template. So that we have 2 classes T4Extensions and DynamicT4Extensions?

This might force the use of the interface IT4MVCActionResult though,

tereško
  • 58,060
  • 25
  • 98
  • 150
Dewy
  • 153
  • 5

1 Answers1

2

This is similar but not quite the same as http://forums.asp.net/p/1510753/3603100.aspx.

I wonder if the solution might be to add a new switch in the settings file that would turn off the generation of those static methods. So if you know you're already getting them from some referenced assembly, you'd turn them off in the app.

Though that might still blow up if you have multiple unrelated libraries that each need to use the methods, as the app would then get an ambiguous reference.

Note that we can't make the methods internal, since some of them need to be called from views, which live in different assemblies.

And ideally, I'd prefer to avoid having those in yet a separate file, as some users may start complaining that T4MVC brings in too many files.

Sorry, not really a clear answer, but more thinking through possibilities. :)

David Ebbo
  • 42,443
  • 8
  • 103
  • 117
  • I think the switch would work well and would satisfy my needs at least. As for having the references in many unrelated libraries, they would become related as they would all be using the same interface and so they would have to have at least one common reference which is where the methods would have to live I think. Also, the extra file, is it really a problem until someone says its a problem, I think having 3 files in fine for the power of what people are getting, but that is just one person opinion. What is the next step? – Dewy Apr 07 '11 at 19:29
  • Maybe you're right that having an extra file is not big deal. We could also consider putting all those files in a T4MVC folder instead of having them at the root of the app. Next step? I guess I need to find the time to work on this :) – David Ebbo Apr 08 '11 at 06:38
  • I just published T4MVC 2.6.50 which adds a new GenerateMvcT4Extensions flag that you can turn off in the settings file. Please try it and mark this response as answer if it works for you. – David Ebbo Apr 08 '11 at 07:29
  • Note that I decided against adding a new file right now as it would have been a bigger scope change (it can be considered later). – David Ebbo Apr 08 '11 at 07:36
  • Hi David, I think we still need a few changes. The Dummy Instance is getting generated in both the library and the web application. It compiles but it is issuing warnings. In my scenario, the MVC class that is generated within the library is empty and was causing conflicts until I realised that you can change the name on this to something else. Might be worth making this more obvious on the release note. (Maybe not, I am new to tinkering with the settings!) – Dewy Apr 11 '11 at 10:07
  • The main problem that I have is that the InitMVCT4Result method won't append the Area line of code as there is a condition that there must exist at least 1 area within the containing app, and as there are no areas within the library it doesn't get added, but there are within the containing web application. This means that links don't work. I take it that having this line in when there are no areas will cause problems? – Dewy Apr 11 '11 at 10:07
  • Its easy enough for me to add an areas folder and a dummy sub folder, in the library, but it would be nice if I didn't have to do this – Dewy Apr 11 '11 at 10:11
  • Since you have things set up that way, can you try to make the changes that you think are right and then email me the modified files? Thanks! – David Ebbo Apr 11 '11 at 20:47
  • Sent an email about this. BTW, not sure where to ask this: Do you know if there is any plans to allow generic helpers? It seems kinda crap to have loads of code to allow generic View Models, to then say its kinda hard to figure out if its generics or html in a call to a helper. Not sure who to ask this to. So feel free to ignore – Dewy Apr 12 '11 at 18:14
  • just run into exactly the same problem. I have my custom extensions to html helpers in a separate solution. I then reference that solution in my other projects making these helpers available in all my projects. In order to use T4MVC I had to write in that reference project some more html helpers that would use html extensions from T4MVC.cs. Now I have T4MVC.cs in both reference project and actual application project, which makes it complain about ambiguous references for multiple things. Have you came to a solution for this issue? – Dmitry Efimenko Jul 06 '12 at 07:16
  • Please see this related thread to discuss possible changes: http://t4mvc.codeplex.com/discussions/362362 – David Ebbo Jul 07 '12 at 17:05
  • This change is now in beta! Please verify that it works for you. See http://t4mvc.codeplex.com/discussions/362362 for details. – David Ebbo Oct 31 '12 at 06:05