3 votesCraig E. Shea shared this idea ·
I must say, having a "repair" installation wipe out my customized settings and extensions is very poor UX and runs contrary to what MSI is supposed to be able to provide: repairing of an application's image on the hard disk--exclusive of user settings.
If user settings are the problem causing VS to not start properly, there are other ways for users to deal with this, such as starting VS without extensions. But wiping out user settings on a repair installation just seems counter-intuitive. And for me, it's extremely counter-productive, losing me a whole day of "productivity". Instead of writing code after an hour's worth (or more) of repair time, instead, I spend the rest of the day reinstalling my extensions and reconfiguring my environment! What a time-suck.
For the record, all 4 of the above are what made this extension simply AWESOME. Without them, the extension is rather useless and was achievable with other extensions that were previously available. I used each of the 4 features above extensively EVERY DAY when in the IDE.
Definitely missing the colored lines per structure--this is what set this particular extension apart from other similar extensnions. A step backwards if you ask me!
Really? I just came across this today...performed a rename, but my @model directives weren't updated. So, the whole point is that these "refactor" helpers make refactoring safe. Well, guess what? They're not safe.
This is a great idea! We completely understand how auto-switching SCC providers would help increase your productivity. Although we plan to make this available to you in the near future, we are still in the planning process and may reach out for your feedback as we start to define how tackle this problem. We will check back as soon as possible with any updates to this request. Allison Buchholtz-Au: VS Program Manager
I whole-heartedly agree. I think a common scenario would be your company, for whatever reason, uses TFS VC. You want to "try something out", which isn't so easy to do with TFS VC, unlike Git, where you can just create a branch at any time with very low cost. Unfortunately, this means changing the source code control provider in _the IDE_. Why at the IDE level? That doesn't make sense for a lot of reasons already mentioned: many people write code on projects spanning different VCS systems (e.g. legacy apps in VSS or TFS while newer ones are in Git or Mergurial). So everytime they open a new IDE, there's a 50% chance (or more, depending on the number of VCS's in use) that the VSSCC will need to be changed. Ugh..