VS2010 Project fails to build when BuildPackage is set to true

Sep 8, 2011 at 6:22 PM
Edited Sep 8, 2011 at 7:25 PM

Error List:

Error    1    Unable to find 'Catalog.API.dll'. Make sure the project has been built.

Error    2    The command ""C:\Projects\AIO\Catalog API\.nuget\nuget.exe" pack "C:\Projects\AIO\Catalog API\Main\Catalog.AIP\Catalog.API.csproj" -p Configuration=Debug -o "C:\Projects\AIO\Catalog API\Main\Catalog.AIP\bin\Debug"" exited with code 1.


<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
    <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\..\</SolutionDir>

When the <BuildPackage> is set to false the project builds without issues.  Also the same exact code works on three colleague workstations but not on mine making me think that there must be something wrong with mine.  I have VS2010 Service Pack 1 installed.  I have installed, uninstalled, and installed the Nuget extension, restarted VS after each.  I have also restarted my machine.  Any ideas are welcome.  

Thanks in advance.

Sep 8, 2011 at 6:29 PM

Did you change the output directory? If so, how and where did you change it to?

Sep 8, 2011 at 6:47 PM
Edited Sep 8, 2011 at 6:48 PM

No I didn't change the output path.  It's set to "bin\Debug\" currently.

Sep 8, 2011 at 6:59 PM

Strange, the error is complaining because it can't find the output dll for your project. Can you look in bin\Debug and see if it's there?

Sep 8, 2011 at 7:05 PM
Edited Sep 8, 2011 at 7:05 PM

I agree that this is very strange - I can paste the C:\Projects\AIO\Catalog API\Main\Catalog.AIP\bin\Debug path into explorer and the file is right there.  Like I said above when the <BuildPackage> is set to false the project builds fine.  

Sep 8, 2011 at 7:20 PM

That's because<BuildPackage> set to false turns that behavior off :). Can you run msbuild on your solution with the switch /v:diag and pipe it to an output file? i.e. (from a vs command prompt)

msbuild MyProject.csproj /v:diag > out.txt

And tell me the value of the TargetPath property?

Sep 8, 2011 at 7:29 PM

Interesting observation:

When the Catalog.API.dll file is copied from C:\Projects\AIO\Catalog API\Main\Catalog.AIP\bin\Debug up to C:\Projects\AIO\Catalog API\Main\Catalog.AIP and we attempt to build the project, the following errors are thrown:

Error    1    The path is not of a legal form.
Error    2    The command ""C:\Projects\AIO\Catalog API\.nuget\nuget.exe" pack "C:\Projects\AIO\Catalog API\Main\Catalog.AIP\Catalog.API.csproj" -p Configuration=Debug -o "C:\Projects\AIO\Catalog API\Main\Catalog.AIP\bin\Debug"" exited with code 1.

Sep 8, 2011 at 7:40 PM
Edited Sep 8, 2011 at 7:41 PM

TargetPath = Price.Catalog.API.dll

On my colleagues machine he has a full path:

TargetPath = C:\Projects\All-In-One\Catalog API\Main\Price.Catalog.AIP\bin\Debug\Price.Catalog.API.dll

I think we found our problem. How can this path be set?

Sep 8, 2011 at 7:43 PM

Not sure why it's not the full path on your machine. Any msbuild property can be set either in the project file using <PropertyName> syntax or passed via the msbuild command line when you run the command. But target path is something that the default msbuild targets will calculate based on output path and other properties in your project. When you create a brand new project is it a full path?

Sep 8, 2011 at 7:52 PM

Its the same for all my projects.  I also created a new project and had the same result.

Sep 8, 2011 at 8:04 PM

Just an FYI - I will keep on digging but this is what I found so far:

In my project properties -> Build Events -> Pre-build event command line -> Edit Pre-build ... -> Macros>>

The TargetPath Macro contains the correct fullpath value.

Sep 9, 2011 at 3:01 PM

More findings:

The issues appears to be with msbuild after a call to the cproj file.  If we check msbuild before this call the correct fullpath is returned.  However the .cproj call returns only the file name.  Does anyone know if this is configurable anywhere?

