I have an old web forms application (.net 3.5) hosted at www.business-app.local
I want to build a new ASP.NET MVC (.net 4.0/4.5) application that will also have the domain name www.business-app.local
I know I can't have two applications with the same domain and port on IIS.
I have tried adding the MVC app in a virtual directory but hit a bunch of web.config clashes.
I want to keep the two applications separate, i.e. it is not a solution to just add the web forms pages to my MVC application, or to add MVC to the web forms application.
How can I achieve this using IIS 8?
The easiest way to do this is to create your new MVC app and add the folders containing the webforms into it. Queti mentions doing this the other way around, but honestly, it's a massive PITA, as you have to hack around with config files and references.
Once you have your webforms pages in specific folders in the MVC app, simply add exclusions for them from routing in global.asax.cs like so:
routes.IgnoreRoute("Webformsfolder/{*pathInfo}")
Also, seeing as you are (I presume) phasing out the webforms stuff eventually, it's probably best to start from scratch anyway, IMHO. Good luck!
You could add MVC to the current application. The trick is to make sure that the routes do not conflict with the web forms directories otherwise the WebForms will be the ones that handle the request.
This is the process I've followed when migrating Web Forms sites to MVC.
I have had to compromise and put them two apps on separate sub domains with a common cookie.
Related
I maintain an ASP.NET MVC web application that uses the conventional MVC architecture except for any route that starts with /admin, which is handled by an older WebForms architecture. The MVC and WebForms code coexist in the same .NET 4.8 Framework project, and the user of the site can't even tell there's any difference, because the styling is the same and we use url prettifying tricks so that you can request /admin/something rather than /admin/Something.aspx.
This all works fine, except that WebForms is really showing its age and now we want to port the admin stuff to Vue. But I can't figure out how to deploy Vue such that it has the same coexistence with MVC.
I know that I could continue to use Razor pages and add Vue with a script tag, progressive enhancement style, but I think that makes it impossible to use single file components, which is one of the Vue features that seems important.
It seems like the most functional way to use Vue is to create a proper Vue site, with build step tooling, but how can I do this within an existing MVC project and just delegate one route to the new code, and port other routes over as needed?
I'm creating an application with a .Net Web Api project wanting to use pure AngularJS as the client side. Since Web Api is built on top of MVC, it creates MVC specific and default items that I feel is not needed. These items include the HomeController, _ViewStart.cshtml, _layout.cshtml, etc. I tried removing them but it comes up with errors. Has anyone tried to remove the MVC stuff out of the web api project and used separate client side front-end? Is it even possible to remove the MVC items without errors?
Remove RouteConfig.cs from App_Start, remove the Views directory and all sub-directories including the Views internal web.config file. Comment out or delete all the lines in the Global.asax.cs Application_Start method except GlobalConfiguration.Configure(WebApiConfig.Register). Remove the HomeController, add an index.html and any needed Angular scripts and go at it. I also added solution folders to organize my views as reusing the existing Views folders did not work. I'm using VS 2015 but is should work for 2013 also. PWE
Web API is not built on top of MVC.
The default templates bring in MVC for the sake of supporting a help page, but you don't need to use it.
You can start with an empty web project and just check Web API.
The routing piece is server routing and it's part of what maps the URL to Controllers+Actions, it has nothing to do with Angular routing.
As Mike Cheel alluded to, there are no dependencies between MVC and Web API. However, if you use the built-in templates, it's easy to get the impression that the 2 are linked. They include a lot of stuff in these templates because they can't anticipate where you want to go with your project... so they try to cover all the bases.
For your purposes, you would probably be better off to start with an empty project and add only the components that you actually need. For this approach, some of the best tutorials and starter projects are from Taiseer Joudeh's "Bit of Technology" blog. His tutorials helped me to build an "MVC Free" web application from scratch that uses JSON Web Tokens and AngularJS Interceptors for security and Web API 2 and Entity Framework to serve up the data.
He has many tutorials on his website... but you might want to start with "AngularJS Token Authentication using ASP.NET Web API 2, Owin, and Identity". What what.. you didn't ask about security? Well... security is an issue that you will need to confront at some point anyway... and Taiseer presents a nice solution for securing an Angular/Web API application.
OK so I have a large .NET 4.0 webforms solution with many projects. I want to develop a new set of screens in MVC3 that integrate into the site. Do I need to change the webconfig and routing in the existing webforms (web application) root? That seems risky. Can I just add an MVC3 project and integrate that into the web application? What's the easiest, least risky way? Does all the routing have to be done at the root? Also, we use NCache for state management. Thanks.
There is nothing about the "solution" that is webforms, so yes, you can add an MVC project to the solution. If you want to add MVC3 components to an existing webforms project, you can do that, too, but you will have to do some of the work the MVC3 project wizard does for you, like adding routes in global.asax.cs and making some web.config changes. Once complete, a hybrid webforms/MVC3 application works fine.
My recommendation, if you want to go this route, is to create an MVC application and look at the things that it puts into the Global.asax.cs file and the web.config file and compare that to your current application.
Check out
http://www.hanselman.com/blog/IntegratingASPNETMVC3IntoExistingUpgradedASPNET4WebFormsApplications.aspx for a good primer.
We have a website that was written in classic ASP, then I started to extend it using web forms. These extensions exist in a subfolder of the main folder. Now we've decided we'd prefer to use MVC3. Also, as we'd like to convert all our site to MVC3 over time, we are hosting the MVC code in the application root. I've found some other questions where people have a similar issue to mine, but no solution. The issue is simply that my web forms app can't seem to be stopped from inheriting the web.config settings from the root folder, and as a result, it won't run, it either complains about missing dlls, or complains about running the wrong version of .NET, or complains I need to remove some settings ( which I try and can never get to work right ). The app in the subfolder is also hosting a webservice that is called by our application, and it also runs HTTP handlers to protect our imaging content, so it's got a bit of stuff in it. Do I need to run my MVC site in a subfolder ? Is there any way to have MVC in the folder above a web forms app ? I'd prefer to set things up so they share session data, but that's looking likely to be impossible at this stage...
So to be clear the folder structure is:
<root>
contains asp site and MVC site.
<subfolder>
contains webforms application
</subfolder>
</root>
and my issue is getting the subfolder to run, preferably in the same session as the MVC app.
There is no reason you can't run regular .aspx files on an MVC site. You are correct though, web.config settings are inherited from the parent (chain), but you just add a new web.config in your directory with relevant settings.
What you will have to do is play with the routes, because by default MVC will route all requests into your controller classes. But if you google around its fairly simple to add an exception to the routing.
If you post some of the specific errors we can probably help further.
Oh and do you mean Classic ASP? i.e. not Classic ASP.NET? Because you'll have fun sharing session data between ASP & ASP.NET.
I'm in the process of moving a large classic ASP application to ASP.NET MVC 2. Questions:
My question is about project organization.
I would prefer to not mix the MVC code with the ASP code in the same VS project. I'd like to have an MVC WAP with areas that match the parts of the website that I'm migrating. For instance, the old site has a folder
/products/default.asp.....
/products/productName/default.asp
etc.
In the MVC WAP, I'd like to have an area called "products", which I could then, either through a rewrite, routing, or preferably through some IIS configuration, point the "products" folder on the ASP site to. In this way, I could gradually move root folders from the ASP site to the MVC application.
However, if I create the MVC WAP in a virtual folder, then my routes wind up looking like
http://localhost/virtualFolder/products
instead of
http://localhost/products
Any suggestions on how to conquer this?
I know that, during deployment, I could deploy the MVC WAP into the root of the ASP site, but this doesn't help with debugging.
I'll write my answer assuming this is hosted on an IIS7 instance. If it's IIS6, then you'll need to look for a suitable ModRewrite module for it.
So, assuming IIS7, you'll be far better off using URL Rewrite:
http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/
You can manage your rewrite rules and rewrite maps, depending on your level of access and control, either from within the IIS7 Administration Console, or manually via your web.config file.
These rewrite rules and maps can be as simple or complex as you need them to be. You can also set them up to be either a temporary or permanent redirect - which will assist if any search engines are indexing the site as the correct redirect code will be returned with the HTTP request to ensure crawler results are updated promptly.