Visual Studio

warning: Creating default object from empty value in /home1/seocactu/public_html/csharptocsharp/modules/taxonomy/taxonomy.module on line 1388.

Recently installed Visual Studio 2013, and was shocked to find out that, by default, web projects aren't supported, unless you check the "Microsoft Web Developer Tools." There's an extra 30 minutes of my life I wish I could get back :)

In Visual Studio, how many times a day must I click the Reload All button? Switching between many branches a day, this has definitely worsened with the increased usage of git. Apparently the git + VS plugin is supposed[?] to help this, but in my minimal testing of it, it just doesn't cut it performance-wise.

So, how many times you ask? Doesn't matter. Anything > 0 is too many.

This is a neat trick that you can use if you're not using Visual Studio 2010 yet. It allows you to have multiple web.config files for each type of build configuration that your project has. No longer do you have to do any sort of copy/paste. Plus, if you use something like MSBuild in, it will work there too (if you're building from the sln file)!

You will need to create two additional web.config files. I name them like this web.buildConfiguration.config where buildConfiguration is Debug, Release, etc. Each of your new config files will contain the settings appropriate for the build configuration you are targeting.

Open your project properties and select Build Events. Under the 'Pre-build event command line' paste this in :

if $(ConfigurationName) == Release copy $(ProjectDir)Web.release.config $(ProjectDir)Web.config
if $(ConfigurationName) == Debug copy $(ProjectDir)Web.debug.config $(ProjectDir)Web.config

when you build, your web.config will be replaced with the correct one for _that_ build configuration.

I work for a fabulous company, I've been with them for about 3 years. They are incredible about making sure developers have what they need to get the job done, whether it's software or hardware (or classes, or books). In fact, I'm on my third development machine! Most software requests are usually also granted.

So what does your gear look like? What development software has your company gotten for you to help better your work?

This is what it looks like for me:(as of posting)


  • Windows XP 64, core 2 quad @ 2.5 GHz, 8 gigs of ram
  • 3 19 inch widescreen monitors
  • microsoft natural ergo keyboard
  • trackball mouse
  • physical server 03 box [for testing]
  • various XP/03 virtual machines [more testing]


  • Resharper 4
  • dotTrace
  • NDepend
  • NCover complete
  • RegexBuddy
  • BareTail Pro
  • All the microsoft dev. stuff (VS 03,05,08, SQL server 05,08)
  • Snag it
  • ultramon

What about you?

kick it on

So here's a short follow up to a comment from anonymous2 in the Visual Studio automate testing post. Anon2 was right! I totally needed coverage and fxcop to be built into the build process... so here we go with another attempt at using Visual Studio's post-build events to automate testing [and make it even hotter!].

With the suggestion from this comment. All of these items are now fully contained in the project. All tools live in the project's /lib folder and all results live in /reports.


set NCOVER=C:\SVN\TNCMSDemo\trunk\lib\ncover\NCover.Console.exe
set NUNIT=C:\SVN\TNCMSDemo\trunk\lib\nunit\nunit-console.exe
set NUNITXML=C:\SVN\TNCMSDemo\trunk\reports\nunit.xml
set FXCOP=C:\SVN\TNCMSDemo\trunk\lib\fxcop\fxcopcmd.exe

copy /Y "$(ProjectDir)Web.config" "C:\SVN\TNCMSDemo\trunk\TNCMSTest\App.config"

%NCOVER% %NUNIT% /xml %NUNITXML% "C:\SVN\TNCMSDemo\trunk\TNCMSTest\bin\Debug\TNCMSTest.dll" //x "C:\SVN\TNCMSDemo\trunk\reports\Coverage.xml" //l "C:\SVN\TNCMSDemo\trunk\reports\Coverage.log"

%FXCOP% /project:C:\SVN\TNCMSDemo\trunk\tncms.fxcop /out:C:\SVN\TNCMSDemo\trunk\reports\FxCopReport.xml

"C:\SVN\TNCMSDemo\trunk\lib\nunit\nunitresults\nunitresults.exe" %NUNITXML% C:\SVN\TNCMSDemo\trunk\reports\

Now some explanation:
We set some vars because programmers are lazy like efficiency.
set NCOVER=C:\SVN\TNCMSDemo\trunk\lib\ncover\NCover.Console.exe
set NUNIT=C:\SVN\TNCMSDemo\trunk\lib\nunit\nunit-console.exe
set NUNITXML=C:\SVN\TNCMSDemo\trunk\reports\nunit.xml
set FXCOP=C:\SVN\TNCMSDemo\trunk\lib\fxcop\fxcopcmd.exe

