In old sweet Web Forms times, when we make change on code behind, once we hit the application, it was compiling on the fly and running new changed code.
For Web Apps and MVC, when I add a new controller or change something on business logic, I have to always build app on VS 2015 manually and go back to browser and test again. But many times I keep forgetting building till I see yellow error screen.
Is there any way to kick build if there is code change and if I hit the website first time like Web Forms? I would not prefer to build on save since I am a ctrl + S freak, and keep pressing that combo on every other second.
To my knowledge Dynamic Compilation is not available in an MVC application because it won't be a "Web Site" project, it will be a "Web Application" project. Only Web Site projects can do dynamic compilation, since with MVC you're routing to actions in the controller my guess is it has to be compiled in advance - unlike ASP.NET where you're routing to a physical file.
Related
In VS 2012, I am attempting to create an MVC 4 web application with jQuery calls to a Web API project. (Other devs will be consuming the API with our current, native app, and probably adding to the API in the future.) So I have one project that is the Web API, and another project that is the MVC 4 website. I can only set one of them to run, and they use localhost:xxxxx.
How do I debug changes to both? For example, let's say I add a new API path /api/customer/get and then a new jQuery ajax call to that path and do something with the resulting JSON. I've changed code in both projects and want to follow it end-to-end; how do I launch both? How do I debug both?
Just to be clear, the MVC app isn't making server-side calls to the API, I'm using MVC mostly to be able to easily use bundling, minification, and (hopefully) pre-compiled Handlebars templates in .NET; the API calls are coming from jQuery. As I am still relatively new to these technologies, alternate suggestions are welcome.
Thank you in advance.
I had the same problem and have found a solution from here:
forums.asp.net
The fix is to do the following:
In your solution file, click properties go to the Startup project node (if it is not already selected)
Next select Multiple startup projects. Select your website and your webservice and in the Action column make sure both of them have "Start" selected.
Now when you debug your website and put a break point in your webservice, it should hit the break point.
Coming late to the party but in case anyone else is looking for a solution, this is what was best for me: Set the Api project up to be the starting project (I needed to limit to one startup so that I could flip between browsers more easily). After firing up the service project, right click on the web/ui project and select debug, start new instance. You'll have both running and you'll seamlessly step from web to api.
I had a similar problem with my web api project. My solution consisted of an angular front end with 2 web api projects on the backend. One web api project handled "authorization" and the other handled "resources". I used the following tutorial by Taiseer Joudeh as a starting point:
http://bitoftech.net/2014/09/24/decouple-owin-authorization-server-resource-server-oauth-2-0-web-api/
Breakpoints worked on the "authorization server"... but not on the "resource server". I compared the packages from the two projects to see what was different. Once I added "Microsoft.AspNet.WebApi.Cors" to the "resource server" project, the breakpoints starting working.
I am trying to determine what the best project type would be for a project that contains only an ashx file and a config for that file.
I'd do it as a web application project.
Reasoning:
For WAP's you don't deploy code to the server. It's compiled first.
It's compiled as part of deployment. This will catch most of the fat fingered typing errors.
(and this is my real one): Web Site Projects are a complete pain in the * for team development. To the point that even for a stupid simple little app that only I will ever work on I still refuse to click on the New -> Web Site menu option.
There are multiple reasons to dislike "Web Site" projects; and extremely few to bother with them. So, IMHO, just stick with Web App projects or use an MVC flavor of the month.
I would choose a Web Site Project, let ASP .Net to deal with compilation
I have an existing solution in VS2010. When I click the properties of my project I get the view as can be seen in image1.png:
When I create a new empty ASP.NET web application and click the properties of my project I get the view as can be seen in image2.png:
A huge difference.
Now I'm implementing this code here: http://wcf.codeplex.com/wikipage?title=Getting%20started:%20Building%20a%20simple%20web%20api
And that tutorial assumes I get a view as I've shown you in image2.png
In image1 and image2 I've also marked the menu items: "Website" and "Project"
This makes me assume that I've created a website application whereas I need something different (I'm thinking a web application project).
Not sure what to do now, I need to convert my current application to another thing, but to which type and how to do it?
I also came accoss this post: http://blogs.msdn.com/b/webdevtools/archive/2009/10/29/converting-a-web-site-project-to-a-web-application-project.aspx
But before I start screwing up everything :P Is that what would solve my problem?
It should be possible to use either a web site or a web application project. In the example on the link you've posted, they use the predefined template for ASP.Net MVC Web Applications. This has several advantages - it sets up the structure and other resources for you - it's effectively a template.
For the purposes of the tutorial, why don't you just set up an application that way? If you've already written some code, you can just import it into the new application.
For future projects, you might want to consider which is best for your needs. Apart from structure, there are some other key differences between a web application and a web site project.
MSDN handily provides the differences here:
http://msdn.microsoft.com/en-us/library/dd547590.aspx
If you find you want the features of the web application, then the link you've posted is fine. You'll need to do some re-organizing of your references and so on and so forth, but the process is fairly straightforward (but not painless).
A "web site" in visual studio is the old, .net 1 style of creating web sites. It basically dynamically compiles the code in a folder when it's hit for the first time. Later .NET introduced a "web application" model where the code is compiled into a DLL and no code files are deployed with the site. "Web sites" are pretty much depcrated and shouldn't be used for any new projects unless you're doing a quick demo site.
The codeplex project you referenced also depends on MVC 3 (which are web applications).
You are probably better off just restarting like the tutorial says - create a new MVC application like it shows in its first screenshot.
If you do not have that option, use Web Platform Installer to add MVC for you - http://www.microsoft.com/web/downloads/platform.aspx
Good luck!
I can't tell exactly what's going on from your screenshots, but if you have a web site that you need to convert to a web application project, you can find the directions here
Although the instructions are specific to VS2005, they are basically the same for 2010 as well.
I'm an ASP.NET Web Forms developer who has recently switched over to an MVC web app.
I'm having difficulty working out the quickest way to preview code changes when running the MVC web app through the integrated Visual Studio web browser.
In web forms, I can make a change to the codebehind and simply refresh the page and it's all good.
In MVC, I seem to have to close the tab in the browser, return to Visual Studio and press F5, wait for it to build every single dependent project and open up a new tab in the browser to display the page. This is so much slower than how it works in Web Forms it's driving me to distraction.
Am I doing things right? Is there a way to speed this cycle up?
The view pages themselves are compiled dynamically and thus any changes to these can be viewed simply by saving the changes and refreshing the pages in the browser. Changes to code made elsewhere, however, will require a rebuilt after which you can refresh the page.
Pressing F5 will start the web server (if it isn't already started) and then attach a debugger to the process after which it will fire up the web page. The first two steps are very slow, and you should avoid them unless you specifically need to start the web server or debug the application.
So
Changes to view: ctrl+s -> refresh web page (f5)
Changes to code: ctrl+shift+b -> refresh web page (f5)
I used to find setting my project to run via IIS, rather than Cassini, made it a bit quicker. If you've made changes to the code, you'll still have to compile the solution, but at least this way you aren't waiting for Visual Studio to slowly crank itself into gear every time.
Found this article that might provide some clues too:
What are the (dis)advantages of using Cassini instead of IIS?
Is there any difference between website and web application project? What if you are working on a project that is sort of hybrid of site and application? which project should you chose?
I'ld go the newer Web Application project (always, regardless of the size of the project).
There is nothing to lose and everything to gain with using the Web Application Project (you cannot say this about using the "website" only).
The official list of differences are here:
Use Web Application Projects when you
Need to migrate large Visual Studio.NET 2003 applications
Need to
control names of output assemblies
Need stand-alone classes to
reference page and user control
classes
Need to build a Web
application using multiple Web
projects
Need to add pre-build and
post-build steps during compilation
Use Websites if you:
Need to generate one assembly for each page.
Prefer single-page code model to code-behind model.
Prefer dynamic compilation and working on pages without building entire site on each page view (that is, save file and then simply refresh the page in the browser).
Want to open and edit any directory as a Web project without creating a project file
#Mehrdad's link here is essential if you want to know more http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
As for which project to choose, I would go with the Web Application Project, regardless of size. Having all of your code behind compile down into a single DLL is a major benefit for maintenance and security on the hosting end. I know there are precompile options for web site projects, but they seemed like more trouble that it was worth for me.
I know that the IIS filters are in place to prevent users from accessing your .vb or .cs files, but it still makes me a little leery.
But more important to this is the nice fact that if you make a bunch of coding changes, or maybe add some classes and change the processing logic, the only thing you have to merge up is the compiled DLL and nothing else. Similarly, if you do a few UI changes (say change the stylesheet or position of a few controls), you don't have to worry about recompiling the application, you simply bring over the update .aspx page and you're done.
Take a look:
http://msdn.microsoft.com/en-us/library/aa730880(VS.80).aspx#wapp_topic5
http://forums.asp.net/p/1300026/2538628.aspx
I'm used to create websites when I want to create a new webapplication.
My current project had some problems on compiling, so I switched to a webapplication project. The step isn't very hard. Visual Studio helps you to change all necessary lines.
Refer to the links in the post:
http://www.codersbarn.com/post/2008/06/01/ASPNET-Web-Site-versus-Web-Application-Project.aspx
Anthony :-)