I have been at this for a couple of hours now and its beginning to do my head in.
Within TeamCity am trying to get an MSBuild to run the .NET Duplicates Finder, this was the easy bit.
<Target Name="Duplication" DependsOnTargets="CreateSVNStats">
<MakeDir Directories="$(BuildDir)\test\" Condition="!Exists('$(BuildDir)\test')" />
<Exec Command=""C:\buildAgent\plugins\dotnet-dupfinder\bin\dupfinder.exe" --show-stats --show-text --discard-cost=70 -i **/*.vb -o $(BuildDir)\test\result.xml" ContinueOnError="false"/>
</Target>
I have the result.xml that this what am stuck on is getting the result.xml to be displayed in teamcity.
I have tried to add a custom tab with the result.xml in it and it doesn't work.
was wondering if anyone knew where the .NET Duplicates Finder Build Runner xlst is so i can format the Result.xml file correctly and display it.
Thanks
I don't have any ideas about formatting the result.xml file but can you upgrade to TeamCity 6? With TC6 you can use multiple build steps, e.g. run your build using msbuild then run a Duplicates Finder (.Net), the results will both be displayed under the same build configuration.
Team City 8 comes with built in duplicate finder: http://confluence.jetbrains.com/display/TCD8/Duplicates+Finder+(.NET)
Might be available in earlier versions too, haven't checked.
Related
Heads up: I'm a total MSDeploy noob. In fact, this is my first attempt at creating a msbuild script and I'm only recently started looking into msdeploy.
Now that that's out of the way, I'm writing a build script to compile and package my ASP.Net webforms application. The script can compile the solution, however, I'm getting the following error when attempting to package:
Microsoft.Web.Deployment.DeploymentException: The library 'Microsoft.Data.Tools.Schema.DbSqlPackage, Version=10.3.0.0, ...' could not be loaded.
I've searched the web but I can't seem to find any instances of this issue (specific to the missing DbSqlPackage.dll). I assume this has something to do with the ability to package and deploy databases referenced in the solution.
I am using MSDeploy V3 and MSBuild v4.0.30319. The Package target of the .build file is as follows:
<Target Name="Package" DependsOnTargets="Compile">
<PropertyGroup>
<PackageDir>%(PackageFile.RootDir)%(PackageFile.Directory)</PackageDir>
<Source>%(Website.FullPath)</Source>
<Destination>%(PackageFile.FullPath)</Destination>
</PropertyGroup>
<MakeDir Directories="$(PackageDir)" />
<Exec Command='"#(MsDeploy)" -verb:sync -source:iisApp="$(Source)" -dest:package="$(Destination)"' />
I am not trying to include any databases and I would be happy if there is a switch that I can set to bypass the error all together. However, if anyone knows how to FIX and not just avoid the issue, that would be preferred.
Thanks in advance.
Vinney
I tried to repair the installation of MS Web Deploy but no dice. Except, my filter terms "web deploy" turned up another item in my installed programs: "Web Deploy dbSqlPackage Provider" (or something along those lines... it's late). The build/package completes after removing this program.
It only took me half a day to find this solution... oh well!
I have this custom build step form my project:
<Target Name="BeforeBuild">
<WriteLinesToFile Condition="" File="$(OutputPath)\env.config"
Lines="$(Configuration)" Overwrite="true">
</WriteLinesToFile>
</Target>
Basically it outputs the build configuration to a file.
This works fine when building in Visual Studio. Team Build decided to make things harder. The OutputPathfor Team Build is in a different spot (not bin\$(Configuration))
I know how to find out if the build is part of a team build (Condition=" '$(TeamBuildConstants)' == '_TEAM_BUILD_' ") but unless I want to hard code the path, I can't see a way to get the Team Build path.
Any ideas on how to find out (in the project, the the Team Build file) what the output location is?
You might need to use $(OutDir) when running in Team Build:
http://blogs.msdn.com/aaronhallberg/archive/2007/06/07/preserving-output-directory-structures-in-orcas-team-build.aspx
So you could use the _TEAM_BUILD_ condition and have two calls - one with OutputPath and one with OutDir.
I am using TeamCity 4.5.1 to build and deploy an ASP.Net application to development.
This is working perfectly so far, however, my manager has asked that I tag the folder with the specific SVN Revision from which the source was compiled.
I am using an MSBuild script to do the build and deployment, however, I am unable to successfully retrieve the build number.
Here is the MSBuild command I'm using (sanitized):
<Exec Command=">\\server08\D$\Websites\MYPROJECT\version.txt echo %env.BUILD_VCS_NUMBER%,%env.BUILD_VCS_NUMBER.1%,%system.build.vcs.number%,%system.build.vcs.number.1%,%system.build.number.format%,%system.build.number.format.1%,%system.build.vcs.number.MYPROJECT_Web_Root%,%env.TEAMCITY_VCS_NUMBER_MYPROJECT_Web_Root%" />
Version.txt turns up like this:
,,,,,,,,
Aka, empty. What am I doing wrong? Any better way to do this?
%env.XYZ% is TeamCity's method of referring to the environment variables, if you want to use them in ITS settings anywhere.
In a batch file or via msbuild, you only want the XYZ part.
echo %BUILD_VCS_NUMBER% > \\path\to\version.txt
I have a solution with several projects in it. Let's say
project A depends on projects B and C
project B depends on project C
When I run my solution on the local machine VS builds each project once and it takes 1 minute. However, on our build machine it takes about 4 minutes to build and, as I can understand from the MSBuild logs it goes like this:
build A -> build B for A, build C for A
build B -> build C for B
So it builds some projects several times... How can I speed up the build process?
P.S. It's not a question of 3 extra minutes, I just wonder why is it so different from my local machine build?
I am not sure about your build order. Sometimes TeamBuild can look like it is building projects over and over but it is building for different configurations. Take a look and make sure you have not defined multiple FlavorsToBuild.
Also, if you don't want to do a fresh check out and rebuild every time, you can define this at the bottom of your TFSBuild file.
<PropertyGroup>
<IncrementalBuild>true</IncrementalBuild>
</PropertyGroup>-->
Put that right before the </Project> tag.
This sample seems to work for me. TestLib.Extra depends on TestLib. If I change something in TestLib, both projects will build. If I change only in TestLib.Extra, only that one will build, and if I don't change anything at all, they will just report Skipping target "CoreCompile" because all output files are up-to-date and so on.
<Target Name="Build">
<MSBuild Targets="Build" Projects="TestLib\TestLib.csproj" />
<MSBuild Targets="Build" Projects="TestLib.Extra\TestLib.Extra.csproj" />
</Target>
The trick is to use the "Build" target of the projects, rather than "Rebuild". The difference between these is essentially the same as the difference between the "Build" and "Rebuild" commands in the build menu in Visual Studio.
Edit
This works well also if the projects are included in a solution file, and you specify the solution to build instead:
<Target Name="Build">
<MSBuild Targets="Build" Projects="TestLib.sln" />
</Target>
Maybe like our's, your build server is a virtual machine (10x at least slower).
Also TFS (and maybe others), does a fresh checkout on build, so it will have to build all the projects regardless.
Are you using the /maxcpucount switch? There may be a difference in number of processors between your local machine and the build machine. This setting can also be different between your msbuild file and the visual studio setting which could also explain the difference you're seeing in build times.
I do this as follows. It is somewhat complicated custom build system but the basic idea is.
The dlls which are reused in many solutions are build to a known folder. This is achieved my using a msbuild project file that builds these common dlls.
When building other csproj files in a solution we copy the csproj files then use xslt manipulation to replace the project references with dll refernces for those common dlls.
The build scripts then build these changed csproj files using custom msbuild project files we maintain corresponding to each solutions. We don't build .sln files. These custom project files is a itemgroup of .csproj files in correct dependency order.
Maybe this can help you in achieving what you want.
I have CruiseControl.NET Version 1.4 set up on my development server. Whenever a developer checks in code, it makes a compile.
Now we're at a place where we can start giving our application to the testers. We'd like to use ClickOnce to distribute the application, with the idea being that when a tester goes to test the application, they have the latest build.
I can't find a way to make that happen with CruiseControl.NET. We're using MSBUILD to perform the builds.
We've done this and can give you some pointers to start.
2 things you should be aware of:
MSBuild can generate the necessary deployment files for you.
MSBuild won't deploy the files to the FTP or UNC share. You'll need a separate step for this.
To use MSBuild to generate the ClickOnce manifests, here's the command you'll need to issue:
msbuild /target:publish /p:Configuration=Release /p:Platform=AnyCPU; "c:\yourProject.csproj"
That will tell MSBuild to build your project and generate ClickOnce deployment files inside the bin\Release\YourProject.publish directory.
All that's left is to copy those files to the FTP/UNC share/wherever, and you're all set.
You can tell CruiseControl.NET to build using those MSBuild parameters.
You'll then need a CruiseControl.NET build task to take the generated deployment files and copy them to the FTP or UNC share. We use a custom little C# console program for this, but you could just as easily use a Powershell script.
Thanks for all the help. The final solution we implemented took a bit from every answer.
We found it easier to handle working with multiple environments using simple batch files. I'm not suggesting this is the best way to do this, but for our given scenario and requirements, this worked well. Supplement "Project" with your project name and "Environment" with your environment name (dev, test, stage, production, whatever).
Here is the tasks area of our "ccnet.config" file.
<!-- override settings -->
<exec>
<executable>F:\Source\Project\Environment\CruiseControl\CopySettings.bat</executable>
</exec>
<!-- compile -->
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>F:\Source\Project\Environment\</workingDirectory>
<projectFile>Project.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Rebuild</targets>
<timeout>0</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<!-- clickonce publish -->
<exec>
<executable>F:\Source\Project\Environment\CruiseControl\Publish.bat</executable>
</exec>
The first thing you will notice is that CopySettings.bat runs. This copies specific settings for the environment, such as database connections.
Next, the standard MSBUILD task runs. Any compile errors are caught here and handled as normal.
The last thing to execute is Publish.bat. This actually performs a MSBUILD "rebuild" again from command line, and parameters from CruiseControl are automatically passed in and built. Next, MSBUILD is called for the "publish" target. The exact same parameters are given to the publish as the rebuild was issued. This keeps the build numbers in sync. Also, our executables are named differently (i.e. - ProjectDev and ProjectTest). We end up with different version numbers and names, and this allows ClickOnce to do its thing.
The last part of Publish.bat copies the actual files to their new homes. We don't use the publish.htm as all our users are on the network, we just give them a shortcut to the manifest file on their desktop and they can click and always be running the correct executable with a version number that ties out in CruiseControl.
Here is CopySettings.bat
XCOPY "F:\Source\Project\Environment\CruiseControl\Project\app.config" "F:\Source\Project\Environment\Project" /Y /I /R
XCOPY "F:\Source\Project\Environment\CruiseControl\Project\My Project\Settings.Designer.vb" "F:\Source\Project\Environment\Project\My Project" /Y /I /R
XCOPY "F:\Source\Project\Environment\CruiseControl\Project\My Project\Settings.settings" "F:\Source\Project\Environment\Project\My Project" /Y /I /R
And lastly, here is Publish.bat
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe /target:rebuild "F:\Source\Project\Environment\Project\Project.vbproj" /property:ApplicationRevision=%CCNetLabel% /property:AssemblyName="ProjectEnvironment" /property:PublishUrl="\\Server\bin\Project\Environment\\"
C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe /target:publish "F:\Source\Project\Environment\Project\Project.vbproj" /property:ApplicationVersion="1.0.0.%CCNetLabel%" /property:AssemblyVersion="1.0.0.%CCNetLabel%" /property:AssemblyName="ProjectEnvironment"
XCOPY "F:\Source\Project\Environment\Project\bin\Debug\app.publish" "F:\Binary\Project\Environment" /Y /I
XCOPY "F:\Source\Project\Environment\Project\bin\Debug\app.publish\Application Files" "F:\Binary\Project\Environment\Application Files" /Y /I /S
Like I said, it's probably not done the way that CruiseControl and MSBUILD developers had intended things to work, but it does work. If you need to get this working yesterday, it might be the solution you're looking for. Good luck!
I remember doing this last year for a ClickOnce project I was working on. I remember it taking me forever to figure out but here it is. What I wanted my scripts to do was to generate a different installer that pointed to our dev env and a different one for prod. Not only that but i needed it to inject the right versioning information so the existing clients would 'realize' there is a new version out there which is the whole point of clickOnce.
In this script you have to replace with your own server names etc. The trick is to save the publish.htm and project.publish file and inject the new version number based on the version that is provided to you by CC.NET.
Here is what my build script looked like:
<target name="deployProd">
<exec program="<framework_dir>\msbuild.exe" commandline="<project>/<project>.csproj /property:Configuration=PublishProd /property:ApplicationVersion=${build.label}.*;PublishUrl=\\<prod_location>\binups$\;InstallUrl=\\<prod_location>\binups$\;UpdateUrl=\\<prod_location>\binups$\;BootstrapperComponentsUrl=\\<prod_location>\prereqs$\ /target:publish"/>
<copy todir="<project>\bin\PublishProd\<project>.publish">
<fileset basedir=".">
<include name="publish.htm"/>
</fileset>
<filterchain>
<replacetokens>
<token key="CURRENT_VERSION" value="${build.label}"/>
</replacetokens>
</filterchain>
</copy>
</target>
Hope this helps
Just be able passing the ${CCNetLabel} in the CCNET.config msbuild task would be a great improvement.
You want to use the ClickOnce manifest generation tasks in msbuild. The process is a little long winded, so I am just going to point you to a couple of links. Here is the reference on msdn and a sample article to hopefully get you started.