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.
Related
How can I go about separating my MVC project into UI specific (JS, CSS, Images, Fonts, and maybe Views) and Controller/Model specific (Controllers, Helpers, Models, and may be Views). Since our front-end developers work mostly independent of Visual Studio, I was looking for best practices in separating projects. Any pointers or sample projects?
This is how we finally ended up doing it.
Create a separate visual studio project called SolutionName.Client (this is where all frontend js and scss files go)
Create you MVC project called SolutionName.MVC (this is the asp.net mvc project)
Using Grunt.JS write tasks that compiles all js and css files and drops them to SoltuionName.MVC/Content folder
Similarly write tasks that drops all Views (razor files) into SolutionName.MVC/Views folder.
In Project build settings, add a pre-build tasks to run grunt task.
This setup took few hours to get it working but it is now quite useful.
You can easily do this and I've done it for each of my projects in MVC as well.
One project has your Controllers, ViewModels, and in my case, any custom logic related to Dependency Resolution for MVC and custom classes related to security authentication with MVC. Basically any code that touches the MVC framework core and is not involved in rendering content.
The other one has pretty much everything that you use on the client-side, and code needed for the front end. Which in my case, code-wise, is very minimalist and included some code for Glimpse and Elmah. The rest is your Views, Styles, Scripts, static content like downloads, etc.
As for the files in App_Start, My views project has Bundles, Filters, and obviously any HtmlHelpers you may have, custom css transformationslike for LESS.
My Controller's App_Start has the RouteConfig. These aren't necessarily critical it's just the way I ended up organizing mine and really depends what aspects you need access to during the startup of those components.
I will say that to save yourself time, in your Views/web.config file, add a namespace entry for your Company.Project.ViewModels namespace so that it's done in one place and you don't have to add it to each view, as this namespace would reside in your Controllers Project.
Your project with the Views will be your startup project. Just make sure in the global.asax your calls to the FilterConfig, RouteConfig and BundleConfig all resolve correctly.
It's fairly easy to do, my recommendation is to try it yourself and split it out the way you want and if you have problems come back and ask about the difficulties rather than looking for a step by step guide.
Bottom line is, yes it's possible and yes it works,
I recently joined a group that manages a Classic ASP web application. It has been working fine for our group's need. However, a decision was made, before I joined, to move to ASP .Net. Since we are mostly ASP developers, we write code in ASP .Net as we would in Classic ASP (for the most part). Would it be possible to introduce MVC to this application/project?
Thanks!
Yes, it is possible to use MVC in a traditional WebForms project. I migrated a large WebForms project to MVC 2 a couple of years ago, and here are my findings (I have updated them to reflect MVC 3)
Make sure you have .NET 4.0 installed, as well as the MVC 3 framework and VS extensions.
Create a new blank MVC project to use as a reference.
Look at the default web.config for the reference project. You basically want to use the reference web.config, and merge in stuff you need from your current project.
Look at the reference global.asax.cs. Similar to the above, you want to merge the changes in the reference .cs into your current application's global.asax.cs.
You will need to add the following references to your web project:
System.Web.Abstractions,
System.Web.Extensions,
System.Web.Helpers,
System.Web.Mvc,
System.Web.Routing
You can enable the VS extensions by changing the ProjectTypeGuids:
In Solution Explorer, right-click the project name and select Unload Project. Then right-click the project name again and select Edit ProjectName.csproj.
Locate the ProjectTypeGuids element and add {E53F8FEA-EAE0-44A6-8774-FFD645390401}.
Save the changes, right-click the project, and then select Reload Project.
Add the following standard folders for MVC content:
~/Views
~/Views/Shared
~/Controllers
~/Models (for your view models, optional)
~/Content (for CSS and images, optional)
~/Scripts (for JS, optional)
Additional notes:
If your existing WebForms relies on web.config settings for authorization (such as preventing unauthorized users), this won't be recognized by MVC actions, because routing works completely separately from the WebForms authorization. Use AuthorizeAttribute to require authorization, or constrain actions to certain roles or users. You can even specify global filters so you don't have to apply this attribute on every single controller or action.
There may be additional considerations for making MVC work with IIS versions prior to 7, or with application pools that use the Classic pipeline. Consider using IIS 7+ with Integrated pipeline.
My notes above mainly involve getting the baseline of MVC working, which uses ASPX views. ASPX views use the same markup as the ASPX files you are used to in WebForms. You can also use the new Razor syntax (primer), which I highly recommend. You can use both ASPX and Razor view pages at the same time. However, you cannot use an ASPX master page on a Razor view (or vice versa). Also, MVC will find and use ASPX views before Razor views, so if you upgrade a view to Razor, delete the original ASPX. You will need to do a little additional work to enable Razor views. I'm trying to find my notes for enabling Razor. I'll update when I find them. Once you do have Razor installed and working, you can use this tool by Telerik to convert ASPX to Razor.
Here is a question on SO about a problem I'd had while upgrading. I'm only providing it because it covered some of the points I mentioned above in more detail. However, I was upgrading to MVC 2 at the time, so some of this stuff is out of date.
The short answer is yes it is possible.
Scott Hanselman has written about this topic before.
Depending on the skills in your team, you may well find it difficult to get up to speed - it is possible to write clean MVC style code in Classic ASP but most people don't.
It is of course technically possible. However, it sounds like it would be a cultural shock, as MVC works quite a bit differently than Classic ASP or ASP.NET WebForms. I think it would be worthwhile to do - or just stick with ASP.NET WebForms if that seems more natural. But if you've not yet fully committed to WebForms, MVC seems just as easy to move to, IMO.
Yes. I worked on a project that began as plain ASP.NET and later added some ASP.NET MVC pages. Eventually we liked MVC so much more that we eventually migrated all of our WebForms pages to use MVC instead. But the whole time, the two systems worked very well together.
Here's the only real gotcha that I can remember running into: WebForms works by having the entire page encased in a big <form> tag. Since HTML doesn't allow you to have nested <form> tags, you typically can't use MVC forms inside of a WebForms page. Either keep your WebForms pages separate from your MVC content, avoid using HTML forms in MVC content that may appear on a WebForms page, or use popup dialogs for your forms that get created outside of the WebForms DOM area.
I've inherited an MVC3 project that has a large number of ASPX views that I would like to convert to Razor. This question => Aspx to Razor syntax converter? is similar to mine, and it helped me find a bunch of options for converting the views themselves, but I'm unclear on the steps I need to take in addition to converting the views.
The first known limitation of Telerik's razor-converter is "The tool only works with views and does not deal with the project structure and master pages". This tool claims to be able to convert master pages as well, but it doesn't look like anybody beyond the developer has ever used it.
I think these are the steps I need to take:
Use a utility to convert the views
Convert the master pages manually (how do I do this?)
Modify the project structure (what needs to be modified?)
Delete the ASPX files
Test the application (any specific gotchas I should look out for?)
Are these the right steps? Can you help me with my questions on steps 2 and 3?
I have only tried this on one solution and the actual conversion did a fairly good job. I downloaded the Telerik converter project, compiled it, and then converted my projects using these command lines:
aspx2razor C:\Development\MyProject\MyWebProject\*.ascx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.aspx C:\Development\MyProject\MyWebProject -r
aspx2razor C:\Development\MyProject\MyWebProject\*.master C:\Development\MyProject\MyWebProject -r
I only needed to go back to add an #include for a namespace here and there, and to add a few parenthesis to force the Razor view engine to recognize my inline code properly. This was also a fairly simple solution, so YMMV. But even if it converted 80-90% of your views successfully, it's that much less manual work which you would have to perform yourself. From here, you could also create a _ViewStart.cshtml file and make a few minor adjustments to take advantage of Razor-specific layout features. (Check out Scott Gu's post on it here: http://weblogs.asp.net/scottgu/archive/2010/10/22/asp-net-mvc-3-layouts.aspx)
The big issue I had was trying to reconcile the file changes with source control. Since the classic MVC view engine uses .aspx, .ascx, and .master extensions, I had to manually add the .cshtml files to my MVC web project and source control then remove the old versions. It wasn't difficult, just time-consuming.
In addition, you may need to add all of the necessary web.config entries to support the Razor view engine as well if your project was created using MVC 1 or 2. Projects created with MVC 3 should already have these entries in place, even if it was not originally created as a Razor site.
I have an ASP.NET MVC 3 website and I'm looking for a way to package up a set of views and controllers into an external DLL and hopefully use MEF (Dependency Injection) to load the correct controllers and views.
Does anyone know if something like this is possible and any good links to tutorials on the subject?
Precompiled Razor for Shared Views and Mono
Compile your asp.net mvc Razor views into a seperate dll
A combination of those two will probably get the best result in your case - My precompilation code handles some things the single file generator doesn't, but Chris has more use of out of box code at runtime, which is probably better if you only need to run in a standard mvc3 setup.
I have also used aspx files set up as embedded resources ( Views in separate assemblies in ASP.NET MVC ), but Razor is quite a bit easier to work with in compiled form.
I have an Umbraco website that I want to extend. I feel that ASP.Net MVC is the way to go for the extension I'm writing - I particularly like the idea of a Portable Area from MVCContrib. What I'm wondering is, how straightforward would it be to incorporate the Portable Area into Umbraco without recompiling the source?
More generally, is it possible to wire a portable area into an existing application just by modifying web.config? I'm thinking along the lines of creating a HttpModule and including that in web.config.
No, portable areas require a VirtualPathProvider to be set. VirtualPathProviders must be configured via code.
You could try some hacktastic approach using the App_Code folder. It may work.
The current version of Umbraco (4.x) is based on the web-forms model so it won't be easy incorporating MVC into it (though I believe Umbraco 5 - still in planning - will be MVC based).
Generally you either user XSLT or web-form User Controls to add functionality to an Umbraco site. However, I'm not clear what the "extension" you are writing actually does? Perhaps you could expand upon what it is designed to achieve?