4

I finally realized why my BeforeBuild Target is no longer executing as expected -- it's so silly, it's because the project's configuration names had changed. But what I really want to do is test for the solution's configuration name, not the project's.

I know that the project's configuration name is stored in $(Configuration). Is there one for the solution's configuration name? Or is this simply not possible because (presumably) the solution names are only known to the configuration manager? If so, can anyone recommend a good method for managing configurations? I'd hate to have to add duplicate project configuration names everywhere...

UPDATE: after searching and reading some docs, I haven't been able to find any proof that MSBuild is aware of the solution's configuration name when its individual project files are compiled. I went ahead and build the solution from the command line, passing /v:diag, and dumped the output to a file. I searched through the file to find any signs of it knowing that the solution's configuration name is "Deployment", but the only occurences of that string appear when the BeforeBuild condition is checked.

Dave
  • 14,618
  • 13
  • 91
  • 145
  • Yea, solution files are a visual studio concept and not a msbuild one. – Ritch Melton Nov 12 '11 at 20:16
  • That's a real shame, and actually very strange since MSBuild accepts a solution file as an argument, and the solution has all of the configuration names right inside of it! – Dave Nov 12 '11 at 23:52
  • Msbuild converts that solution file to a msbuild file and then processes the msbuild file. I agree that it sucks, but this has been part of MSBuild since it came out, so most of us are used to it. Info here:http://pjbelfield.wordpress.com/2007/11/15/the-solution-file-is-not-an-msbuild-file/ – Ritch Melton Nov 13 '11 at 00:11
  • Here's a SO link to the same concept. http://stackoverflow.com/questions/5237884/generating-an-msbuild-project-file-from-a-visual-studio-solution-file-and-proje FWIW, I make TeamCity build the top level test projects and not the solution files. – Ritch Melton Nov 13 '11 at 00:13
  • What type of project are you trying to compile? C++, C#, or some other? – Michael Price Nov 13 '11 at 05:13
  • @MichaelPrice I am compiling C# code. So far, I'm happy with the COMPUTERNAME approach, since I'm only using MSBuild community tasks for building installers in TeamCity. – Dave Nov 13 '11 at 06:59

3 Answers3

1

See my other answer. I was able to create a VS extension to get the solution configuration name as a build macro ($(variable) notation).

Community
  • 1
  • 1
ceztko
  • 14,736
  • 5
  • 58
  • 73
  • this extension is a life saver. Is there any problem with it not working during headless builds? (devenv.com) I'm having an issue where the macros are evaluating to "" – yano Oct 09 '13 at 22:36
  • @yano, the extension has been updated. Now it should be way better. Unsure if it will solve your problem with headless build but you can give it a try: not the macro setting is more prompt. Also there's a binary release that it's compatible with VS 2010, 2012 and 2013. – ceztko Mar 10 '14 at 20:56
0

There is property SolutionConfigurationContents witch is created by Msbulid during soluton file processing it contains solution configuration in it. When building from VS it will contains project (not solution) configuration.

Brans Ds
  • 4,039
  • 35
  • 64
0

The only solution I've come up with so far is to create my own environment variable on the TeamCity server, and have MSBuild check for its presence in the BeforeBuild target.

EDIT: I couldn't use my own environment variable because it wasn't getting passed to the build runner for some reason. But when I used /v:n in the TeamCity MSBuild settings, I noticed that there is $(COMPUTERNAME), which is exactly what I wanted anyway. I ended up trying this and it totally did the trick.

Dave
  • 14,618
  • 13
  • 91
  • 145