Call:  return _project.GetPropertyValue("TargetPath");

From ProjectFactory.cs CommandLine project From NuGet solution.

Sep 9, 2011 at 3:02 PM

Also as an FYI I reinstalled my VS2010 - no dice

Nov 25, 2011 at 7:24 PM

I'm also seeing this issue. Project builds fine until I change BuildPackage to enable building. Then I see the exact same issue. Build fails if it's enabled, succeeds if it's disabled (default state).

Negative on the dice as well.

Jan 15, 2012 at 7:30 PM

Hi there - we've been encountering the same problem, but I think we're starting to get some leads as to the cause of the problem.

Out of curiosity, if you use msbuild to build the sln, do you receive a error about the configuration? Would be keen to compare notes with you on this to resolve it.

Look forward to hearing from you!

Jan 31, 2012 at 1:36 AM
Edited Jan 31, 2012 at 2:25 AM

To anyone who reads this further on, I've done a lot of work with colleagues on this issue and discovered the following:

The scenario is caused by an System Environment Variable being created by SQL Server at install - this environment variable overwrites the local Platform variable used by MSBuild. This means it tries to 'build' using the wrote platform (doesn't tell you this unless you try an msbuild which gives a more obvious error) and therefore doesn't know the TargetPath.

The problem is 100% machine specific and many users will not even know they have an issue until they either try and retrieve the TargetPath due to a coding requirement or use a solution which uses it (such as nuget BuildPackage).

What won't work:

Uninstalling VS, SQL Server, nuget etc.

Reinstalling your machine if you install SQL Server first (we had SQL Server 2008 R2 full install) followed by Visual Studio.

What we have found to work twice:

Close Visual Studio and stop looking at the errors in there.

Use msbuild (run from Visual Studio 2010 Command Prompt) - build your solution. If you get errors about building for an invalid configuration then this solution is for you. In our case it was trying to a configuration for Target Platform "BPC" (which wasn't ours).

Open the windows system variables (requires Admin priveleges).

Find the system variable called 'Platform' and remove it. (In our case, this variable had 'BPC' set, hence the previous error in msbuild)

Restart (important - the fix will appear not to work otherwise)

Try using msbuild again - it should work now.

Open Visual Studio and try building again - it should work now, complete with nuget package creation as part of PostBuild.


Disclaimer: The BPC environment key is used by SQL Server Integration Services (SSIS) - I don't yet know what it's removal will do to SSIS. If SSIS is crucial to your development stack, then I recommend further investigation.

I would really like to hear from other people if this helps them. If it doesn't help you, please say so - I will continue to look at what I missed.

Mar 12, 2012 at 11:02 PM

We had the same issue and thanks to hanzworld the above process fixed the issue.

Another way to look at this issue is that NuGet package manager in VS2010 is not requesting a specific platform on the command line that it generates to call nuget.exe.

When I cut and pasted the nuget command that VS2010 was trying to execute I also got the same error.

If I change -p Configuration=Debug to be -p Configuration=Debug;Platform=AnyCPU then the nuget pack command works fine from the command line without having to delete the Platform=BPC environment variable.

Shouldn't the package manager in VS2010 specify the platform? What would happen if I wanted to build a DLL that had multiple platform targets?


Apr 30, 2012 at 7:05 PM

I also had this issue; I resolved it by applying WinMerge to a project that I knew to be working and to the project that didn't, then merged over anything that wasn't specific to that project from the working project to the non-working project.

May 28, 2012 at 3:08 AM
Edited May 28, 2012 at 3:25 AM

Arrrrrgh! Bitten by the Platform environmental variable AGAIN!

I recently rebuilt my system and TOTALLY forgot about this issue!

See : http://social.msdn.microsoft.com/Forums/en-US/msbuild/thread/3c4e9c3f-2bf2-436e-80de-e000a7dda8bd

Thanks hanzworld!


Jul 16, 2012 at 12:51 PM

hanzworld's solution worked perfectly for me as well, having the exact same issue. Thank you very much,


- Nikolaj