I am trying to learn how to use MSBuild so we can use it to build our project. There's what seems to be a very big hole in the documentation, and I find the hole everywhere I look, the hole being how do you name or otherwise designate the MSBuild project file?
For example, the tutorial on MSBuild that can be downloaded from Microsoft goes into some detail on the contents of the build file. For example, here's a little bit of their Hello World project file.
<Project MSBuildVersion = "1.0" DefaultTargets = "Compile">
<Property appname = "HelloWorldCS"/>
<Item Type = "CSFile" Include = "consolehwcs1.cs"/>
<Target Name = "Compile">
<Task Name = "CSC" Sources = "#(CSFile)">
<OutputItem TaskParameter = "OutputAssembly" Type = "EXEFile" Include = "$(appname).exe"/>
</Task>
<Message Text="The output file is #(EXEFile)"/>
</Target>
</Project>
And it goes on blah, blah, blah Items blah blah blah tasks, here's how you do this and here's how you do that. Useless, completely useless. Because they never get around to saying how this xml file is supposed to be recognized by the MSBuild app. Is it supposed to be named in a particular way? Is it supposed to be placed in a particular directory? Both? Neither?
It isn't just the MS tutorial where they don't tell about it. I haven't been able to find it on MSDN, or on any link I can wring out of Groups.Google, either.
Does someone here know? I sure hope so.
Edited to add: I mistook the
.proj file included in the tutorial
to be the .csproj file and that is what
one fed to MSBuild, but it took the answer below before I saw this.
It should have been rather obvious, but I missed it.
You can name the file as you see fit. From the help for MSBuild
msbuild.exe /?
Microsoft (R) Build Engine Version 2.0.50727.3053
[Microsoft .NET Framework, Version 2.0.50727.3053]
Copyright (C) Microsoft Corporation 2005. All rights reserved.
Syntax: MSBuild.exe [options] [project file]
So if you save the file as mybuildfile.xml you would use the syntax:
msbuild.exe mybuildfile.xml
You don't have to specify the build file if you respect following strategy:
Today, when you invoke msbuild.exe
from the command line and don't
specify any project files as
arguments, then we do some auto
inferral and scanning and decide if we
should build anything. If we find
either a msbuild project (anything
that has an extension of *proj) or a
solution file (.sln), we will build
either the project or the solution as
long as there is only one solution or
one project in the directory. If there
is a solution and a project, we will
give preference to the solution. If
there's more than one project or more
than one solution, we issue an error
message because we can't decide which
one to build.
This is taken from New Feature Feedback Request: /IgnoreProjectExtensions - A new command-line switch.
I always name my manually written scripts build.proj.
Not a direct answer, but related; if you use .msproj as your extension, Visual Studio gives you intellisense.
Or for the truly lazy, like me.
msbuild.exe project-file-name.vcproj /t:Rebuild /p:Configuration=Release
Visual Studio 2012 recognizes the .msbuildproj as an extension and will treat it as a "project" in the Solution Explorer.
Related
My C# projectA published via ClickOnce depends on projectB. I need the projectB.dll.config file for projectA to work. While MSBuild copies over projectB.dll.config to projectA/bin/ConfigXY correctly, it is not published. VisualStudio (2017) doesn't even show the file in Application->Publish->Application Files.
As a workaround, I added this to A.csproj:
<Content Include="..\projectB\bin\Release\projectB.dll.config">
<Link>projectB.dll.config</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>
Now VS shows the file in the "Application Files" list, but this of course works only for the Release build config. Since I have lots of configs in project A that map to different configs in B, I cannot simple use $(Configuration) in the path.
I have found some suggestions to include ..\**\*.dll.config, but that seems dangerous, as when both the Debug and Release folder exist (from a previous build), I might end up with the wrong one.
What's the right way to do this?
I’d like to post this as a comment, but due to the limitations, I post it as an answer and I am sorry for that.
I did some tests, and it seems, to include the project.dll.config file to be published(shown in Application > Publish > Application Files), we need to include this file to the projectA.
I guess you mean you want to use “..\XXX\XXX\Release\projectB.dll.config” path for Release build and use ““..\XXX\XXX\Debug\projectB.dll.config” path for Debug build without using $(Configuration) right?
Generally, MSBuild uses $(configuration) to switch the configuration mode, if it is not available for you, to my knowledge, from MSBuild side, it is hard or not possible to switch/match the configuration mode.
I'm trying to use MSBuild to create a target that will create an installer with InstallShield 2012. I'm having difficultly understanding how to access InstallShield. I ran across this mentioning an InstallShield task but I'm not sure how to get access to it. I think I need a UsingTask directive, but not sure what to import. Can someone give me a pointer on how to get this going? Thanks.
You need to import the targets file. Took me a while to figure that out as well since it's in the msbuild extensions directory together with a dll. Here's a basic sample of how to use it (note this is for 2012Spring but you get the idea):
<Import Project="$(MSBuildExtensionsPath32)\InstallShield\2012Spring\InstallShield.targets" />
<Target Name="BuildInstaller">
<InstallShield.Tasks.InstallShield
Project="/path/to/my.ism"
ProductConfiguration="Package"
ReleaseConfiguration="MSI" />
</Target>
Btw if this doesn't work out for some reason, you can always invoke ISCmdBld.exe in an Exec task, it will do the job just as fine.
InstallShield provides Visual Studio integration. When you create an InstallShield project in VS it creates a project file (.ISPROJ) which imports the InstallShield.targets file for that version of InstallShield. The project file contains plenty of examples on how to build a particular configuration and pass in such things as merge module path, properties, path variable overrides and so on.
Please note that building InstallShield requires the x86 MSBuild platform due to COM components.
I'm using MsBuild to build and publish my project (along with CruiseControl.Net). I have set everything up and it works great but the problem is it's overwriting all my existing files in the deployed folder(and the folder contains user data, i could do an xcopy after the build/publish but the user data is a few gigs and that would be too much disk activity on each automated build).
So what I would like to do is use a "Replace only Existing files" option instead of removing everything from the folder. I get this option in Visual Studio 2010 when publishing, you can either "Replace Exiting Files" or "Delete All Files First", how to do this using the msbuild command parameters.
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
<workingDirectory>C:\CCnet\dmisr-web_workingdir\MAKANI</workingDirectory>
<projectFile>MAKANI.sln</projectFile >
<buildArgs>/noconsolelogger /v:quiet /p:Configuration=Staging /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\dMisr\Web - Deployed" /p:AutoParameterizationWebConfigConnectionStrings=false</buildArgs>
<targets>ReBuild</targets >
<timeout>600</timeout >
</msbuild>
This answer may help
How do I keep MSDeploy from deleting extra folders in my project?
Looks like you may just need to supply an extra property to msbuild.
SkipExtraFilesOnServer=True
/p:SkipExtraFilesOnServer=true is still removing other files for me when using these build arguments
/p:DeployOnBuild=true;DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder;_PackageTempDir=\\Network\Share\code /p:AutoParameterizationWebConfigConnectionStrings=false /p:SkipExtraFilesOnServer=true
I do not seem to have the ability to comment. Hence providing my comments in the answer section.
I'm currently using the Hudson build system with MSBuild steps. As part of the build, I have a project file with various targets in, one of which is to start a build with visual studio. However, I need to pass through a seperate project file to this target in order for it to build, but I keep getting the exception 'MSBUILD : error MSB1008: Only one project can be specified.'
I believe this is because the system is unable to calculate which project is supposed to be the parameter, and which the top-level target? If so, is there anyway to resolve this.
Here is a snippet of the target project file:
<Target Name="VisualStudioTask">
<!-- Required Properties:
$(BuildType)
$(ConfigurationSetup)
$(Solution)-->
<Exec Command="C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.exe $(BuildType) $(ConfigurationSetup) $(Solution)" />
</Target>
The MSBuild step calling this looks like this:
/t:VisualStudioTask -p:BuildType="/Build" p:ConfigurationSetup="Release" -p:Solution="%22..\MyProject.vcproj%22"
Many thanks
Chris
I have figured it out, the problem was that I'd left out a '-' when declaring the 'ConfigurationSetup' parameter, so if you look in my original example it has this:
/t:VisualStudioTask -p:BuildType="/Build" p:ConfigurationSetup="Release" -p:Solution="%22..\MyProject.vcproj%22"
When it should have this..
/t:VisualStudioTask -p:BuildType="/Build" -p:ConfigurationSetup="Release" -p:Solution="%22..\MyProject.vcproj%22"
Here's my situation: I'm trying to understand how msbuild works by looking at the build files located in the .NET framework install path:
C:\Windows\Microsoft.NET\Framework\v3.5>dir /s/b microsoft*
Microsoft.Build.Tasks.v3.5.xml
Microsoft.Build.xsd
Microsoft.Common.targets
Microsoft.Common.Tasks
Microsoft.CSharp.targets
Microsoft.Data.Entity.targets
Microsoft.VisualBasic.targets
Microsoft.WinFx.targets
MSBuild\Microsoft.Build.Commontypes.xsd
MSBuild\Microsoft.Build.Core.xsd
I'm assuming that msbuild starts with Microsoft.Common.Targets, and then at some point in the future msbuild 'looks' at my vb project file extension (.vbproj) and loads 'Microsoft.VisualBasic.targets'.
two questions:
1) Is my interpetation correct?
2) can you explain to me, where is the code that determines that this is a .vbproj file, and loads 'Microsoft.VisualBasic.targets' accordingly? Is the code locked away in an assembly somewhere, or is it visible in the build files listed above?
It "starts" with your .vbproj file. Take a look at that file, it will <Import> the Microsoft.VisualBasic.targets, which in turn will <Import> Microsoft.Common.targets.
In 4.0, which is currently available in Beta, there is a /preprocess switch which will make this all clear.