I am trying to write a simple library for MVC2 projects that takes care of user login, e-mail validation, password recovery, etc. Since some of these steps involve user interaction, I need to have Views and Controllers in that project.
In MVC2 Preview 2, one could do this by abusing areas (at least, it seems) since they were implemented in different projects. However, in RC a new area will merely create a subfolder. Since I want to share the base code between applications, that is not an option.
I tried to brutally hack the AfterBuild steps into my project files, but that doesn't 'feel right' (I wouldn't sleep another night :)
Could you share some thoughts on how to do this?
This question might be a duplicate of Areas over multiple projects - Views not found in child projects
The build task to copy the views have been moved to the Mvc.Futures project. Other options to solve the problem include defining the views in the application, even when they are being referred to by controllers in the library. Also, the MvcContrib project offers portable areas.
A thorough explanation by Phil Haack can be found at http://forums.asp.net/p/1494640/3540105.aspx
Related
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
I've created a web app (mvc4) that I'd like to reuse in multiple projects. The site is an admin panel, but it may be extended and slightly modified in each project. I want to avoid copying the project over, because I'd like to be able to update each project to the latest version at the lowest possible cost.
So far I have tried 2 approaches:
a script that 'clones' the project by copying all the necessary things as well as altering others (guids in assemblies, namespaces and things like that) - this works fine for extensibility and modification, but that's just a copy so pushing 'updates' is a mess (I did it manually) and it does not scale.
portable areas from mvc contrib project - this seemed like a good idea at first, but it turns out that it's nice for simple scenarios, but fails at more advanced use cases. It doesn't support localization (from resources embedded in the portable area), bundling and min requires a lot of hacks (mvc contrib is still on mvc 3), it's not possible (out of the box) to reuse shared views or Display/Editor templates from the portable area and it looks like if I'd go further that way, some new things would come up
Currently I'm thinking about 'just' branching each project from the core one. This would of course require the same changes (or at least a big subset of them) that were done in the script I mentioned earlier, and I'm afraid that if I try to pull updates from the core project the number of conflicts will render the whole approach unusable.
Does anyone have an idea on how I could tackle this problem?
I'd suggest to create a NuGet package of the mvc app and reuse it. So versioning and applying updates would be much easier. However it takes a bit work to make your code completely isolated from the codes you want to add in the new project.
When building ASP.NET projects there is a certain amount of boilerplate, or plumbing that needs to be done, which is often identical across projects. This is especially the case with MVC and ALT.NET approaches. [I'm thinking of things such as: IoC, ORM, Solution structure (projects), Session Management, User Management, I18n etc.]
I would like to know what approach you find best for 'reusing' this plumbing across projects?
Have a 'master solution' which you duplicate and rename somehow? (I'm using a this to a degree at the moment, but it's fairly messy. Would be interested how people do this 'better')
Mainly rely on Shared Library projects? (I find this appropriate for some things, but too restrictive for things that have to be customised)
Code generation tools, such as T4? (Similar to the approach used by SharpArchitecture - have not tried this myself)
Something else?
Visual Studio supports Custom Templates.
I definitely (mostly!) go for T4 templates in conjunction with a modified version of SubSonic 3. I kind of use the database to model my domain and then use the T4 templates to generate the model and associated controllers and views. It takes about 50-60% of the effort out and keeps a consistency in place.
I then work on overrides (partials) of the classes along with filters and extension methods to 'make the app'. Now that I'm familiar with the environment and what I'm doing, I can have a basic model with good plumbing in place in a very short space of time. More importantly, because I create a set of partial class files, I can regenerate all I want without losing any of my 'custom' coding.
It works for me anyway :)
You could do it the bearded, t-shirted, agile style and create a nice template and put it in sourcecontrol. So when you need a new project, you just checkout the template?
For insanely fast MVC site setup, I use modified T4 templates (created with T4 Editor) and with ALOT of help from Oleg Sych's blogs for page generation (for your typical add/edit/index pages) combined with an awesome implementation of an automated create-update-delete called MVCCrud (if LINQ-to-SQL is your preferred data access method)
Using modified T4 templates and MVCCrud you can create fully functional entities (Create/Edit/List/Delete) with error handling and intuitive error messages in about 4 minutes for each.
I create a new project using the new project wizard so that I get unique project GUIDs assigned. Then I would use "Add Existing Item" to copy items from similar projects if it made sense to do so.
I sometimes use a file diff tool to copy references from one project to another, otherwise I just add the references by hand. A file diff tool can also be used to include similar source files, but the underlying files have to be copied anyway, so I prefer "Add Existing Item".
I've used T4 to generate solution and project files, but that definitely seems like an edge case and not something that would normally be necessary. In that case, I'd probably wrap the T4 in a PowerShell like script to create and populate the rest of the directory structure.
I use "shared libraries" pretty aggressively in general, but not specifically due to this scenario.
In general, I don't find myself reusing plumbing between projects much. It's probably more often that I hack away in one "prototype" project, then abandon it, and rebuild the project from scratch following the above approach and only bring over the "non-hacky" code.
I'm creating a MVC2 application template at http://erictopia.com. It will contain all the basic items I think should be in a MVC project. These include BDD specifications, an ORM (NHibernate and possibly Lightspeed), T4 templates, custom providers, ELMAH support, CSS/Javascript minifier, etc.
We are currently using the default folder structure for our MVC app, and were wondering if it is possible to instead put a Controller and its related views into the same folder.
For example, a subset of our current structure is:
Model folder
OrderViewModel.cs
Views folder
OrderView.aspx
OrderGrid.ascx
OrderHeader.ascx
Controllers folder
OrderController.cs
Desired:
Order folder
OrderController.cs
OrderGrid.ascx
OrderHeader.ascx
OrderViewModel.cs
OrderView.aspx
We have hundreds of actions/views, and they're currently grouped into too few controllers. This is partly because it becomes a pain to navigate around the project when flipping back and forth between a view and its related classes. The above solution would allow a developer focusing on one controller action to have all of them easily accessible.
I guess Areas could help with this too, but we'd have to make ~100 areas (one per set of closely related screens) to make this useful from my team's POV.
The default controller factory uses reflection to find all classes that derive from Controller, so no matter in which folder you put them, as long as they are public and derive from Controller it will work. But IMHO mixing views and controllers into the same folder is not a good idea. If it is a matter of organizing your controllers why not create subfolders in the Controllers folder?
I'm not sure that diverging from convention is a good idea, as people are probably used to the standard folder layout - but I do feel your pain.
Navigation between files would be less painful if Visual Studio had some more of the features found in IntelliJ IDEA.
The fact is, pretty much any folder structure will degrade over time, as more files are added to the project, and better tools are usually a more efficient solution to the problem.
To be fair, it looks like VS2010 is starting to take some of the IntelliJ ideas on board, so things will probably improve - but there's a long way to go before Microsoft catch up.
EDIT: I forgot to mention that there is a plugin that provides lots more functionality for Visual Studio - pretty much bringing it up to the same level as IntelliJ
I'm creating a solution where I have several projects, each of them having the responsibility of dealing with entities, MVC views and controllers of a certain kind. That is, one deals with accountance, another with company management, etc. This allows us to reuse them in multiple solutions.
I'm able to use the views in the different assemblies from the core project of the solution (a standard MVC project) by registering a VirtualPathProvider, and the trick of making the views as Embedded Resources, so they can be loaded from outside their DLL.
The main (and huge) drawback of this approach is that by setting the views as Embedded Resources takes away the possibility of compiling, using IntelliSense and debugging them, so it makes the development really tricky, and the maintenance even more so.
Is there any way to make compile this views inside DLLs? Am I missing something there or is there any other better approach to this?
Note: I can compile views in my MVC Project, but not the ones inside the DLLs.
I don't know if this helps you, but...
For a while I wanted to do the same as you until something occurred to me: As long as the views exist as .aspx and .ascx files, they can be used to 'skin' the application since they are not part of the compiled application. In other words, the benefits from having all the Views as uncompiled files in the final, composed application are just too great to ignore, IMO.
So I ended up deciding that the final, composed application is responsible for how everything is rendered. That also means that if I have two different applications that reuse the same modules, they can render these very differently.
These files should contain only rendering code anyway, so should really be developed by a HTML/Graphics designer - not a developer.
All Controllers and ViewModels I still implement in separate modules (.dlls).