We copy a Web.config to an App.config of our test project to do 'expectation' assurance / testing.
copy /Y "$(ProjectDir)Web.config" "C:\SVN\TNCMSDemo\trunk\TNCMSTest\App.config"

Here's where the sauce begins to flow. I call NCover (shorthand as %NCOVER%) which calls NUnit console (%NUNIT%).


I designate a custom-named xml output file for the nunit process with the /xml switch.

Next is the path to the dll to test

The //x switch is for a custom-named coverage xml file (in this case, I want to control the location)
//x "C:\SVN\TNCMSDemo\trunk\reports\Coverage.xml"

The //l switch is for a custom-named coverage log (again, I want to control the final location) [we're almost done!]
//l "C:\SVN\TNCMSDemo\trunk\reports\Coverage.log"

Now I call FxCop's command line utility app.

Here is the reference to the .fxcop project file I made with the actual FxCop desktop app

And here is where I want its output to go.

Finally, I use NUnitResults to generate a nice html report.

%NUNITXML% is the path to the nunit xml file (see above)

And here is the directory that I want it to live.

Now that you have that sorted out, you can spend your time crafting hot c0de.

Stuff you will need to accomplish the above:
NUnit console
NCover console

If you thought that was the opposite of teh suX0r, or something to add/fix/nuke... leave a comment [or kick it]! (or leave one anyway)

kick it on

This isn't really new, I know, I know I've heard it all before about ReSharper. "ReSharper is ok but...," or "It's expensive..." or "Blah blah ReSharper...," or some other comment from some jerky developer deeming it useless. Even if you think the rewards aren't that great in terms of orgiastic programming results;
think about your hands (and fingers), and all the wasted keystrokes. Damnit.

Scott Hanselman discusses the programmer's hands and how important they are to your career (BC: and of course, your life). Although ReSharper may not indeed save you from some terrible hand condition... Everything helps.

I spent hours a day for years in my past life as a classical musician honing finger movements for ultimate efficiency. Why? Because you want to be able to pick your nose when your 80.

Yes I have a crazy ergo keyboard and trackball rat.

In any case. My comment to the unbelievers is:

Have fun wasting your time. [loser]

I am in no way affiliated with ReSharper, JetBrains, or any other Visual Studio plugin like CodeRush. I'm just a coder d00d. But, like me, if you're in a situation where the company you work for supports time-saving tools for their developers, then you need some sort of Visual Studio add-on (or whatever IDE) like this.

I've tried "convincing" other developers and showing them how awesome it is--turning a huge list of private items to public getter/setters should have been enough--but no one seems to care! For me: incorporating, LINQ and extension methods in 3.0 is the best part. For months I dealt with all the broken [looking] LINQ queries with ReSharper 3.1--but no more!

So to anyone that hasn't tried it for Visual Studio 2008... here are the ReSharper 4.0 nightly builds for your pleasure...

And for anyone else I say: remember your digits... and I give thee this.

broken developer finger

kick it on

Whether you're into test driven development (TDD) or test after development (TAD), or you're into having your code get br0xored by not testing (doh!)... unit testing is all over the development world. You're a silly-goose if you haven't heard about it. In any case, using Visual Studio's post-build event process is a nice way of making sure your tests are always executed after a build. Though this isn't news to most developer 'dudes,' it surely made me all hot and steamy when I did it!

To do it you'll need the following:

  • Visual Studio (no duh)
  • Some sort of command line unit test app... like nunit console
  • A new pair of pants after you see how rad this is.

So, you go here:
Visual Studio -> Project Properties -> Build Events

And add this line, pointing nunit-console to the DLL of your project:

"C:\Program Files\nunit\nunit-console.exe" "C:\SVN\Proj\trunk\ProjTestProj\bin\Release\ProjTestProj.dll"

And that's it! Get ready for the hotness!

But wait! There's more!

As an added bonus... I add this line before the line above...

copy /Y "$(ProjectDir)Web.config" "C:\SVN\Proj\trunk\ProjTestProj\App.config"

This enables "Unit testing" (or more like expectation testing) of the Web.config file by copying it over to the Unit Test project as App.config. When this happens, you would be able to talk to it in your Test project via the ConfigurationManager. For example:

Assert.AreEqual("666", ConfigurationManager.AppSettings["SomeImportantNumber"]);

kick it on

Heavy Metal Rock and Roll.

About Brian

profile for bluevoodoo1 on Stack Exchange, a network of free, community-driven Q&A sites

Brian Canzanella brings you nifty tips and tricks for most things .NET. read more...

Readers / Stuff