The "Apply server settings to all users (store in project file)" option is missing in VS2013 - by Marc Gravell

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


140
0
Sign in
to vote
ID 800003 Comments
Status Closed Workarounds
Type Bug Repros 39
Opened 9/9/2013 6:17:00 AM
Access Restriction Public

Description

This change is a major nuicance for anybody who works on a team, and for OSS projects, where it is not guaranteed that every developer is using the exact same option. In reality, different developers could be using:

- a different "hosts" alias / localhost / 127.0.0.1 / some specific IP address
- different ports
- IIS / IIS Express / VS Development Server
- different start pages
- different root urls
- etc

Basically, every time anybody changes these settings, the csproj (rather than the .user file) will be changed and typically committed - making it just deeply annoying.

Not only is this option missing in the UI, but the SaveServerSettingsInUserFile setting (in the csproj) is no longer respected.

If you manually set the values in the .user file and load it, the IDE will *read* the correct values, but if you make any changes in the IDE, the values are changed in the csproj, and removed from the .user file.

Basically, this change removes a really good feature, and makes it a nightmare for teams.
Sign in to post a comment.
Posted by Bala [MSFT] on 1/9/2014 at 12:37 PM
This issue is now fixed in VS 2013 Update1. Thanks for your patience, please let us know if you still have issues with this feature.

Bala Chirtsabesan
Web Development Tools team
Posted by Marc Gravell on 12/11/2013 at 4:28 AM
This feature is now present and available in VS2013.1 RC. Note that this is a preview yadayadayada - read the release notes and make your own determination.
Posted by Noah_P on 12/6/2013 at 3:24 PM
Thank's for the update Mr. Hanselman! Our team hasn't been able to move to 2013 yet because of this bug, so its awesome to see there as been progress in correcting it.
Posted by Marc Gravell on 11/19/2013 at 10:32 AM
This is why we love you Scott :)

Thanks for the update
Posted by Scott Hanselman on 11/19/2013 at 10:00 AM
Ok, I'm told this has been fixed by dev and is now in QA. We expect this WILL be in the first Update to VS.
Posted by kipus0ep on 11/12/2013 at 7:04 AM
Also see this bug which is relevant to this issue: https://connect.microsoft.com/VisualStudio/feedback/details/807760/cant-open-web-project-after-using-iis-express-instead-of-iis-once
Posted by Jeremy Foster on 11/6/2013 at 4:24 PM
This is a massive bug, I'm surprised only 72 users have clicked here.

Essentially anyone who works on a team OR uses a code repository with more than one branch is screwed.

This problem is so bad that VS2013 is unable to even load a web project once the particular IIS Express site has already been taken. You have to edit the project file and rip out the IIS Express configuration to get back up.

Who the hell thought it was a good idea to place the configuration in the project file? IIS configuration should NEVER be in the project file since it would only ever work if every one had the same physical layout of folders and files on each computer...
Posted by kipus0ep on 11/5/2013 at 4:21 AM
Seriously?! Microsoft?!
This is a really DUMB fault, someone should get fired for this ASAP!
Posted by David Warner on 10/23/2013 at 3:43 PM
Really hoping for a fix for this issue in Visual Studio 2013 Update 1 (assuming such an update is planned). The UI missing this option is annoying, but the dealbreaker is that some settings in .csproj.user like 'IISUrl' are not just ignored but overwritten when starting a web project in VS2013.
Posted by Marc Gravell on 10/22/2013 at 2:51 AM
@Đonny note: "removed" here I believe is more of an "oops" kinda thing - as I understand it, this is planned to be resurrected. The problem is that **until then** I can't really use VS2013 for anything web-related. Which is a pain.
Posted by Đonny on 10/22/2013 at 2:17 AM
I really sucks that key features get removed from Visual Studio. This makes basically VS2013 usable only for web projects developed by single-person "teams".
Posted by Mr Scott Lowe on 10/21/2013 at 9:02 PM
In reference to the comment about VS 2013 respecting the *.user.proj settings, it does respect _some_ of the XML elements but not _all of them.

For example, the "StartAction" element is honoured (e.g. "URL"), but the "StartURL" element is not. This is preventing our team from moving to VS 2013.
Posted by AceHack on 10/21/2013 at 1:59 PM
It did not respect my settings from VS2012. In VS2012 I had Full IIS selected and it clearly said that in the .user file. But in VS2013 it still tries to use IIS Express.
Posted by David De Sloovere on 10/9/2013 at 10:35 AM
Someone will have to buy drinks for the whole team that owns that settings screen.
Posted by Microsoft on 9/23/2013 at 3:03 PM
Thank you for bringing up this issue. Unfortunately, this functionality was lost when the web project properties page was refactored. We are working to get this feature back into the product.

For now, if you have a project with this setting unchecked in VS 2012, and open it in VS 2013 it will respect your individual user settings until the first time that the servers section is modified on the web project properties page.
Posted by Microsoft on 9/23/2013 at 3:02 PM
Thank you for bringing up this issue. Unfortunately, this functionality was lost when the web project properties page was refactored. We are working to get this feature back into the product.

For now, if you have a project with this setting unchecked in VS 2012, and open it in VS 2013 it will respect your individual user settings until the first time that the servers section is modified on the web project properties page.
Posted by David De Sloovere on 9/13/2013 at 9:02 AM
This is also important if you want different branches to use a different hostnames that's linked to different sites in IIS (not express).
dev.project.localtest.me vs main.project.localtest.me
You really don't want to check this into source controle either. After merging it's gone.
Posted by Sara [MSFT] on 9/10/2013 at 6:56 AM
Thank you for submitting feedback on Visual Studio and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Macy [MSFT] on 9/9/2013 at 6:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)