80

I have a TeamCity server setup to do my CI builds. I'm building and testing a C# solution and running some custom MSBuild tasks. One of these tasks is printing a warning in my build output...

MSBuild command line parameters contains "/property:" or "/p:" parameters. Please use Build Parameteres instead.

I don't understand what this means or how to remove it. It doesn't Google well (with or without the typo). I ran the task from the command line (with /verbosity:diagnostic) and it doesn't appear, so I believe it's a TeamCity message.

The MSBuild task is

<Target Name="InstallDb">
  <MakeDir Directories="$(DbPath)" />
  <Exec Command="sqlcmd -S .\sqlexpress -i db\OmnyxDatabaseDrop.sql" />
  <Exec Command="sqlcmd -S .\sqlexpress -i db\OmnyxDatabaseCreate.sql -v DbPath=&quot;$(DbPath)&quot;" />
  <Exec Command="sqlcmd -S .\sqlexpress -i db\OmnyxDatabaseProgrammability.sql" />
</Target>

And the relevant TeamCity step information is

MSBuild version: 4.0
MSBuild ToolsVersion: 4.0
Run platform: x64
Targets: InstallDb
Command line parameters: /property:DbPath=%env.DB_PATH%

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
  • 5
    @AnneTheAgile you simply add a TeamCity *System* Build Parameter. It's one of the 3 types of build parameters you mentioned. You name it like 'system.' and provide the value that you want. TeamCity will automatically send it to MSBuild. You can check the value of the parameter in the build report. There's a tab for parameters where they all get listed. – Anthony Mastrean Jan 11 '12 at 00:22

2 Answers2

58

You have to add Build Parameters under Properties and environment variables in the configuration

`enter image description here

So in the command line parameters in the Build Step for MSBUild, remove any property that is specified as /p: and add each of those to the Build Parameters ( screenshot above) and give the values

Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
manojlds
  • 290,304
  • 63
  • 469
  • 417
  • 5
    @Anthony Mastrean Yeah - `Build parameters are passed to a build. Build parameters can be of two types: system properties and environment variables. Environment variables are supported by any build runner, however system properties are only available for build runners with property notion. For example, Command line runner does not support properties. ` – manojlds Jun 02 '11 at 18:26
  • 8
    Thanks! This worked, but I had to visit [this](http://confluence.jetbrains.net/display/TCD6/Defining+and+Using+Build+Parameters+in+Build+Configuration) doc to really understand the implementation/usage. – Anthony Mastrean Jun 03 '11 at 16:10
  • Sorry I'm probally being a bit dense. How do you use them ? $(%DbPath%) or $(DbPath) neither seem to be working for me? – Mark Broadhurst Jun 30 '11 at 16:33
  • 2
    from team city docs: Configuration parameters provide a way to override some settings in a build configuration inherited from a template. They are never passed to a build. – topwik Dec 13 '11 at 17:24
  • 1
    @towpse I read that, too. It's completely confusing. Normally TC docs are great but that guy must have been on holiday when they wrote this bit. – Luke Puplett Dec 18 '12 at 17:41
  • 8
    This seems to be a problem if you have two MSBuild steps within the same build configuration that use the same parameter, but different values. If they have to be defined at the "Build Configuration" level, then it looks like it's impossible to pass different values of the same param to a build step. – TSmith Apr 15 '13 at 13:32
  • 3
    This would be great. Except its a bug. What if you want different params passed to two different build steps that share the same parameter name? – Doug May 30 '13 at 02:25
  • 2
    @TSmith - The really bizarre thing is that TeamCity *does* support per-step parameters. If you convert it to a meta-runner and look at the XML, you can see them for each step. But there's no way to see that in the UI. – Bobson Oct 15 '15 at 11:49
39

It all happens behind the scenes! You just have to follow the right conventions. In your MSBuild script, you use the regular variable notation

$(DbPath)

And in TeamCity, you define a system or env variable

system.DbPath

TeamCity will automagically send all of its system/env variables to your MSBuild task, removing the 'system' or 'env' part. And you don't have to write /property:DbPath=system.DbPath in your TeamCity task.

casperOne
  • 73,706
  • 19
  • 184
  • 253
Anthony Mastrean
  • 21,850
  • 21
  • 110
  • 188
  • According to [the docs](http://confluence.jetbrains.net/display/TCD6/Defining+and+Using+Build+Parameters+in+Build+Configuration#DefiningandUsingBuildParametersinBuildConfiguration-UsingSystemPropertiesinBuildScripts), only **system** variables are injected into scripts. – ladenedge Sep 28 '11 at 19:32
  • 1
    As I understand it, [environment vars](http://confluence.jetbrains.net/display/TCD65/Configuring+Build+Parameters#ConfiguringBuildParameters-SystemPropertiesandEnvironmentVariables) are set as actual environment vars on the build agent. While they might not be passed to the build script/step like system vars, they are available for use. MSBuild must use environment vars to provide values for `$(MyVar)` because I have a TeamCity environment var that's providing a value for a goofy cmd line tool that I call with MSBuild. – Anthony Mastrean Oct 31 '11 at 01:52
  • This is really bad advice, as it could cause chaos with concurrent build configurations both building simultaneously if the value at the system-level is different. It is an implicit race condition. – John Zabroski Jul 21 '21 at 21:19