i want to integrate mvc2 into an existing webforms project. to get this work, i found all information online.
now i have the problem that mvc just works when the controller and views folder are placed in the root, but i want to have a specific folder (like 'mvc') so that the controller and views folder are placed like this:
~/mvc/controller
~/mvc/views
is this possible or do i have to use mvc area to solve this issue?!
thanks for your help!
best regards...
If you want to group all of your MVC work together, I would use areas to accomplish this.
I think it is possible though to override the View Engine to point the default root to a different folder. This is detailed in this post.
Something to think about before doing this though is, are you planning to eventually migrate your WebForms to Asp.net MVC and remove your WebForms work? If so you might be better keeping the root Controllers and Views folders in the project root.
Related
I have a VERY large website that has classic asp and webforms. I have successfully added MVC and it is working great but... the number of controllers/views is going to massive and I need to organize them.
I would like to use Areas but I cannot find any examples of it working.
I have placed my "Controllers" folder in the "App_Code" folder (if there is a better way, please tell me) and would like my structure to have 2 more levels like this:
App_Code/Controllers/Level1/LeveA/FooController
App_Code/Controllers/Level1/LeveA/BarController
App_Code/Controllers/Level1/LeveB/ThisController
App_Code/Controllers/Level1/LeveB/ThatController
and want the views the same way:
Views/Level1/LeveA/Foo/Index.cshtml
Views/Level1/LeveA/Foo/UpdateFoo.cshtml
Anyone have any idea how to set this up?????
*** This is a web site not a web application, that is why I put the controller in the App_Code
Get ready for yet another elementary question from me...I think I have a grasp on the Area concept in a MVC site, but I would like to organize them even further, could I either move them to an external project (with controllers, views, scripts, styles) or create sub-folders within the Area folder?
Reason I'm asking is that I have tried to create a folder under Areas and called it Common, then created an area inside that folder and called it MyTest. When I attempt to browse to mysite.com/mytest, it fails.
You should try to go the usual way and use areas as a subfolder of the Areas ASP.NET root folder. The only reason why your URL would fail is that your AreaRegistration file is not properly registering your route. You can check out Glimpse as a way to debug routes or simply look at the files and try to figure it out your self. Keep in mind that ASP.NET automatically look for classes that inherit from AreaRegistration and use them to register routes that are specific to your area. If your routes seem to be configured properly, make sure your controllers are in namespaces that are visible to the route.
If you want to isolate the areas (with the controllers models and views) into separate projets, you should look into creating your own VirtualPathProvider, because that's the only way for your views to be located. However, they would have to be Embedded Resource and couldn't be debuuged. Your area, if located in a separate DLL, would be automatically registered and your controllers would be automatically found as long as the DLL is in the main application Bin folder.
Here is what I want to achieve, I want to separate AREAs of ASP.NET MVC as pure single DLL.
Blog.DLL
Forums.DLL
FAQ.DLL
Each of them are individual ASP.NET MVC Area, with its own default CSHTML or ASPX pages. Installing, migrating and maintaining lots of pages including resources, javascripts and so on are real pain for long run. As most of these will hardly change.
My final website will be like this.
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
Without adding any thing, just dropping Blog.dll, my application should support /blog and all its pages. If I want to customize something, than I can add area, and add only cshtml pages..
\MvcApplication
\bin
\MvcApplication.bin
\Blog.dll
\Forums.dll
\Areas
\Blog
\Views
\Shared
\BlogLayout.cshtml <-- this will override the look
\Controllers
\..
\Models
\..
\Views
\..
\Global.asax
\Web.config
This will help in reusing ASP.NET Area Plugins, by simply dropping the dll in bin folder. However web.config may require some changes, but most likely we will save configure values in database and only thing needed will be "Entity Framework connection string" in web.config.
My challenges (Questions)
Is it possible? It sure looks to me, but will there be any reflection/permission issues?
How do I include cshtml/aspx views within one DLL? Probably compiled versions? I have seen couple of text template based View Engines on codeplex but I am little confused on how to actually use them.
And how do I get ViewEngine to first check if physical directory file exists or not and then look into cshtml/aspx within the dll itself as resource file?
You may take a look at the following article which illustrates how a custom VirtualPathProvider could be used in order to retrieve Razor views that are embedded into separate assemblies as resources.
Maybe worth looking at portable areas from mvccontrib. I haven't used them since MVC 2, but found the following SO question by someone having some problems using them with MVC 3, with some possible solutions: ASP.NET MVC 3, Razor Views, and Portable Areas
MvcCodeRouting supports what you want, plus many other cool stuff. Check out this post about ASP.NET MVC Plugins.
Initial sidenote: I'm working on a hybrid WebForms+MVC application that started as a WebForms application hence I've added project GUIDs that converted it to MVC. This means that I'm getting context menus directly on Controllers and Views folder in application root. That works.
I was wondering whether it's possible to convince Visual Studio (and Asp.net MVC tooling) to add Add controller... and Add View... context menu items to other folders not just those default ones that are on the project root?
The reason is that I'm working on an Asp.net WebForms application that is now a hybrid with MVC. And since it already has quite a few folders in root I would rather separate the new MVC part and contain it altogether within mvc folder, so all MVC related files would be inside that particular folder.
But right clicking on mvc\Controllers doesn't give me the wizard, nor does the mvc\Views... Also navigation from controller code to views isn't working...
Is there any way to customize this in Visual Studio? Do Asp.net MVC tools for VS have some sort of configuration file where this can be configured? Or in registry maybe?
If you wish to separate the MVC stuff from the rest of the application you might want to put it in a separate Area.
You'd have the context menu and separation from the existing mess.
Where do you put non-controller, non-model code, like util classes, extension methods and so on in a ASP.Net MVC project? Maybe there's not a specific place to put it, you just put it anywhere, if so, any recommendation? Any best practices?
if it's a single class i put them in a "Library" folder on the project root. If it's a bit bigger I use a specific folder and if it's something more complex i create a new project in the same solution.
According to the Kigg Sample MVC web project (You can get it from the official ASP.net), they put extension utility classes with a subfolder under root.
Good references for ASP.NET MVC Best Practice
http://weblogs.asp.net/rashid/archive/2009/04/01/asp-net-mvc-best-practices-part-1.aspx
http://weblogs.asp.net/rashid/archive/2009/04/03/asp-net-mvc-best-practices-part-2.aspx
App_Code is intended for such purpose if I'm not mistaken.
Anything stored here (including in subfolders) will be accessible throughout the application.
In VS2015 Community (probably others as well but I've not checked) it's even in the context menu under Add -> Add ASP.NET Folder -> App_Code along with a few others.
My recommendation is to put them where they are used most. So if it is the controller that uses them put it with the controller, and so on.