4 ms·

I'm a junior developer who's been working with C#/.net/VS for about six months with very little guidance, so maybe take this with a grain of salt, but in my exp

I'm a junior developer who's been working with C#/.net/VS for about six months with very little guidance, so maybe take this with a grain of salt, but in my experience Visual Studio is regularly an impediment. We had a single with our setup project that took us a week+ of man-hours to resolve, stemming from someone opening a project up in VS 2010 instead of 2008, and then committing the changes. Almost every time I check out a project some of the assembly references are messed up. There are always more errors when I check out code than when I last checked in the project. It regularly takes me about half an hour to go from "Hm, let me fire up this project" to "okay, I'm at the breakpoint". In an environment where I'm working on like five projects, this seems nuts to me. Coming from python and php, the syntax highlighting is pretty sweet (but then, using the python REPL, I hardly needed it. It's sort of like "look at this problem you didn't have before that we solved!"), and I'm starting to understand why people like static typing, as it reduces certain classes of errors. I think I want to go back to python and Vim or Notepad++, though.

ebrenes 14y ago
All abstractions are leaky. Visual Studio and its associated files are meant to act as helpers and thus abstract away several details of the project, what it does with them but there's still a process to it all. Project files are like build scripts and changing them can cause breaks. Just like wanton changes in a build script can do the same. If you proceed working with VS, I'd suggest familiarizing yourself with project files and how they're set up. All automated processes make assumptions and rely on certain conventions. I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims. For new developers I generally recommend they review all changes they commit, including project files. Just because its an abstraction or things happen automatically doesn't mean you can just push all changes into the repository. When you open a 2008 project in 2010 you are prompted that changes will take place for example, so it's not like it was a stealth change. Once they're properly set up project files are pretty maintenance free, but certain behaviors can make them unstable to use. For example, if you need to support both VS2008 and VS2010, just create duplicates, it's no different than having build scripts that are not backwards compatible, you'll have to keep multiple versions around. Or just keep the VS2010 conversion locally and don't commit that back into the repository. Anyways, you can go back to a simple text editor and just use msbuild manually, if you prefer keeping track of everything manually. best of luck!
- roflc0ptic 14y ago
  >> I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims. That's pretty valid. We may be living in an edge case, and I trust that if everyone's experience with VS was as bad as mine, it just wouldn't get used. Thanks for your thoughts.

ebrenes 14y ago

All abstractions are leaky. Visual Studio and its associated files are meant to act as helpers and thus abstract away several details of the project, what it does with them but there's still a process to it all. Project files are like build scripts and changing them can cause breaks. Just like wanton changes in a build script can do the same. If you proceed working with VS, I'd suggest familiarizing yourself with project files and how they're set up. All automated processes make assumptions and rely on certain conventions. I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims. For new developers I generally recommend they review all changes they commit, including project files. Just because its an abstraction or things happen automatically doesn't mean you can just push all changes into the repository. When you open a 2008 project in 2010 you are prompted that changes will take place for example, so it's not like it was a stealth change. Once they're properly set up project files are pretty maintenance free, but certain behaviors can make them unstable to use. For example, if you need to support both VS2008 and VS2010, just create duplicates, it's no different than having build scripts that are not backwards compatible, you'll have to keep multiple versions around. Or just keep the VS2010 conversion locally and don't commit that back into the repository. Anyways, you can go back to a simple text editor and just use msbuild manually, if you prefer keeping track of everything manually. best of luck!

roflc0ptic 14y ago
>> I've yet to meet an automated process that can adapt itself to any situation to suit its user's whims. That's pretty valid. We may be living in an edge case, and I trust that if everyone's experience with VS was as bad as mine, it just wouldn't get used. Thanks for your thoughts.