How do I pass this common property to MSBuild using TeamCity? - msbuild

I am using the TeamCity Visual Studio runner. I want to add a setting that is not accessible from Visual Studio.
/Property:FileAlignment=4096
I typed that directly into the build step "Command line parameters." The build log shows the error:
MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameters instead.
I don't understand how to provide this to MSBuild from TeamCity and get rid of this warning!
1. Which kind of parameter should I use?
There are 3 kinds:
Configuration parameters
System properties
Environment variables.
I don't want an environment or system variable because I don't want this build to depend on anything external. I am going to try Config right now, but then I'm not sure I'm filling it in right.
2. How can I tell this parameter is actually getting used?
The build log, which seems only to have navigable/foldable xml-like levels with their program, did not say the build parameters.

You should use "System properties". Don't worry about the name, that's just how TeamCity calls it. They are regular properties. You can add them in "Edit Configuration Settings > 7. Build Parameters".
For example, you can add the system property as follows:
Name: system.FileAlignment
Type: System property (system.)
Value: 4096
Note that TeamCity will insist on the "system." prefix. It doesn't matter because the MSBuild script will still see it as $(FileAlignment).

The TeamCity documentation defines Build Parameters as "a convenient way of passing generic or environment-specific settings into the build script". Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. System and Environment parameters are provided to your build script. Environment variables are actually set on the system (I can't find any documentation for this). System parameters are passed to the script engine.
TeamCity automatically provides System variables to the actual command line (it looks like the Visual Studio runner runs msbuild.exe and not devenv.exe). I guess that TeamCity is constructing a command like
cmd> msbuild.exe my-solution.sln /p:FileAlignment=4096
I tried this on my command line, just to make sure that it should work (I added the /v:diagnostic flag). The diagnostic verbosity makes msbuild print all of it's properties to the console. I verified that FileAlignment=4096 was in there.
That /FileAlignment property appears to be a special property that's automatically in any .csproj file. So you should be good to go. You can check the actual parameters that were passed to the build by clicking on any build and viewing the 'Build Parameters' tab. There's a section that shows the "Actual Parameters on Agent".

This was solved. To clarify, Anthony told how to solve the problem in the commandline using MSBuild. It can also be solved on the commandline using devenv, per a ticket with Microsoft, the syntax is:
devenv ..\..\mysolution.sln /Rebuild /Property:Config=Release;Platform=AnyCPU;Filealignment=512
What I wanted, however, was to get Teamcity's "Visual Studio Build" to accept the parameter. This was achieved as follows. In the box for Command line parameters, I entered:
/Property:FileAlignment=filealignment v:diag
Then the output tab for Build Parameters shows:
User Defined Parameters
Name Value passed to build
system.filealignment 512
system.verbosity diagnostic

(This is -754 chars for a comment so must be typed as a post)
hi Anthony, Thank you for replying!
Yes, msbuild on the commandline works fine for me as well and project files may store FileAlignment properties. In our case, upon discussion with Microsoft, it appears necessary that I specify the solution-wide aka build-wide alignment, ie in the command arguments, in addition to fixing the projects (which I have already done).
No parameter that I specify on the GUI item ( /Build Step / Command line parameters/ ) will appear on the tab /Build Parameters/. Of course some will not compile at all.
Also I have even more weird behavior where using
/verbosity:diagnostic
vs
/verbosity:minimal
causes a longer build log for the minimal! It appears diagnostic is hiding the details inside of a special task, which is part of Teamcity and not me;
[16:24:05]: Overriding target "SatelliteDllsProjectOutputGroup" in project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets" with target "SatelliteDllsProjectOutputGroup" from project "C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets".
I am struggling with this because the Teamcity-generated build output log is so nice to have as a TreeView. That works with the SLN build but using any bat file cannot produce log file with the pretty (xml, presumably) tree-format.
If you have further ideas I will love to hear them, and thank you for your edits! :)

Related

TFS Build ignores configured Code Analysis ruleset

