Edit: Scott initially said "I will be in the update", not it will be in the update...
You play this kind of game with "automation" and you get burned. Build, configuration and deployment management are hard software problems and they need to be solved by smart people and real tools, not checkboxes and file selectors.
But even then, I need different settings for debug/release or x86/amd64 - and it's not really helping when there is incosistent naming across SDK's coming from Microsoft itself - where you can't match with one variable (say $(Target)) the given architecture, and it seems every group at Microsoft follows different conventions of how to name things.
You can't hack what you can't see, basically. And changes to the project file (or whatever other "wizard guided" IDE output you're using) are opaque by definition.
I am having a hard time truly understanding the difference (not that we use VS stuff for deployment anyways, but that is for other reasons).
A developer could add custom deployment info to the manual file and accidentally commit it just as easily.
You just do not like GUIs (which is a perfectly acceptable stance) but it has nothing to do with some fundamental difference.
Just because they supply a GUI doesn't mean it's the only way to change project settings. I'm not sure what led you to believe that.
While I'm probably in the minority, I edit my *.csproj files by hand and build from the command line for several of my projects. I do this for the exact reasons that you mention: I like control in the engineering process.
I'm unhappy that VS 2013 is putting user settings in the proj file willy nilly and I hope that it's fixed soon.
Your distinction is convenient and meaningless.
"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."
I had to re-do our TeamCity integration when they stripped out the IIS Path property out of the project file in favor of publishing profiles. For a shop like ours, where we have lots of small projects, automating the deployment is pretty critical. I don't want to have to add 120 publish profiles when previously I could rely on the project settings.
Ultimately, we hacked together a fix, but I'm still wary of their changes.
This bug is more of an issue for OSS than a company. IMO.
We have a dev environment where all our code builds upon checkout and then we have our own local environments to actually do development on. What's the problem with someone deciding that they want to run at hostname alias so-and-so on their local machine or port whatever instead of what's the default?
So basically you're saying is Stack Exchange development team does what ever the fuck they want to do?
You didn't give anywhere near enough information for someone to come to the conclusion he came to. And the anger with which he presents it is uncalled for.
(and possibly the ability to downvote)
I've been here for far longer than you and I'm still stuck in the 300 karma range. Why? Because of my timezone. Most people are asleep when I'm awake.
It is virtually impossible for me to submit an article and have it viewed by a large number of people before it is pushed off the front page. So all my submissions get low score, only for the same article to be submitted later in the day once NY and LA have woken up and get big karma scores for someone else. I've given up submitting, which is how you accumulate the big karma scores.
Unless you don't trust the basic competence of your team (in which case, it is probably time to find a new team), I don't see the need for that degree of uniformity.