We have a solution with around 70 projects. One of them takes relatively long (~10min) but does not use system resources. We also employ parallel build to speed things up.
When I (re)add this project to the solution, it is at the end of the build order. The machine is 100% busy when compilong 69 projects and then 10min idle when compiling the 70th. When I manually edit the .sln-file so that the project comes first in all lists, it is somewhere in the middle. How can I move it to the beginning?
This is not about dependencies. This project A has only one to another project B and I am fine if B is first as long as A is second. Also, no other projects depends on project A.
It sounds like you have already tried editing project dependencies in visual studio. If you have already edited it to make the project first, but it still takes a while then you probably should just take it out of the solution file. Then put the building of it into your own msbuild script where you can use the MSBuildExtensions parallel tasks to make it build at the same time as everything else:
See https://mikefourie.wordpress.com/2012/02/29/executing-msbuild-targets-in-parallel-part-1/
And I'm pretty sure the MSBuildExtensions library is a nuget package now as well.
VisualStudios sln-files are very limited and are written in a format defined decades ago. In fact, it is converted to a msbuild-script before doing anything useful.
To have more flexibility, I added an msbuild-script (master.msbuild) with something similar to this (untested but proper documentation is available)
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<ProjectsToBuild Include="longrunningproject.proj" />
<ProjectToBuild
Include="SolutionWithTheOther69Projects.sln"
Properties="Configuration=Debug;Platform=x86"/>
</ItemGroup>
<Target Name="Build" >
<MSBuild
Projects="#(ProjectsToBuild)"
Targets="Build"
BuildInParallel="true"
ContinueOnError="false"
Properties="VeloxVersion=$(VeloxVersion);RootDir=$(RootDir)"
/>
</Target>
</Project>
Projects are executed in order they are defined. Still no control what happens in the solution but I can put projects in front or behind it and can so influence the build order.
If the long-running task is called by an msbuild-exec-task, it is important to set the YieldDuringToolExecution-flag of this task. E.g.
<Exec
Command="..."
YieldDuringToolExecution="true"
/>
Otherwise, things are starting in parallel and then slowly dying off until the exec-task is done. I could not decode the logic behind that but honestly, I do not care.
After several days of try and error, the build machine screams at 100%-cpu-load, slowly come down to the one long-running task and then is done. Speedup-factor 2.5 :D
How can I move it to the beginning?
You can create a MSBuild project file named "before.<SolutionName>.sln.targets" in the same folder as your solution.
Then build the solution with command line (Visual Studio will ignore this file.), the before.<SolutionName>.sln.targets will be built before all of the Visual Studio projects in the solution.
In this case, we just need to build that special project in the before.<SolutionName>.sln.targets file, that special project will be built before all of projects in the solution.
The content of before.<SolutionName>.sln.targets like:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="BuildSpecialProject" BeforeTargets="Build">
<Message Text="Build My Specify Project" />
<MSBuild Projects="Path\YouSpecialName.csproj"/>
</Target>
</Project>
Then build the solution file with command line with MSBuild or dotnet:
msbuild /t:build "<SolutionPath>\<SolutionName>.sln"
dotnet build "<SolutionPath>\<SolutionName>.sln"
Check this thread for some more details.
Hope this helps.
I would like to build the same project twice in the same solution configuration, varying some #define flags to toggle features. Both binaries will be deployed with different names.
The solutions that I know could work:
Add a solution configuration - But I will then need to build the solution twice, which I would prefer to avoid. Both project configurations will always be built.
Copy the project - But then I have the overhead of maintaining a new project when I only want to maintain a different configuration.
Batch build - I avoid using batch build as I use both devenv for local development and msbuild for continuous integration.
Any other ideas or suggestions?
Just figured out a way to do what you asked for. Create one msbuild file (I named mine multiple.proj) and add the script below.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Choose>
<When Condition="'$(Configuration)|$(Platform)' == 'Debug|AnyCPU'">
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectName).csproj">
<Properties>Configuration=Release</Properties>
</ProjectToBuild>
</ItemGroup>
</When>
</Choose>
<Target Name="BeforeBuild">
<Message Text="Building configuration $(Configuration)..." />
</Target>
<Target Name="AfterBuild">
<MSBuild Projects="#(ProjectToBuild)"/>
</Target>
</Project>
</type>
</this>
Import the script on your projects (csproj or vbproj):
<Import Project="..\multiple.proj" />
This script tells msbuild to build again your project with another configuration as an AfterBuild event. I used Debug/Release to make the example, but you can easily change the script to support other configurations, or make the decision to build again based on other variables.
Be careful because you're running two builds at once, so build errors can be harder to understand.
Hope this helps.
i'm stuck with extending my msbuild project file and tfs 2010. What i want to achieve is to automatically generate the documentation for my source code after the build. I searched the web and found out, that the file Microsoft.TeamFoundation.Build.targets defines a lot of customizable targets for either desktop- or team-build. One of them is the GenerateDocumentation-Target which i want to use. The Problem i have is, that despite i imported this file, the overloaded targets are not invoked by msbuild. The header of my vcxproj-File looks as follows:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
after this i include the team build targets file with the statement
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets"/>
At the very end of this project file i tried to overload some targets as suggested in the TeamFoundation target file:
<Target Name="GenerateDocumentation">
<Message Text="GenerateDocumentation invoked" Importance="high"/>
</Target>
<Target Name="BeforeBuild">
<Message Text="BeforeBuild invoked" Importance="high" />
</Target>
<Target Name="AfterBuild">
<Message Text="AfterBuild invoked" Importance="high" />
</Target>
but except the AfterBuild-Target neither the GenerateDocumentation nor BeforeBuild target is called for a local build nor a build with the build server. Am i'm missing something? Is the DefaultTarget="Build" correct? I tried to change this to DefaultTarget="DesktopBuild" but then calling msbuild resulted in a variety of errors (MSB4018). In the project file the target file $(VCTargetsPath)\Microsoft.Cpp.targets is imported too. When removing this import, the GenerateDocumentation target is called, but not the other ones (including ResourceCompile which i need too). Can i use both of them somehow?
Thanks in advance...
what about adding this at the end of your build task...
<CallTarget Targets="GenerateDocumentation"></CallTarget>
</Target>
I'm fairly new to ant, and I've seen uncle Bob's "extract until you drop" episode.
As a result I try to define ant-targets as small as possibly possible, so you can see exactly the essence of the target, and no more. For more details, you have to refer to sub-targets.
Whether that's good or bad style is a different debate (or a flame-war maybe).
Therefore, I was creating a build script that, in pseudo-code, would look like this:
build =
compile
instrument if coverage
The coverage task is split into subtargets, too:
coverage:
create-coverage-dirs
call-cobertura
EDIT- I want to express that coverage sub-targets should not be run.
But... I'm having a hard time expressing this 'cleanly' in ant-ese.
Assuming that I can use the depends attribute to indicate ... inter-target dependencies, I got to something like this:
<target name="build" depends="compile, coverage"/>
<target name="compile"> .... </target>
<target name="coverage" depends="
create-coverage-dirs,
taskdef-cobertura"
if="build.with.coverage">
<cobertura-instrument ...> ... </cobertura-instrument>
</target>
<target name="create-coverage-dirs">
...
</target>
<target name="taskdef-cobertura">
...
</target>
Whow this looked nice!
Only it seemed that, when executing, the coverage task was duefully omitted, but it's sub-tasks were still executed when build.with.coverage was false!
>ant -v compile
Build sequence for target(s) `build' is
[compile, create-coverage-dirs, taskdef- cobertura, coverage, build]
Complete build sequence is
[compile, create-coverage-dirs, taskdef-cobertura, coverage, build, ]
I can put an if attribute in every coverage sub-task, but that doesn't seem clean to me.
So here's the question:
Is my ant-ese a horrible dialect? Am I 'making ant into make'?
Should if be used this way, or is there an if-and-recurse kind-of attribute?
Repeat after me: Ant is not a programming language. In fact, write it down 100 times on the blackboard.
Ant is not a programming language, so don't think of it as such. It is a build dependency matrix.
It's difficult for programmers to wrap their heads around that idea. They want to tell Ant each step and when it should be done. They want loops, if statements. They'll resort to having a build.sh script to call various targets in Ant because you can't easily program Ant.
In Ant, you specify discrete tasks, and which tasks depend upon other tasks, and let Ant handle where and when things get executed.
What I am saying is that you don't normally split tasks into sub-tasks and then try calling <ant> or <subant> on them.
Have discrete tasks, but then let each task know what other tasks they depend upon. Also remember that there is no true order in Ant. When you list the depends= tasks, there is no guarantee which order they'll be executed in.
Standard Ant Style (which means the way I do it (aka The Right Way), and not the way my colleague does it (aka The Wrong Way)), normally states to define tasks at the top of the properties file and not in any target. Here's a basic outline on how I structure my build.xml:
<project name=...>
<!-- Build Properties File -->
<property name="build.properties.file"
value="${basedir}/build.properties"/>
<property file="${build.properties.file"/>
<!-- Base Java Properties -->
<property name="..." value="..."/>
<taskdef/>
<taskdef/>
<!-- Javac properties -->
<property name="javac..." value="..."/>
<task/>
<task/>
</project>
This creates an interesting hierarchy. If you have a file called build.properties, it will override the properties as defined in the build.xml script. For example, you have:
<property name="copy.verbose" value="false"/>
<copy todir="${target}"
verbose="${copy.verbose}">
<fileset dir="${source}"/>
</copy>
You can turn on the verbose copy by merely setting copy.verbose = true in your build.properties file. And, you can specify a different build properties file by merely specifying this on the command line:
$ ant -Dbuild.properties.file="my.build.properties"
(Yes, yes, I know there's a -propertycommand line parameter for ant)
I normally set the various values in the build.xml to the assumed defaults, but anyone can change them by creating a build.properties file. And, since all the base properties are at the beginning, they're easy to find.
Tasks are defined in this non-target space too. That way, I can easily find the definition since they're in the same place in each build.xml, and I know I can use a task without worrying whether the task defining target has been hit.
Now, to your question:
Define your tasks (and don't have a tar defining task, or you'll drive yourself crazy). Then, define the dependencies on each of those tasks. Developers can select the targets they want to hit. For example:
<project>
<description>
yadda, yadda, yadda
</description>
<taskdef name="cobertura"/>
<target name="compile"
description="Compile the code"/>
<!-- Do you have to compile code before you run Cobertura?-->
<target name="coverage"
description="Calculate test coverage"
depends="compile">
<mkdir dir="${coverage.dir}"/>
<cobertura-instrument/>
</target>
<project>
If you want to compile your code, but not run any tests, you execute ant with the compile target. If you want to run tests, you execute ant with a coverage target. There's no need for the depends= parameter.
Also notice the description= parameter and the <description> task. That's because if you do this:
$ ant -p
Ant will show what's in the <description> task, all targets with a description parameter, and that description. This way, developers know what targets to use for what tasks.
By the way, I also recommend doing things the right way (aka doing it the way I do it) and name your targets after the Maven lifecycle goals. Why? Because it was a good way to standardize on the names of targets. Developers know that clean will remove all built artifacts, and compile will run the <javac> task, and that test will run the junit tests. Thus, you should use the goals in the Cobertura plugin: cobertura.
Edit
my problem is: I regard 'coverage' as related to 'optimized' and 'debug', i.e. a build flavor. That's where my difficulty lies: for Java, coverage results in an an extra intermediate target in the compile step.
I'm looking at the Corburta page, and there's no real change in the <javac> task (which is part of the compile target.
Instead, you run Corburtura on the already built .class files, and then run your <junit> task. The big change is in your <junit> task which must now include references to your Corburtura jars, and to your instrumented classes.
I imagine you could have a corburturatarget or what ever you want to call it. This target runs the instrumented JUnit tests. This is the target you want developers to hit, and should contain a description that it runs instrumented tests.
Of course, you can't run the instrumented Junit tests without first instrumenting them. Thus, your corburtura target will depend upon another instrument.tests target. This target is internal. People who run your build.xml don't normally say "instrument tests" without running those tests. Thus, this target has no description.
Of course, the instrument.tests target depends upon having .class files to instrument, so it will have a dependency upon the compile target that runs the <javac> task:
<target name="instrument.classes"
depends="compile">
<coburtura-instrument/>
</target>
<target name="corburtura"
depends="instrument.classes"
description="Runs the JUnit tests instrumented with Corburtura">
<junit/>
</target>
The only problem is that you're specifying your <junit> target twice: Once when instrumented, and once for normal testing. This might be a minor issue. If you update how your JUnit tests run, you have to do it in two places.
If you want to solve this issue, you can use <macrodef> to define a JUnit test running Macro. I used what was on the Corbertura page to help with the outline. Completely non-tested and probably full of syntax errors:
<target name="instrument.tests"
depends="compile">
<corburtura-instrument/>
</target>
<target name="corburtura"
depends="instrument.tests"
description="Instrument and run the JUnit tests">
<run.junit.test fork.flag="true">
<systemproperty.addition>
<sysproperty key="net.sourceforge.corbertura.datafile"
file="${basedir}/cobertura.ser" />
</systemproperty.addition>
<pre.classpath>
<classpath location="${instrumented.dir}" />
</pre.classpath>
<post.classpath>
<classpath refid="cobertura_classpath" />
</post.classpath>
</run.junit.test>
</target>
<target name="test"
description="Runs the Junit tests without any instrumentation">
<run.junit.test/>
</target>
<macrodef name="run.junit.test">
<attribute name="fork.flag" default="false"/>
<element name="sysproperty.addition" optional="yes"/>
<element name="pre.classpath" optional="yes"/>
<element name="post.classpath" optional="yes"/>
<sequential>
<junit fork="#{fork.flag}" dir="${basedir}" failureProperty="test.failed">
<systemproperty.addtion/>
<pre.classpath/>
<classpath location="${classes.dir}" />
<post.classpath/>
<formatter type="xml" />
<test name="${testcase}" todir="${reports.xml.dir}" if="testcase" />
<batchtest todir="${reports.xml.dir}" unless="testcase">
<fileset dir="${src.dir}">
<include name="**/*Test.java" />
</fileset>
</batchtest>
</junit>
</sequential>
</macrodef>
I would not use a property at all in this case, but rely solely on depends (which seems more natural to me for this task):
<target name="build" depends="compile, coverage"/>
<target name="compile"> ...
<target name="coverage"
depends="compile, instrument,
create-coverage-dirs, taskdef-cobertura"> ...
The if attribute tests if the property exists, not if it is true or false. If you don't want to run the coverage target then don't define the property build.with.coverage.
As of Ant 1.8.0 you can use property expansion to resplver property as a boolean:
<target name="coverage" depends="
create-coverage-dirs,
taskdef-cobertura"
if="${build.with.coverage}">
I just learned about how to include FxCop on a build. But it's slow and I want it to be done just only on release builds. Is there any way to configure that?
Check the configuration condition.
<Target Name="AfterBuild" Condition="'$(Configuration)' == 'Release' ">
<FxCop TargetAssemblies="#(OutputAssemblies)"
RuleLibraries="#(FxCopRuleAssemblies)"
DependencyDirectories="$(MSBuildCommunityTasksPath)"
FailOnError="False"
ApplyOutXsl="True"
OutputXslFileName="C:\Program Files\Microsoft FxCop 1.32\Xml\FxCopReport.xsl"
DirectOutputToConsole="true"/>
</Target>
Haven't tested this but I think it should be something along the lines of:
<Target Name="MyTarget" Condition="'$(FlavorToBuild)'=='Release'">
...do release specific stuff...
</Target>
Add a condition in the .msbuild script.
Only execute the FxCop task if Configuration is "Release" not f.ex when it is "Debug"