I have a solution that is using an hybrid .csproj and project.json combination (for nuget management purposes). So basically the "project.json" file is working as a "packages.config" file with a floating version capability.
This solution is using a custom RuleSet that is being distributed via Package, and is imported automatically. On the dev machine, works without a problem.
At the build machine (that is, inside the machine itself, working as an user) the solution also compiles without a problem.
However, when a vNext build (is this the name for the new build system?) is queued, it ignores completely the custom ruleset and just uses the StyleCop one (that is also included), which gives a bunch of warnings. Said warnings should not appear as the Custom RuleSet basically suppresses those warnings (ie: Warning SA1404: Code analysis suppression must have justification,
Warning SA1124: Do not use regions, etc)
As far as I have checked, there is no setting to specify the ruleset, and this works with XAML Builds. What is different in this new build system that is causing this? Is there a way to force/specify the Code Analysis Rule Set from the definition?
Thanks in advance for any help or advice on the matter.
Update/Edit
After debugging back and forth with the wonderful help of jessehouwing I must include the following detail on my initial report (that I ignored as I did not know that it was influential):
I am using SonarQube Analysis on my build definition.
I initially did not mention it as I did not know that it replaces the Code Analysis at Build Time (and not only when it "analyzes", as I thought).
If you are using the SonarQube tasks
The SonarQube tasks generate a new Code Analysis Ruleset file on the fly and will overwrite the one configured for the projects. These rulesets will be used regardless of what you've previously specified.
There is a trick to the naming of the rulesets through which you can include your own overrides.
More information on the structure can be found in the blog post from the SonarQube/Visual Studio team. Basically when you Bind your solution to SonarQube it will generate 2 ruleset files. One which will be overwritten during build, the other containing your customizations.
There is a toolkit/SDK to generate a SonarQube plugin for custom analyzers which allow you to import your rules into SonarQube, so it will know what rules to activate for your project(s).
If you're not using SonarQube
Yes you can specify the ruleset you want to use and force Code Analysis to run. It requires a couple of MsBuild arguments:
/p:RunCodeAnalysis=true /p:CodeAnalysisRuleset="PathToRuleset"
Or you can use my MsBuild helper extension to configure these settings with the help of a UI template:

Modify website MSBuild options to include configuration in path

I'm in the process of updating an old solution from Visual Studio 2005 to Visual Studio 2015, and I'm trying to reproduce as much of our old kludgy behavior as we safely can to minimize the downstream effects. I'm currently running into an issue with the Website Property Pages and MSBuild.
The path here is mostly correct, except that we want the configuration used to be in the path as well. So a Debug build will go into E:\Projects\...\PrecompiledWeb\Debug\MyService and a Release build will go into E:\Projects\...\PrecompiledWeb\Release\MyService. Is this doable? Is there a variable I can insert to make that determination when building?
We're using msbuild against the containing solution file (via TeamCity if it matters, but I can replicate it without it).
Edit: I've found the Debug.AspNetCompiler.TargetPath and Release.AspNetCompiler.TargetPath paths in the solution, but if I change them to be separate, the Debug one overrides the Release one when I next open the dialog.
When MSBuild starts building the project, it takes one or several project files. This dialog takes it parameters from MSBuild project file (you can edit it either from Visual Studio, or simply in every text editor). The project should have the property, called $(Configuration). You can use it in your output variable:
<OutputPath>E:\Projects\...\PrecompiledWeb\$(Configuration)\MyService</OutputPath>
One thing you must aware of is that the property $(Configuration) must be declared before the $(OutputPath) property.

How can I pass MSDeploy-style parameters to MSBuild via the commandline?

