I have a ASP.NET MVC6 web application developed in VS 2015. I run it on Windows 10. I have client side JavaScript compiled by Gulp which is dropped in the wwwroot folder which I want to debug as well as debug the WebAPI controllers on the server side. The application will be hosted on Azure after the development is complete.
During the development, should I use (1) WebDev.WebServer.exe (2) IISExpress.exe (3) IIS10 or (4) DNU to host the ASP.NET website?
IIS Express (2) is good enough for about 95% of things you need to do during development, it's as good an implementation of "proper" IIS7+ as you'll likely need.
That said, for things you can't properly emulate on your workstation, such as Azure, periodic deployment to your Azure environment is always a good idea, just to be sure you don't fall into the trap of "Well it worked on my machine".
Never use the built-in webserver.exe, it's a toy and is severely limited in functionality.
Related
I have a aspnetcore webapi application,i want run it in iis(not vs iis),and dont publish the app,just in use the develop file like:
app develop file
because i dont want publish my app into iis every time I change code
I don't want to see the swagger page only I start vs
I set the iis site path to app develop folder but I get the error code:403.14
error page
Check this article
There should be very few reasons for you to run IIS during
development. Yes, in the past there were very good reasons to run full
IIS because there were always a number of things that behaved very
differently in full IIS compared to IIS Express.
However, with ASP.NET
Core there's little to no reason to be running full IIS during
development.
You could use dotnet-cli to run your api
You cannot fight the fight that is doomed to fail,
https://blog.lextudio.com/how-visual-studio-launches-iis-express-to-debug-asp-net-core-apps-d7fd3677e3c3
Visual Studio uses a trick, which I documented with full detail in the blog post, to run ASP.NET Core apps on IIS/IIS Express. So you only options are,
Use Visual Studio.
Publish the app and then run it on IIS.
There is no obvious third option.
In ASP.Net core, there are two ways of running/debugging the app, IIS Express and ________?
I don't think it is proper to call the other way Kestrel b/c that is running in the IIS Express version, isn't it?
When I pick the green underlined option, what is that called?
Is dotnet hosting Kestrel then?
As #Tratcher says: ConsoleHost would be a good term. Since your application is run with a shell around it which is called the console on windows. Which is the Host of your dotnet application.
If you want to be as appropriate as possible towards the red line IIS express which would be the host of the dotnet app, then Console would be the most appropriate, since its the host of the application.
Although in more OS independent terms its either called the shell or the terminal (console is a very windows term). But since visual studio only currently runs on windows that should be fine.
I have just installed VS2012 and created a MVC project. I right clicked on project and selected property, I chose Web tab. I selected "Use Local IIS Web server" but the "Use IIS Express" checkbox is disabled.
I checked my C:\Program Files (x86)\IIS Express\ folder and IIS Express 8 is there.
Any particular reason?
If I fall back to use Visual Studio Development Server, I have 50% of the chance to see "Server Too Busy" message.
All you have to do is to activate IIS in your development machine:
Start -> Control Panel -> Enable or disable Windows features -> Internet Services
Then check mark in World Wide Web Services -> Common HTTP Features
And check mark in World Wide Web Services -> Application development Features
That's all you need.
Using Full IIS has some benefits. One is that it is always running, so you don't have to start your VStudio Project to unit test. Another is that you can create an actual site and configure IIS mirroring production, using the same Admin Tools, which makes it easier to support when deployed in an environment. And, I seem to recall that IISExpress had issues with Application Routing. On the flip side, I don't see an issue with using the Full IIS. Granted, IISExpress is much better than Cassini, but if there is no reason to not use Full IIS then I conitnue to advocate it's use.
Wondering if I should stick with testing on my local IIS install or just use the Express version. Any reason why or why not?
generally, I would try to have the development / testing environment resemble your live environment as closely as possible.
so if you're using IIS in production, I'd recommend using it in development also.
I cannot tell you how many times I've seen web apps working perfectly on the development machine using IIS6, and crashing completely on IIS7.
I suggest this configuration:
IIS Express on the developer machine
same IIS as in production on a staging machine
IIS Express is the best choiche on your local computer because it's easy and fast to install and configure and doesn't require administrative rights to be installed.
It's completely integrated with Visual Studio and it has all the functionality of IIS.
And the configuration is in the source code repository so each developer can checkout the solution and is able to run it with minimal effort.
As sJhonny suggests is recommended to have an environment closer as possible to the production environment.
The best way is to have a staging server with the same software configuration of the production server, in your case with the same IIS complete version (it's enough a virtual machine).
My development machine is running Windows XP SP2 (and IIS 5.1 by implication).
Until recently our deployment environment was based around Windows Server 2003 (and therefore IIS 6.0).
We are about to move to Windows Server 2008 (and therefore IIS 7.0) for a new project.
Our projects use ASP.NET MVC and WCF Services.
Are there any key reasons for us to upgrade our development machines to run Windows Server 2008 (or possibly Vista, since this also comes with IIS 7.0)?
I would say it's in your best interest to upgrade your development machines to emulate as much of the production environment as possible within your means and resources. Otherwise you may fall into traps you're completely unaware of just by deploying an application from your development machine to the server's environment, which may pertain to differing versions of IIS, the version of .NET framework each machine is running, or just the way the code is compiled or executed at runtime.
Especially since IIS 7 has been vastly upgraded since IIS 5.1, why shouldn't you work closer with it's current functionality while developing before you missing out on some great opportunities? To really know what to expect from an application in production, develop it under the same circumstances.
Edit/Added: This link may help you see at least one significant example of how differing versions can affect your project.
I would recommend that you develop against the same major build as you intend to deploy on. That said, this leaves you with a few options. First, you could build against your local IIS installation (as it appears you currently do). That means that all of your boxes should likely be upgraded to Windows Vista or Windows 2008 Server (or Windows 7 as it is running IIS 7.5). Your second option is to deploy to a remote machine. It is entirely possible to deploy your application to a remote test machine running IIS 7 and remotely debug as well. The problem is that if you have more than one developer working on the remote site, it becomes problematic. IIS can handle the remote debugging on different webs for different developers, but depending on your architecture and configuration, you may still be sharing resources between instances of test web applications.You could occasionally deadlock each other. The only benefit is that you don't have to buy licenses for all of your machines (and potentially upgrade hardware to support the OS upgrade). However, I think that would be short-sighted. The loss of developer productivity wouldn't be worth it, IMHO.
There are major changes between IIS 5.1 and IIS 7.x. The changes to the architecture, such as the integrated pipeline, can result in drastically different behavior and compatibility issues. I think you will find that IIS 7 far more developer-friendly. The introduction of things such as failed request tracing, extended logging, and enhanced error pages alone make it much easier to track down errors in your application. In that regard, the upgrade is well worth it.