I'm running the following msbuild command
msbuild /verbosity:normal /property:configuration="Release"
/property:VisualStudioVersion="12.0" /m /property:RunOctoPack="true"
/property:OctoPackEnforceAddingFiles="true" /target:"Clean" ../MYSLN.sln
which builds successfully.
I just tried running the same command using xbuild on OSX so:
xbuild /verbosity:normal /property:configuration="Release"
/property:VisualStudioVersion="12.0" /m /property:RunOctoPack="true"
/property:OctoPackEnforceAddingFiles="true" /target:"Clean" ../MYSLN.sln
which reports
MSBUILD: error MSBUILD0004: Too many project files specified
I have XBuild Engine Version 12.0 and Mono, Version 4.0.2.0
Is there some subtle mistake in how I'm listing the parameters
----EDIT----
That's being thrown here: https://github.com/mono/mono/blob/master/mcs/tools/xbuild/Parameters.cs#L140 which suggests that xbuild isn't picking up the solution file (I think)
NB, I've tried with the solution file as the first and last parameter to no avail
----EDIT----
I've added that the solution file has an uppercase name in case that is important.
----EDIT----
Ah, I've been writing a test around their parameter parsing code and it isn't recognising /m
So, I grabbed their source and wrote a test to see what was happening. And xamarin doesn't recognise the /m parameter. That's a real parameter for xbuild so I've logged https://bugzilla.xamarin.com/show_bug.cgi?id=33388 to see if they purposefully don't support it
TLDR; currently xbuild doesn't support /m as a parameter
Related
I'm attempting to do a command line package deploy for our Windows Store Application.
My command line instructions are:
msbuild /m /p:Configuration=Debug /p:Platform=x86 /target:Build
I'm using VS2013 Professional with Windows 8.1
I get the following error:
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Task 'GenerateAppxPackageRecipe' failed. Value cannot
be null.\r [C:\Path\Project.csproj]
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets(1224,9):
error APPX0002: Parameter name: source\r [C:\Path\Project.csproj]
How should I resolve this?
This error was resolved by using the correct version of msbuild.exe
On a clean build server with VS2013 installed, there are (at least) two copies of msbuild.exe installed. In our case the install locations were:
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe
and
C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe
The one in the .Net Framework folder was the one that gave us the errors. Using the version installed in the Program Files folder resolved the issue.
It's impossible to help you without having the code which can reproduce the error. I suspect some property does not resolve correctly when building outside VS(eg VisualStudioVersion) and needs to be passed from command line. VS also uses msbuild to build your projects, so comparing build logs from VS and CMD should help you track down the problem.
I suggest, that you set visual studio's build output verbosity to diagnostic, clean solution, than build and capture the build log.
Then clean solution and build from command line with verbosity set to diagnostic and /fl switch(log to file, because diagnostic build log is way too long to analyse in console window).
Compare command-line output to VS output. Look for the differences. With diagnostic level of verbosity, chances are, you'll find out what's missing (I had similar issues with database projects failing to build from cmd due to VisualStudioVersion variable not being resolved correctly, so I passed it from command line).
NB: diagnostic log is very verbose which makes analysis hard: I'd start from detailed verbosity level.
I have deleted all files/folders from "project"/bin folder, cleaned the solution and rebuild with success !
For those facing the issue on hybrid app (corodova in my case), delete the build folder manually and re-build from VS.
Standard clean solution didn't do the job.
Do any GUIs exists for processing and running rake, msbuild or nant files?
Although I don't mind working with the command line I still find that I occasionally have to delve into rake/msbuild files to find out exactly what a task/target does or what arguments they expect.
Ideally I'm looking for something that lets you only input valid arguments for the task/s you're running.
There is a GUI for MSBuild called MSBuild Explorer
Note: I'm using Mercurial as an example here, because that's what I'm trying to get to work with MSBuild right now.
But the problem is not limited to Mercurial, it happens with every external program that is somewhere in my %PATH% variable (I tried the same with PowerShell, for example).
So I didn't put the Mercurial tag on this question on purpose, because this is not about Mercurial!
What I actually want to do:
I want my build script to get the current revision number from my Mercurial repository and store it in a file.
The simplest way to do this from the command line is:
hg id -i >rev.txt
Mercurial is installed on my machine and the installation folder is in my %PATH% variable.
So I can run this line from anywhere on my machine (directly from the command line, or from a batch file), and it just works.
The problem occurs when I try to run this line from my build script.
I change the BeforeBuild (or AfterBuild) section of my .csproj file as follows:
<Target Name="AfterBuild">
<Exec Command="hg id -i >rev.txt"/>
</Target>
When I compile my solution with Visual Studio, it works and the rev.txt file is created in the folder where my .csproj is.
But when I compile the exact same solution from the command line with MSBuild, the build fails with the following error message:
The command "hg id -i >rev.txt" exited with code 9009.
I googled "msbuild code 9009" and found some solutions, but all of them propose to provide the full path to the executable.
When I do this, the build succeeds with MSBuild as well.
But this is not an acceptable solution for me, because I can't be sure that everyone using my project (including the build server) has installed Mercurial in the exact same folder.
That's exactly what %PATH% is for...
The same happens when I put the <Exec Command="... line directly into the build script.
If I specify the path to the executable, it works.
If I don't specify the path, it doesn't.
Is there any trick to make MSBuild execute programs in my %PATH% variable without specifying the complete folder?
EDIT:
#leppie:
Output redirection:
You mean the fact that I save the output of my command in a text file inside the command , instead of just running hg id -i as a command and using an output parameter or something like that to get the output?
Doesn't make any difference...the error is the same when I omit >rev.txt.
Command line args:
No, it throws the same error, even if I shorten the command to just hg (without any parameters).
Don't forget: if I run the exact same Exec command in the exact same .csproj file from Visual Studio, or if I just provide the path to the .exe file in the command, everything works.
So IMO output redirection and command line args can't be the problem.
Have you tried this extension pack for mercurial/msbuild?
http://msbuildhg.codeplex.com/documentation
Seems to have a task for returning revision id, which is what your trying to achieve no?
<HgVersion LocalPath="$(MSBuildProjectDirectory)" Timeout="5000">
<Output TaskParameter="Revision" PropertyName="AssemblyRevision" />
</HgVersion>
Okay, I found the solution.
I have to admit, it was a classic case of PEBKAC :-)
I'll explain it anyway, maybe it will help someone who made the same mistake:
Basically everything I have tried (plus what James Woolfenden suggested in his answer) would have been worked...if only the batch file that I use to run the build script wouldn't have looked like this:
path="%windir%\Microsoft.net\Framework\v4.0.30319"
msbuild build.proj
Yes, exactly.
I'm editing the %PATH% variable for the duration of this batch file, and I'm overwriting it with the path to MSBuild instead of just appending it.
So when my build script tries to call Mercurial, it can't find it anymore because its location is not in the %PATH% variable anymore.
No idea why I didn't see this before.
The correct way would be to append the MSBuild path, leaving the other paths intact:
path=%path%;%windir%\Microsoft.net\Framework\v4.0.30319
How do I pass multiple ReferencePath in MSBuild in the command line. I'm currently using this
MSBuild /t:Rebuild "Solution1.sln" /p:ReferencePath="C:\My Library 1\obj\Debug; C:\My Library 2\obj\Debug"
MSBuild is returning an MSB1006 error. Take note that my reference paths have spaces in it.
Try escaping the semicolons as %3b
Try moving the quotes around the entire property expression, not just the values
/p:"Name=Value One;Value Two"
I had the same problem. This worked for me:
msbuild {{slnPath}} /t:rebuild /p:OutDir={{outputpath}} /p:Configuration=Release
Specify /p for every parameter
This wasn't working in powershell
msbuild C:\temp\project.sln /p:referencepath="C:\Checkout\References
\CRM 2011;C:\Checkout\References\Log4Net\4.0\release"
but works fine from an old fashioned cmd prompt.
No matter what I do, I can't seem to make it work using MSBuild. I now use DEVENVE.EXE to compile my solution; it would read my user project settings where the ReferencePath is saved and use that to locate the correct version of the DLL I want to use.
replacing the ';' with '3%B' seems to work in my setup with Nant and Jenkins
I've started using Code Contracts in all new code I'm writing, such as in a framework library I'm building to help bootstrap IoC, O/RM, etc., in an ASP.NET MVC application. I've written a simple build script for this framework library that looks like the following:
#echo off
echo.
echo Cleaning build output (removing 'obj' and 'bin' folders)...
for /f "tokens=*" %%G in ('dir /b /ad /s bin') do rmdir /s /q "%%G"
for /f "tokens=*" %%G in ('dir /b /ad /s obj') do rmdir /s /q "%%G"
rmdir /s /q build
echo.
echo Starting the build...
call "%VS100COMNTOOLS%\vsvars32.bat"
msbuild Integration.build /target:Build
echo.
echo Done!
pause
This doesn't work. What I end up with in my build folder if I run this is, for whatever reason, assemblies that aren't fully rewritten by ccrewrite alongside .pdb.original, .rewritten and .csproj.FileListAbsolute.txt files that litter the output directory.
What does work is first building the solution in Visual Studio 2010, commenting out line 3 through 7 in the batch file and running it again. I then end up with properly rewritten assemblies and no .pdb.original nor .rewritten files.
What I've deduced from this is that Visual Studio 2010 somehow triggers the Code Contract rewriter properly so the resulting assemblies from the Visual Studio 2010 build is re-used by the command-line MSBuild call, so what my batch script basically does is just copying files to the build directory. Rather useless, in other words.
I've read this, but Jon's problem seems different from mine since ccrewrite is obviously doing something, but it's just not completing the rewriting for whatever reason. The Integration.build file builds the correct configuration (that has Code Contracts enabled in the .csproj files) and everything else looks right, it just doesn't work properly.
So, I'm wondering: How do I run MSBuild the way Visual Studio 2010 is where ccrewrite does what it's supposed to and doesn't litter my output directory with .rewritten and .pdb.original files? Does anyone have a perfect example of how an MSBuild file doing proper Code Contracts rewriting looks like?
The answer is in the script. All Visual Studio is ever going to do is run MSBuild tasks that will invoke others. One thing you can do is go to Tools|Options|Build... and turn on logging so you can see in detail which bit is doing what to generate the artifacts.
How would one do such a complex and involved thing? Read a guide to MSBuild such as Hashimi p1 and Part 2.
Then dig into the source for the build in e.g.:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
The best way to get there is to open your .csproj and look what it includes and go via that (the .CSharp.targets is the first one - the one I cited comes further down the stack).
(That and wait for someone to pop in with an actual answer!)
I've played a little with Code Contract's static analysis and it is pretty cool.
Now trying to set up TeamCity build ...
Here is msbuild integration info from Microsoft Research (see page 44)