There's a difference between how secondary references are resolved when building within Visual Studio, and how they're resolved on the build server. So a solution that builds fine locally might fail on the build server with an error similar to this:

Reference required to assembly 'System.ServiceProcess, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' containing the base class 'System.ServiceProcess.ServiceBase'. Add one to your project.

There are a number of potential solutions to this, but one of the cleanest is described on stack overflow and on this blog. I kept getting this error when compiling locally, though:

A problem occurred while trying to set the "References" parameter for the IDE's in-process compiler. Error HRESULT E_FAIL has been returned from a call to a COM component

The final solution for me was to add the following to the offending project files, right at the end, just above the closing project tag:

<Target Name="AfterResolveReferences"> 
 <!-- Redefine referencepath to add dependencies-->
 <ItemGroup Condition=" '$(BuildingInsideVisualStudio)' != 'true' "> 
 <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath>
 </ItemGroup>
</Target>

This causes the build to pick up secondary references, with the condition forcing Visual Studio to ignore the contents of the ItemGroup tag (and thus do nothing at all.)

In this case the opposite of true is not false; I think it's empty string on the build server. The not equals condition does the trick.

We were getting this error in the design view for our WPF application, only on some machines:

Could not create an instance of type 'TypeExtension'

The class reference was resolving correctly; if it doesn’t you get an error message to that effect. however the reference was to a class defined in a different project; this seemed to be the root of the problem.

Turns out this is a designer bug that is fixed in Visual Studio Service Pack 1. Check your version on Visual Studio’s about dialog; if you don’t see an “SP” in the version you need the service pack.

Config merge is something I whipped up in response to a discussion with my colleague Jon about config files. Configuration files are always a pain in team development, and I thought this solution was interesting enough to merit a code project article. We'll see. :-)

From the introduction:

This article describes a solution to the perennial problem of config file management for multiple developers and environments. The centerpiece is a command-line tool which merges the base (default) configuration file with a truncated file (the differences or "diff" file.) This diff file contains only those elements which need to be added or changed.

You can find the article and code on code project.

Batch files are one of those things I work with so infrequently that I have to research some aspect of them every time.

Today's problem: How do I intentionally fail the build in Visual Studio when my utility program fails?

To bubble an error from a command-line utility, return an error code from the Main() method:

static int Main(string[] args)
{
    int retval = 0;     // success code

    try
    {
        ...
    }
    catch (Exception ex)
    {
        // Return an error code so the caller knows there was a problem
        retval = 1;
        ...
    }
    return retval;
}

If the pre- or postbuild event called the utility directly, you're done; the build will fail.

But if a batch file called it, you need to catch the error in the batch file and bubble it back up:

MyUtility.exe %arg1% %arg2%
:: In case of error, bubble up to visual studio
IF ERRORLEVEL 1 EXIT 1

That link will also explain how to catch different error codes, in case you need the batch file to do more intelligent processing.

It's also possible to mess around with how Visual Studio handles error codes.

I just got a new machine, and when I tried to load my website project to VS2008, I got a COMException from the conversion wizard for the web project.

I found some references to this - apparently it's caused by the user account not having access to IIS. The workaround was to run Visual Studio with administrative privileges, but this didn't work for me - presumably because I'm running Vista Home Premium, which doesn't have IIS installed at all.

My solution was to switch the project over to Visual Studio's built-in web server on another machine, check in the changes, then open it on my personal machine. If you're upgrading to 2008 on a single machine, I guess the solution is to switch over before trying to convert the solution.