With regards to ASP.NET Development, I’ve been doing things “my way” for a long time since 1.0 of the framework. I’m a die-hard web forms old stick in the mud (yes I am growing to like MVC, but its slower for me to get going with.
Anyway…over the years I’ve gotten into the habit of running IIS and SQL Server directly on my development machine, this made my life easy up until we started hiring additional developers and updating O/S or migrating computers…it’s always a bear to get going again. Ideally I’d make a VM development environment that was shareable, similar to what I’m doing with Drupal / Vagrant. But the Windows VM world seems less scriptable (I think?) and way more manual and it doesn’t really solve the issue of O/S upgrades.
Anyway, here I’m sitting with a pretty clean Windows 10 Install, so I’m going to outline some things I’ve done that have helped me and that I’ve wasted too much time researching.
Run Visual Studio as Administrator
Microsoft has it seems changed the definition of Administrator. Mentally you think this means you have complete control / rights to everything on the box, but you don’t. I’ve gotten so many stupid access is denied errors when dealing with ASP.NET projects that seem to go away by running as administrator. With that said, right clicking and running as admin everytime sucks.
This stackoverflow article goes over how to change the devenv.exe settings to run as admin. http://stackoverflow.com/a/9654880
In earlier versions of VS, IISExpress seemed to really slow down the build/debug step, it seems to have gotten faster. With that said, default configuration is to force you to use localhost:RANDOMPORT — good news though! you can override this using the Override Application Root URL under Project->Properties->Web — however for some reason you also need to manually edit the applicationhost.config now stored in .vs/config — Also be sure to change the Start-up URL. Don’t forget to update your hosts file with the appropriate pointer.
Exclude .vs from GIT
The .vs folder and the configs it contains are meant to be machine / user profile specific and as such shouldn’t go into source control.
Traditionally I would host my own SQL Server, but in retrospect this leads to some long term issues, specifically around sharing changes across teams. Instead we are migrating now to a centrally stored SQL Server with PROD and DEV versions of our SQL Data. We use Windows Auth for our connection strings thus eliminating the need to manage passwords