Hosting on local IIS

[rosieks]

I'm wonder if final version of asp.net core tools for visual studio will have option to host application on local IIS.

I have 20+ web projects and I like experience from previous version of ASP.NET where I don't have to run debugger to verify if something works. I just build my project and I can run it in browser. Even I don't have to run visual studio so if my project is divided into multiple solutions I can just run it.

[guardrex]

@rosieks There will be an effort by @tuespetre to update his DNX approach (dnx watch with full IIS local) to a dotnet version (dotnet watch); however, he's planning to take a look at this when RC2 releases, so it will be several weeks down the road. See dotnet/AspNetCore.Docs#696 and https://github.com/tuespetre/dnx-watch-iis for more info.

[sayedihashimi]

@rosieks last I heard we may not be able to get full support for local development with IIS. It's something that is important to us but it requires some changes that we may not be able to absorb. I'm hoping that if we are not able to get to it in the initial release that we can address it in a timely manner in an update down the road. At this point it's really a scoping issue so that we can be more focused. I think that IIS Express is working well for most ASP.NET Core/5 scenarios. If there are any scenarios that you're interested in working on that will be blocked without this support in the initial release please let me know.

[upta]

Uck, sucks to hear that because that's a deal breaker for my shop. We make extensive use of IIS sub-applications (and doing them in IIS Express + VS is a nightmare, I've tried, VS was in a constant state of overwriting my paths).

Guess we'll just have to stick with what we've got indefinitely, too bad :(

[NickCraver]

This is also a blocker to progressing internally at Stack Overflow. While I understand IIS has many challenges, from a developer standpoint the current state is quite a regression. The need to publish the application means that direct editing of content doesn't work. As an example, previously a designer would:

1. Edit a .css file, and hit F5

Now they have to:

1. Edit the .css file
2. Build the project
3. Publish the project
4. Reload their browser

Most importantly are that these are very time consuming steps. We've gone from something that can take seconds to accomplish to several minutes. If your project is more complicated and builds take longer, the impact is even more severe.

Our designers also run from macOS pointing at Parallels (again via IIS). We can have local.web1.com, local.web2.com, etc. websites that just work. The equivalent of this in the dotnet world is to publish to IIS, or expose IIS Express port numbers all the way down the pipe (since Kestrel can't port share).

In short, the new system takes a great deal more time for trivial fixes. At a minimum you're talking about F5 spin-up cost (which may be minutes for large applications) and the manual steps needed to do so. I really think this needs a much higher priority than it's currently given. All of the features added to ASP.NET Core won't matter much to those that can't use it at all. It's a hard sell as it is to migrate applications to ASP.NET Core. If the hosting experience is worse and it costs more time, complication, and frustration to do even trivial fixes, then it's going to be a non-starter for many places. We're one of them.

Please, reconsider the priority on this.

[guardrex]

since Kestrel can't port share

It's just a workaround, but WebListener can port share aspnet/KestrelHttpServer#1265 (comment), so that might help with the port sharing problem. Doesn't help otherwise. 😢

[eriksendc]

+1 for this. We use an "interesting" web.config to get http requests to either go to a Wordpress instance or our .NET Core web application, all deployed as one site in IIS (so that we don't have any cookie sharing problems, and we don't need some kind of synthetic subfolder for a sub application, or use a subdomain). It's really pretty cool, but to date we've just been doing the integration when we publish the web application to our QA VM. My developers really would like to run Wordpress and the web app locally to avoid any gotchas. Anyways, it'd be cool setting up local IIS was as easy as pointing an IIS site to somewhere on your disk without having to publish.

[webtools-bot]

The GitHub Issue Tracker for the aspnet/Tooling repo is being deprecated in favor of Visual Studio's Report a Problem tool.

If this issue is still a problem with the RTW release of Visual Studio 2017, please report a new issue using the Report a Problem tool. While you can still use .NET Core and ASP.NET Preview tools with Visual Studio 2015, Visual Studio 2017 is now the officially supported tool for developing .NET Core and ASP.NET Core projects.

By using the Report a Problem tool (available in both VS 2017 and VS 2015), you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks. See Visual Studio's Talk to Us page for more details.

Please use the discussion topic here for feedback and questions on the deprecation of this issue tracker. Thanks!

[NickCraver]

@webtools-bot Please, stop moving things. Why must we re-create issues over and over in various places? This is ridiculous. The onus shouldn't be on an entire community to move things because Microsoft wants to move them. There's discussion here. And reasoning. And use cases.

Why must we re-create all this work in another tool? If you want to move items then you should move it (including all of the discussion), and provide the link for everyone here.

I've added notes to #1026 as well.

[upta]

@sayedihashimi Curious if this has been given any more thought, since it's been over a year since it was brought up. Are we basically just going to be indefinitely out of luck for using local IIS development for ASP.Net Core?