Is it possible to pass MSBuild some command line properties:
msbuild.exe /p:Configuration=Release;labDeploy=false;prodDeploy=true
Then somehow iterate through the key/value pairs passed in via the properties arg.
If so, how?
You don't say what you want to use them for, but if you're trying to use them for execution control, look at MSBuild Conditions. For example, my company's "product" at this point, fully implemented, consists of a traditional client-server app, a web-based reporting app, and a newer Silverlight implementation of some of the client-server application.
In my master MSBuild project file, I have separate targets for each application, Whether or not they run is controlled by a Condition check of a few command-line parameters.
<!-- run the builds for the selected build types -->
<Target Name="RunBuild" DependsOnTargets="ValidateBuildSelected">
<CallTarget Targets="BuildWindowsClientApp" Condition="'$(BuildWindowsClientApp)'=='TRUE'" />
<CallTarget Targets="BuildWebReportingApp" Condition="'$(BuildWebReportingApp)'=='TRUE'" />
<CallTarget Targets="BuildWebClientApp" Condition="'$(BuildWebClientApp)'=='TRUE'" />
</Target>
I can run one or all of the options based on how I set the parameter string up.
Related
I want to inhibit the building of certain projects within a solution from building (within a TeamCity Build Configuration in order to optimize the speed of my Commit Build feedback if you must know).
I'm aware of the Solution Configurations mechanism but don't want to have to force lots of .sln files to end up with every permutation of things I want to be able to switch off. I have Convention based rule where I want to say "If I'm doing the Commit Build, I dont want to do the final installer packaging". (And I don't want to break it out into a separate solution).
I'd prefer not to use a solution involving find and replace in the .sln file or in a .proj file created via [MsBuildEmitSolution][1]. I'm aware of questions here which cover the out of the box solution and this slightly related question.
I see MSBuild /v:diag is saying:
2>Target "Build" in file "Z.sln.metaproj" from project "Z.sln" (entry point):
Using "MSBuild" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "MSBuild"
Global Properties:
BuildingSolutionFile=true
CurrentSolutionConfigurationContents=<SolutionConfiguration>
<ProjectConfiguration Project="{C83D035D-169B-4023-9BEE-1790C9FE22AB}" AbsolutePath="X.csproj" BuildProjectInSolution="True">Debug|AnyCPU</ProjectConfiguration>
<ProjectConfiguration Project="{15E7887D-F1DB-4D85-8454-E4EF5CBDE6D5}" AbsolutePath="Y.csproj" BuildProjectInSolution="True">Debug|AnyCPU</ProjectConfiguration>
</SolutionConfiguration>
So the question is:
Is there a neat way of me getting to do an XPath replace or similar to have the effect of changing BuildProjectInSolution="True" to BuildProjectInSolution="False" for Project Y above
Failing that, is there a relatively simple edit I can do within a .ccproj (An Azure 1.4 Package) or a .csproj (a general project) file to cause the effects (including triggering of dependent projects) of the project being enabled within a commandline msbuild Z.sln solution build to be nullified?
Not sure it qualifies as neat, but you can set CustomAfterMicrosoftCommonTargets to import an msbuild file to over-ride the BuildDependsOn property, pointing it to your own custom build task. Basically, by setting CustomAfterMicrosoftCommonTargets you get msbuild to import an msbuild file containing the following:
<PropertyGroup>
<OldBuildDependsOn>$(BuildDependsOn)</OldBuildDependsOn>
<BuildDependsOn>MyBuild</BuildDependsOn>
</PropertyGroup>
<Target Name="OldBuild" DependsOnTargets="$(OldBuildDependsOn)" />
<Target Name="MyBuild">
<CallTarget Targets="OldBuild" Condition="<IfIWantThis>" />
</Target>
Edit
You can use the following MyBuild target to Include/Exclude projects based on regular expressions passed in as IncludeInBuild and ExcludeFromBuild properties. (If you want complex regexes, you may fall foul of MSBuild special character escaping, but this works well enough for simple matching)
> msbuild /p:ExcludeFromBuild="Tests|Install|Azure"
<Target Name="MyBuild">
<CallTarget Targets="OldBuild" Condition="('$(IncludeInBuild)'=='' OR
'$([System.Text.RegularExpressions.Regex]::IsMatch($(MSBuildProjectFullPath),
$(IncludeInBuild),
System.Text.RegularExpressions.RegexOptions.IgnoreCase))'=='True') AND
('$(ExcludeFromBuild)'=='' OR
'$([System.Text.RegularExpressions.Regex]::IsMatch($(MSBuildProjectFullPath),
$(ExcludeFromBuild),
System.Text.RegularExpressions.RegexOptions.IgnoreCase))'=='False')" />
</Target>
You could always pass the particular projects you want to build as parameters to the MSBuild.
The MSBuild command line would look like this:
MSBuild /t:<Project Name>:Rebuild;<Another Project Name>:Rebuild
In TeamCity, you would put <Project Name>:<Target Action> in the target field in the MSBuild runner.
I add a system parameter under Parameters
Name: system.ExcludeFromBuild
Kind: System property (system.)
Value: path to your csproj
While chasing incremental build time improvements, I found that .btproj files and thus all other projects that depend on these are rebuilt (partly) on each incremental build. Tracking this all the way to BizTalkCommon.targets, I found that it does a 2 pass compilation of the assembly - but only the first pass respects already built artifacts, thus breaking the incremental part of the dependency chain. The offending target can be seen in BizTalkCommon.targets (line 228):
<!-- Delete the assembly and rerun the build process -->
<Target Name="SecondPass"
Condition="$(SecondBuild)!=true and $(TempAssemblyOnly)!=true">
<Delete Files="#(IntermediateAssembly)" />
<MSBuild Projects="$(MSBuildProjectFile)" Properties="SecondBuild=true"/>
</Target>
I realize that there's a reason for the 2 pass build, but simply cannot believe it wouldn't be possible to specify appropriate in- and outputs for the target to handle incremental builds correctly.
Does anyone know if there's a patch for the .targets file, or if there's another good reason that incremental builds aren't supported?
You can enable incremental compilation of MSBuild BizTalk project with a couple of very simple changes. Basically, you need to override two targets that are defined in the BizTalkCommon.targets file.
Those targets can be overriden in your own .btproj files and do not require modifying the original .targets file that ships with BizTalk.
How To
First Create you own .targets file to host your customizations, for instance BizTalkCustom.targets :
<Import Project="$(MSBuildExtensionsPath)\Microsoft\BizTalk\BizTalkC.targets" />
<!-- Rerun the build process (second pass) -->
<Target Name="SecondPass" Condition="$(SecondBuild)!=true and $(TempAssemblyOnly)!=true and #(XLang)!=''">
<MSBuild Projects="$(MSBuildProjectFile)" Properties="SecondBuild=true" />
</Target>
<!-- Compile XLang/s orchestration -->
<Target
Name="CompileODX"
Condition="$(SecondBuild)==true"
Inputs="#(XLang);$(MSBuildAllProjects);$(ClrTypesAssembly)"
Outputs="$(BuildDone)">
<!-- Delete previously generated C# files from XLang compilation -->
<Delete Files="#(IntermediateAssembly)" />
<Delete Files="#(CSharpOutputFromXLang)" />
<XLangTask XLangItems="#(XLang)"
ProjectReferences="#(ReferencePath)"
WarningLevel="$(WarningLevel)"
BpelCompliance="$(BpelCompliance)"
DefineConstants="$(DefineConstants)"
TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
TempAssembly="$(ClrTypesAssembly)"
OutputDirectory="$(XLangOutputPath)">
</XLangTask>
</Target>
Then, replace the last Import statement in your .btproj file:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Project="$(MyCustomExtensions)\BizTalkCustom.targets" />
How doe it work
BizTalk Server projects need somehow to be compiled in two passes. The first pass compiles schemas, maps and pipelines, whereas the second pass compiles orchestrations.
You'll notice that the overriden targets are very very similar than the original ones, defined inside the BizTalkCommon.targets file. In fact, I made two simple changes:
The first change involves modifying the SecondPass Target and adding an extra test in the Conditionattribute. This test is usefull to prevent the second pass from occurring if your project does not even have Orchestrations.
Unfortunately, if your project contains Orchestrations, the original SecondPass Target deletes the intermediate assemblies and then proceed to compile the Orchestrations. However, the CompileODX Target does not need to run if all files are already up to date. Therefore, the second change involves moving the Delete Task from the SecondPass Target to the CompiledODX Target.
That's all there is to it.
This is something my team ran into a while back and simply backed off customizing the build files and went with the BizTalk deployment framework instead, located here. BizTalk does lots of "funny" things from a VS level, since 2009 was the first version BizTalk didn't use an external build process. But I'm not sure why the second pass is needed, except maybe from a designer perspective.
World's simplest task (see below) is not being executed after I publish my web application project. Any idea why?
<Target Name="AfterPublish">
<Copy SourceFiles="C:\A.txt" DestinationFiles="C:\B.txt" />
</Target>
Note: The following applies to VS2010 and publishing web-application projects with the "Web Deploy" publish method selected in the 'Build/Publish {projectname}' dialog.
Julien Hoarau's correct in that "Publish" is NOT the name of the msbuild target invoked in the above case; the actual target name is "MSDeployPublish".
Therefore, you have to define a "Target" element whose "AfterTarget" attribute's value is set to "MSDeployPublish" - the "Name" attribute's value does not matter (as long as it's unique among target names).
Here's how to do it:
Open the project file (e.g. *.csproj) in a text/XML editor and, just before the closing </Project> tag, add a <Target Name="CustomPostPublishAction" AfterTargets="MSDeployPublish"> element; pick a name of your choice for "CustomPostPublishAction".
Add a so-called Task child element that performs the desired action; for instance, to add a command to be passed to cmd.exe, use an <Exec Command="..." /> element.
Example:
<Target Name="CustomPostPublishActions" AfterTargets="MSDeployPublish" >
<Exec Command="echo Post-PUBLISH event: Active configuration is: $(ConfigurationName)" />
</Target>
Note:
In command strings, use XML entity(?) references in place of characters that would break XML parsing, e.g. ">" in place of "<".
For documentation of the <Target> element in general, see http://msdn.microsoft.com/en-us/library/t50z2hka.aspx
Task-elements reference here: http://msdn.microsoft.com/en-us/library/7z253716.aspx
In general, if you need to determine the name of the msbuild.exe target that is actually invoked by Visual Studio 2010, do the following:
Go to Tools/Options..., Project and Solutions/Build and Run, select 'Detailed' (or, for even more information, 'Diagnostic') from the dropdown list labeled 'MSBuild project build output verbosity.
After running the build/publish action, e.g. Build/Publish, examine the Output window for the last occurrence of the string "Done building target" to determine the top-level target that was invoked.
Visual Studio 2013. Publish Web application to file system.
<Target Name="Moose" AfterTargets="GatherAllFilesToPublish" >
<Message Importance="high" Text="***Moooooooooooooooose***$(WPPAllFilesInSingleFolder)***$(TargetDir)" />
</Target>
Note: Make sure that build logging is set to at least to Detailed. Look for it under Tools -> Options -> Projects and Solutinos -> Build and Run -> MSBuild output verbosity. Diagnostic is also fine if you want to investigate which build target was last run before actual publish.
This seems to work in Visual Studio 2019
<Target Name="MyCustomTarget" AfterTargets="Publish">
<Copy SourceFiles="C:\A.txt" DestinationFiles="C:\B.txt" />
</Target>
You must define override the target at the end of your file, after <Import ... />
Launch MSBuild with detailed verbosity to see why your target is ignored :
msbuild project.csproj /t:Target_to_Launch /v:d
AfterPublish is called after Publish target, but Publish is not the target called when you publish a web application. Publish is the target for publishing ClickOnce application.
You'll have to find the target used when you call Publish in Visual Studio, it could be Package, WebPublish...
I'm a little lazy right now to figure out the mess of targets to find the right one for a file-based publish (which you might be interested in). What you can do in the meantime is defining an AfterBuild target in the *.pubxml file.
<Target Name="AfterBuild">
...
I recommend also turning off the property "DeleteExistingFiles" because if you copy files into the directories being published, it does a clean somewhere during the publishing process.
<DeleteExistingFiles>False</DeleteExistingFiles>
I need a set of tasks that need to be executed exactly once for the entire solution. This will run tasks that will modify each project to run a separate set of tasks for each project. We had done this earlier using a separate project to the solution which had the solution level tasks, but we want to move away from that. Has anyone done this or does anyone have any suggestions on how to implement this?
Since Solution files are not in MSBuild format they are not easily extended or customized. If you want more control over the build process you would have to create a "driver" msbuild file which would replace your solution file. Inside this driver file you would build all the projects that you needed and perform some additional tasks. You would do this using the MSBuild task. Here is a sample showing how to build more than 1 project.
<Project ...>
<ItemGroup>
<Projects Include="proj01.csproj"/>
<Projects Include="proj02.csproj"/>
<Projects Include="proj03.csproj"/>
</ItemGroup>
<Target Name="BuildAll">
<MSBuild Projects="#(Projects)" BuildInParallel="true" />
</Target>
</Project>
So in your case you would just execute the tasks before you build the projects. Also note that I specified the value true for the BuildInParallel indicating that MSBuild can try and build more than one project at once.
An alternative solution is to have a single target that dispatches to an MSBuild invoked target with as many Global properties removed as possible. My team have a target in the InitialTargets of a Directory.Build.props Import'ed props file - something like:
<Target Name="Prebuild">
<MSBuild Projects="$(MSBuildThisFileFullPath)"
Targets="PrebuildWorker"
RemoveProperties="Configuration;Platform;TargetFramework;BuildProjectReferences" />
</Target>
Since MSBuild appears to synchronize parallel builds on the {project file, global properties, target} set, then by removing all of the properties you can synchronize the build and run it once for all projects being built. The downside: you have to maintain the RemoveProperties attribute - MSBuild doesn't have a way to remove all global properties. If something in the build issues a new MSBuild task with a custom property specified, then you'll get a second instance of the Target invoked.
And - of course - your build will be synchronized on this target. You could try hooking the target up by setting, say, CompileDependsOn to depend on the Prebuild target, to allow independent progress in the build. But to have the target run early and ubiquitously using InitialTargets seems like the better option.
I have a process where I need to automate the process of generating the satellite assemblies. Specifically this is for WPF and combining Resx and BAML resources.
I've got a build script that works, but it requires manual adding of the .resources files I want to combine with the BAML resources. IOW, I have to add to the build script each time I add a .Resx resource. Not cool!
Currently I'm running the assembly linker manually and the script looks like this:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Adds the build action 'LocBamlCsv' -->
<ItemGroup>
<AvailableItemName Include="LocBamlCsv" />
</ItemGroup>
<Target Name="CreateSatelliteAssemblies"
DependsOnTargets="$(CreateSatelliteAssembliesDependsOn)">
<!-- Locbaml needs the runtime assemblies in the intermediate dir -->
<Copy SourceFiles="$(ProjectDir)..\Tools\LocBaml.exe"
DestinationFolder="$(OutputPath)" />
<!-- generate a .resources file for .csv merged output -->
<Exec Command="LocBaml /generate ..\..\$(IntermediateOutputPath)$(TargetName).g.$(UICulture).resources /trans:%(LocBamlCsv.FullPath) /out:../../$(IntermediateOutputPath) /cul:%(LocBamlCsv.Culture)"
WorkingDirectory="$(OutputPath)"
Outputs="$(OutputPath)%(LocBamlCsv.Culture)\$(TargetName).$(UICulture).dll" />
<!-- Generate the resource assembly by merging all .resources files -->
<!-- NOTE: Explicitly add any resource files here -->
<Exec Command="al /template:$(TargetName).exe /culture:%(LocBamlCsv.Culture) /out:%(LocBamlCsv.Culture)\$(TargetName).resources.dll /embed:$(TargetName).g.%(LocBamlCsv.Culture).resources /embed:$(TargetName).Properties.Resources.%(LocBamlCsv.Culture).resources"
WorkingDirectory="$(InterMediateOutputPath)"
/>
</Target>
</Project>
As mentioned it works. but the last command that calls al would be much easier to work with if there was some way to use wild cards (ie. $(TargetName).*s.%(LocBamlCsv.Culture).resources.
I've tried a number of things. Using the build process apparently fires at the wrong time and it ends up failing to find files.
I'm not sure exactly what your problem is
but you did say something that makes me wonder. "Using the build process apparently fires at the wrong time and it ends up failing to find files." From this I get the impression that you are trying to create an item which contains files that are generated during the build process. If this is the case then you should declare those as dynamic items, which are items declared inside of a target. Items declared outside of targets (static items) are evaluated before any target begins to execute. See my blog post MSBuild: Property and Item Evaluation.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build