I am setting up TeamCity to deploy our Website Project application (using a *.wdproj) and Web Deploy application to IIS.
I have a build configuration that uses MSBuild.exe with the MSDeployPublish to build and then deploy the application.
We now want to get the application to deploy to multiple target environments, therefore need a way to supply different settings based on the target environment.
I have added a parameters.xml file to the Web Deployment Project, and have verified that the parameters set in here are making all the way through the target IIS server and being correctly applied - great!
Now what I want to do is have different parameter settings per environment. I was hoping I could use something like the MSDeploy.exe -setParam argument to specify different values for each environment, however I can find no way to get my parameter values into MSBuild via the commandline.
I suspect I might need to do one of the following:
Split MSBuild and MSDeploy into separate build steps.
Configure a task somewhere in the pipeline to take 1 of n versions of parameters.something.xml and move it into parameters.xml so it gets picked up by the rest of the pipeline.
I'm looking for the simplest way to move ahead at this point, any suggestions welcome.
For reference, here is the command I'm experimenting with now:
msbuild /target:MSDeployPublish MySite_deploy.wdproj /P:Configuration=Debug
/P:DeployOnBuild=True /P:DeployTarget=MSDeployPublish
/P:MsDeployServiceUrl=www.myserver.com:8172/MsDeploy.axd
/P:AllowUntrustedCertificate=True /P:MSDeployPublishMethod=WMSvc
/P:CreatePackageOnPublish=True /P:UserName=MyUser /p:Password=MyPassword
/P:DeployIisAppPath=www.myserver.com/MySite
/P:ServerURL=http://www.tryingtoforcethis.com
It's working beautifully except the value for ServerURL, which is a parameter I've defined in my parameters.xml, is not making its way into the target site. The default I specified in parameters.xml, however, is. So I know that the parameters are working, I just can't figure out how to add them to the msbuild commandline.
Well, I think the short answer is that with MSBuild 4.0 and VS2010, you can't just pass arbitrary parameters into MSDeployPublish from the call to MSBuild.
I found these posts helpful:
http://forums.iis.net/t/1167657.aspx/1 - Ming Chen's comments
http://www.hanselman.com/blog/TinyHappyFeatures3PublishingImprovementsChainedConfigTransformsAndDeployingASPNETAppsFromTheCommandLine.aspx - the comments from Richard Szalay at the bottom
After reading these, and sifting through the Microsoft.Web.Publishing.targets file for some time trying to find a "way in", I finally settled on having multiple copies of Parameters.xml in my project folder in source control, labelled according to their environment eg:
Parameters.Test.xml
Parameters.Staging.xml
Parameters.Live.xml
Then, prior to the package and deploy, I just copy one of these files into Parameters.xml and it gets picked up by the rest of the pipeline - done!
BTW I had a temporary problem getting the parameters.xml copy and subsequent cleanup to work within a single MSBuild.exe call due to what seems to be some sort of file access issue, I've detailed it here:
MSBuild.exe Copy task not working properly unless a version of the file already appears in target
To answer your question, the parameterization of your command line is not a concern of MSBuild. Instead, you should utilize external tools. For example, if you run your msbuild command from a batch file you could pass the parameters to the batch file and run it for each environment with different parameters. Another approach is to use a build system like TeamCity or VSTS and utilize their parameterization mechanism. Adapted for the VSTS or TFS, your command could look like this:
msbuild MySite_deploy.wdproj /target:MSDeployPublish /p:Configuration=Debug
/p:DeployOnBuild=True /p:MsDeployServiceUrl=$(IIsHostNameIp)
/p:AllowUntrustedCertificate=True /p:MSDeployPublishMethod=WMSvc
/p:CreatePackageOnPublish=True /p:UserName=$(IIsUserName) /p:Password=$(IIsPassword)
/p:DeployIisAppPath=$(IIsSite)
In addition, I would suggest some clean up for your origianl command line:
Using both /p:target and /p:DeployTarget is redundant. Any one of them is enough. Also it could be replaced with /p:WebPublishMethod.
For /p:MSDeployServiceUrl it is enough to only provide a DNS name or IP. the port and the Url is automatically derived from the /p:MSDeployPublishingMethod=WMSVC.
The custom parameter /p:ServerURL is unknown and won't be mapped anywhere.
msbuild.exe {build-script.proj} /property:{someParameter=someValue}
In your build script you can use $(someParameter) as a variable

Setting build configuration to staging

Simple question. How do I set the build configuration to something other than Debug?
Setting /P:Configuration=Staging in the Command line parameters box, leads to this error:
TeamCity says to use "Build Parameters" instead of "/property:" in an MSBuild step. What does that mean?
So how is it done? I need to build MSDeploy packages for all configurations, I can get the packages to build but everything is Debug.
The way you're doing it is fine -- although perhaps use a lowercase /p:. Our team does it this way too. TeamCity isn't throwing an error, it's just trying to provide some helpful information.
JetBrains provides some documentation for its preferred method at the bottom of the page under Using System Properties in Build Scripts.

Can you turn off conditional compilation symbols from msbuild.exe command line?

We have CODE_ANALYSIS defined in our C# components so that FxCop analyzes them when we build them on our development boxes. I would like to have FxCop turned off when it runs through our build system. The build system is obviously using the msbuild.exe command line command. Is there a way to modify the conditional compilation symbols from this executable? If not, does anyone know any other possible solutions to my problem (other than turning it off manually)?
Thanks.
The CODE_ANALYSIS compilation symbol controls whether the SuppressMessageAttribute instances included in the code are copied into the compiled assembly. It does not control whether FxCop runs. If you want to override a project-level MSBuild property like RunCodeAnalysis (which is the beastie that controls whether FxCop runs under MSBuild), you should be able to use the MSBuild.exe /property command line switch. e.g.:
msbuild.exe <...> /property:RunCodeAnalysis=true
Why do you need to turn them off? The best way to set up the project is to define CODE_ANALYSIS for debug configurations only. The release version will not have this value set. That way, when you build production installs, they will not have any references to FxCop.