All the action is client side in a SPA app. The Visual Studio Durandal and Hot Towel project templates both serve the SPA out of an ASP.NET MVC application.
What, if anything, does the ASP.NET MVC infrastructure bring to the party? As far I can see all it does is make it hard to serve a WCF Web Service (ajax enabled) out of the project web.
Yet both of the project templates are set up like this. What have I missed?
As a matter of fact, ASP.NET MVC in this template is not necessary. All it does is serve the initial Razor template for the SPA and provides you with the bundling and optimization support of all the client side javascript resources for the application so that when you deploy your application you don't end up with gazillions of HTTP requests from the client to fetch all the .js crap necessary for the application to work. Of course you could perfectly fine have used the bundling feature outside of ASP.NET MVC in a simple and plain ASP.NET web application.
What, if anything, does the ASP.NET MVC infrastructure bring to the party?
See the documentation:
Hot Towel builds on the familiar and powerful ASP.NET MVC structure.
App_Start
Content
Controllers
Models
Scripts
Views
As far I can see all it does is make it hard to serve a WCF Web Service (ajax enabled) out of the project
You can't just right-click your project and add a new WCF Service?
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 have finished building my first durandal application using .Net MVC and Web Api v2, every thing working fine however I noticed that I can access files directly like
http://localhost:1990/App/views/sessiondetail.html
now I don't want that cuz that is just requesting static pages with no logic or styling.
You will have to override the web servers' default configuration for handling html files in your application, thus tying into to whatever security mechanisms you have in place for request authorization.
This article how explains how to add a handler for all *.html files in your application.
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.
I can’t get a basic MVC site to work on my web server unless I’ve compiled it first in Visual Web Developer. If it doesn’t have a dll in the Bin, it says the Namespace can’t be found.
In classic asp.net I could just upload the files and the server would compile it at first run. Is this not the case in MVC? Essentially I’d like to build an MVC site without using Visual Web Developer.
That's cause ASP.NET MVC is not based on the Website model that many ASP.NET Web Forms apps were. It is based on the Web application model.
You can read about Web Application Projects here.
I've read about people migrating the Web Application to the Web site model in ASP.NET MVC but I don't recommended it.
Yes, you do need to compile an MVC site and deploy some DLLs in a bin folder when you deploy an MVC site
You can build MVC without Visual web developer... but why?
I'm wondering if anyone has any insight into why ASP.NET MVC sites have to be created as a web application (compiles to single .dll) in Visual Studio as opposed to a web site (each page is a .dll)? I suspect that it has something to do with the routing. Any thoughts?
Web Applications have a .csproj file which gives a lot better control over the build process when compared to a Web Site project which is really just a set of files and folders with build managed entirely by the VS IDE as far as i'm aware.
You may be right about the routing, but another possible reason relates to project structure and the relationship between the MVC application project and it's test project.
One of the key differences between a Web Application and a Web Site is that the Web Site is a standalobe entity, it does not exist within a solution which makes it difficult to express the relationship of the test project to the application project, whereas if a web application is used then the web site and it's tests can be treated as two projects within a common solution while also getting all the benefits of using MSBuild
Okay, I figured this out. The only reason that the ASP.NET MVC application is a Web Application instead of a Web Site has to do with the unit tests. You can 'convert' an ASP.NET MVC application to a web site with very little changes, but the unit tests won't work because they have no reference to the web site. But, I'm pretty sure that you can get the unit tests to work if you start pulling your application logic (controllers, et al) into a separate class library and then reference that class library in the web site and unit tests.