Partager via

MSBuild Known Issues

  • Article

Since the release of Visual Studio 2010 we have received a few reports of crashing behavior which can be traced back to issues with MSBuild.  We’ve analyzed all of these and there are several particular cases where a crash can occur.  We’ve also added a notification to Windows Error Reporting to help guide those who hit these errors.  You can determine you your error is one of these either by matching the problem description below, or looking in the Event Viewer as follows:

  1. Open the Event Viewer
  2. Search for Information events with ID = 1001 and Source = Windows Error Reporting.  Look for those with the time that approximately matches when you saw the crash.
  3. At the top of the details pane for the event is text that would look like the below.  If the bucket number is not 1055654512, then this post may not apply to you.

Fault bucket 1055654512, type 1

Event Name: APPCRASH

Response: xxxxxxx

Cab Id: 0

Crash when debugging using F5

Problem: This can occur if the build process is missing a required target.  This is normally due to an improperly customized build process.  If you are using the .NET MicroFramework 4, which is not supported in Visual Studio 2010, you may also see this issue.

Solution: Provide the missing target.  Try building the project/solution on the command-line.  If MSBuild logs an error that a target is missing, that could be the problem. 

Crash when registering COM component

Problem: COM registration requires the user have permission to certain registry keys, and lacking that permission the RegASM task crashes.

Solution: Ensure the registry keys needed to perform the registration are accessible to the account doing the registration.  Look under HKCR\Record for the GUID matching the type (or types) associated with the COM components you are registering.

Invalid Project Exception when building with .NET MicroFramework 4

Problem: When building projects with Visual Studio 2010 and the .NET MicroFramework 4, the build would fail with an InvalidProjectFileException.  The .NET MicroFramework 4 is not compatible with Visual Studio 2010.

Workaround: There is unfortunately no workaround for this.  According to the .NET MicroFramework 4 team, the next version of the MicroFramework will support VS2010.  Check out https://www.microsoft.com/netmf/default.mspx for updated information.

MSBuild throws an error that it cannot find msbuild.exe

Problem: Building on the command-line or from Visual Studio displays an error that MSBuild could not find MSBuild.exe during a C++ or multiproc build.  If your username is exactly 20 character long excluding your domain (the maximum allowed under Windows), there is a bug in the .NET Framework which will prevent us from authenticating the other MSBuild nodes.

Workaround: Build under an account with a name that is less than 20 characters.  The bug should be fixed in the next version of the .NET Framework.

MSBuild throws an OutOfMemory exception

Problem: Your build in Visual Studio aborts with an OutOfMemory exception.  It may or may not also do this when built from the command-line.  This occurs typically when there are a very large number of projects with a lot of interdependencies, or when projects have an extremely large number of source files.

Workaround: Build your solution on the command-line, so that your process does not have Visual Studio’s initial memory foot print; or build on a 64-bit machine under a 64-bit command window so we can take advantage of the additional virtual memory spacel or split your solution into smaller chunks which can be built individually; or create a solution configuration in which only a subset of your projects build.

Visual Studio crashes when building a solution containing C++ and WiX projects

Problem: When building a solution which contains C++ and WiX projects, Visual Studio may crash.

Solution: This problem has been traced to a bug in the WiX project system.  Please contact the WiX project for a newer version with the correct bits.

Other issues

For some crashing issues we have set up Windows Error Reporting so that it will automatically request for you to send us additional information and contact us directly.  If you see such a request, please consider providing us with the requested additional information so we can either determine that your issue is already known or address it in the next version of the product.

Comments

  • Anonymous
    November 30, 2010
    Since I can't find a contact button on this blog, I'll do it this way. I am using .NET 4.0 and am wondering how it is determined whether or not the target name should be included in the build output. My build file includes 3 targets: Initialize, Clean and Build. Build is the default target and has DependsOnTargets="Initialize;Clean". The Clean target has DependsOnTargets="Initialize". I run the script without passing a target so the default target gets executed. The build output shows like this:

Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 12/1/2010 9:20:39 AM. Project "d:buildproject.proj" on node 1 (default targets). Clean:  Message from Clean target Build:  Message from Build target

Notice how there is no mention of the Initialize target being executed. Note that the script works as it should, so apparently the Initialize target gets executed. It's just not visible. Is this because there are no Message tasks in the target? Or is it something else? Or does this actually tell that the target is NOT executed?? Thanks, David