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.
Related
I have been given a sample MVC project that contains views with extension .aspx
however when I create a new MVC project using the VS2013 ASP.Net wizard the views have extension .cshtml
Are there 2 kinds of MVC project?
Views in MVC refer to either .cshtml files in C# or .vbhtml files in Visual Basic.
.aspx files are webform files and are not views-- this was the initial approach ASP.NET took to make webform development more similar to desktop application development. These pages are generally included in the route list as actual files, whereas MVC uses controller routes that aren't based on existing files (i.e., the url path doesn't match the file and directory structure like traditional html does), which ultimately serve the views. .aspx files can also have code-behind files to separate the html/aspx markup from the .NET code; those files will have either a .aspx.cs or .aspx.vb extension on them. In an MVC app, these files are also likely to have designer files.
One set of files for an aspx file named MyPage may have the following files:
MyPage.aspx
MyPage.aspx.cs or MyPage.aspx.vb
MyPage.aspx.designer.cs or MyPage.aspx.designer.vb
The files in #3 may be hidden until you select 'show all files' in the project, or may not exist at all in a traditional 'web site' project type. I think you have to upgrade to a 'web application project (Wap)' project type before you can integrate MVC, though I may be wrong. All WAP projects should have these .aspx.designer.xx files.
In MVC what extension should the view file names have?
.cshtml unless you have a reason not to use the Razor view engine with C#.
Are there 2 kinds of MVC project?
The relevant answer is that there are many more than 2 different view engines. Razor was introduce in 2010. The Razor view engine is what comes out of the box in the Visual Studio MVC templates. See ASP.NET MVC View Engine Comparison for more info on more obscure view engines that work with ASP.NET MVC.
I'm looking at this MVC WebApi starter kit (for Angular/TypeScript)
Ignoring all the client side code, I noticed the author has made a WebApi that is extremely bare bones. Has has taken out most scaffolding including _ViewStart.cshtml, _Layout.cshtml, and forgoed the convention of controllers in Controllers folder and views in View folder under subdirectory with same name of controller, etc.
He added some interesting Routing and Validation classes that I havent seen before in a Core folder and put controllers in Api folder and Views directly into Views folder with an Index.cshtml at the root.
It's very clean and barebone project structure for a standalone web api that will do nothing except serve data to a client heavy application. I kind of like it this way but before jumping ship I'm wondering what drawbacks this approach has and if I'm actually giving up any core features of the framework by doing it this way. For example, clearly MVC Areas are being given up here in favor of flexibility to create your own view folders structure and seperation of application sections (I'm okay with getting rid of MVC Areas I rarely used them anyways). Another thing is I don't think a Controller action method can return View() and it will find it in the Views folder by convention of the controller name. I'm also okay with that since I will only be serving JSON data and will use 100% client side templating.
Are there any other core features that are being abandoned that I'm missing that may make me regret going with this project structure?
When I create Web APIs that are hosted in IIS, the only files in my web application are web.config, global.asax and global.asax.cs. Everything else is not required.
Take a look at this template if you haven't already before you decide how to structure your ASP.Net MVC / Angular project:
http://visualstudiogallery.msdn.microsoft.com/5af151b2-9ed2-4809-bfe8-27566bfe7d83
You can always add components into your project later, so I wouldn't seat it too much. I like to start with a lean/mostly empty project first and add things myself so that I fully understand what I'm adding.
I've got the following project setup
Project A (main)
Business
Data
View (asp.net mvc 3 project)
Project N
Business
Data
View (asp.net mvc 3 project)
How can I call from Project A the View in Project N and from N back to A. Essentially what I'm trying to do is package each Project N to have its own individual MVC as it comes from different sources and plug it in to the main project and then just have it navigate to the correct view.
Can this be done? Or is there a better way to do this?
You could write a custom virtual path provider. Here's a nice blog post which shows an example of such a virtual path provider allowing you to embed Razor views into assemblies as resources and reusing them in multiple applications.
Unfortunately without a custom virtual path provider, you cannot cross reference views between multiple ASP.NET MVC applications. This simply is not allowed by the default provider which looks for views only inside the current application.
I do sugest another approach if possible. if I understood correctly, those projects are somehow ike plugins but they are not standalone applications.Also they now about each others so they are coupled. It's, let's say tricky, but I would use only 1 asp.net mvc project (the web ui). All the UI bits which belong to other projects I'd make them helpers (pretty much widgets). This means, that each project contains only the helpers which will be used to construct a view.
I think it's a bit of an architectural problem if you only want to keep the views in each project just for the sake of hosting them in a different assembly. Going the widgets' way it might seem mkore work, but I think you gain the most control and the separation level you want. The only thing is you don't have full Views defined, but why you would want to have full Views (partials, layouts) in separate places if they will be used in one place only?!
Now, if each project is indeed a plugin, independent of other plugins, then going with compiled views is the best way. But if Project B knows about the view of Project N, then I think the above solution is more suitable. That or the whole app is too over engineered. Separation is good when it doesn't create a whole new jungle to navigate it.
I have an MVC 3 app that has some core functionality (most important is autorisation) but mainly serves as a portal to different areas or modules. I want to organize thit to different modules that with minor changes also can be deployed as their own website.
The project consists of a Forum, Blog engine, Messaging between users + 4-5 upcoming modules.
I looked at ScottGu's blog about MVC 2 and found something that seemed perfect:
Depending og what the customer need I want to only give them the exact modules they can use. It is also easier from a maintainence view to be able to work and update referencd assemblies in each project and just do a full update for the customers that have that spesific module on their server.
But in MVC 3 there is no apparent way to use Areas this way, do you know how?
Status
I will try to add MVCContrib Portable areas to my existing solution and convert my areas ower and will post back the results. If it works I will mark it as the accepted solution.
MVCContrib has portable areas.
http://mvccontrib.codeplex.com/wikipage?title=Creating%20a%20Portable%20Area&referringTitle=Documentation
This is possible in MVC3:
From:
http://bob.archer.net/content/aspnet-mvc3-areas-separate-projects
Right click on the shell project and "Add Area...". Type in the area name. This will create an Areas folder with your area in it. (This is not 100% needed but you do need the "Areas" folder and you can steal the XXXXAreaRegistration class for your application.)
Create a new MVC3 empty project in your solution to match your area. Move the XXXXAreaRegistration.cs file from the shell mvc project to the new project and adjust the namespace as applicable. (Or you can manually create an area registration class, it's a pretty simple class. Just use the Add area template generated one as an example.)
Edit the routes in the AreaRegistration folder as needed.
Delete the folder under the areas folder that the template wizard added.
Modify the web.config of the new project and take out the connection strings and the authentication, membership, profile, rolemanger sections. You will not need to deploy this web.config but the razor intellisense doesn't work without it during dev time.
Delete the global.asax file from the area's project or you will get extra default routes.
Create a virtual directory in the "Areas" folder of the shell project with the name of your area as the alias and point it to your "area" project. You will need to use IIS or IIS Express for this. I use IIS. For IIS Express you can use the appcmd.exe in the IIS Express folder or you can edit the applciationhost.config file.
I created a new MVC project and added some webforms pages to it in an effort to start adding new pages to my app using MVC and eventually port the old pages over as well. Everything is building and working correctly but I did notice that I don't have the "Convert to Web Application" option when right clicking an aspx file. And I think its not regenerating my designer files when I change the controls on a page.
My guess is that the ProjectTypeGuid is wrong or in the wrong order. Can someone confirm?
Old (Webforms) project file
<ProjectGuid>{4F95C3D9-228E-4BD5-9840-46224BA3EBA7}</ProjectGuid>
<ProjectTypeGuids>{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
New (MVC) project file
<ProjectGuid>{A4690D3F-695B-4BF4-93B7-EA5B17793051}</ProjectGuid>
<ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
This is so wrong on so many levels but I am going to answer you anyways in the hopes I might get an uptick or something. You have two routes with this. First route which I use all the time is put your mvc applications in their own projects. When your deploying the site drop the webforms application first, and then make a folder in that webforms application and put your mvc application into that folder. That should work like a charm for you. If you insit on having webforms and MVC Framework in the same project, then don't drop your webforms into the view folder. Create its own folder because you can not directly access your aspx pages from the views folder without making modifications to the web.config. Hope this helps.
MVC is available as a Web Project only. The VS2005 style Web Site is not supported.