I'm looking for a way to call MSBuild with all possible configurations/platforms defined in the solution file.
I've looked here:
Using MSBuild to Build Multiple Configurations
which requires explicit knowledge of the configurations, as you must enumerate them on the command line,
and here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/066c9dbf-d191-4b8c-8ee1-b9709b56c500/msbuild-for-visual-studio-2010-build-all-configurations-of-a-vcxproj-file?forum=msbuild
which leads to another page that suggests defining another project file to encapsulate the msbuild calls. Unfortunately, it too requires explicit knowledge of the configurations.
So then, is there any way to obtain through the command line, the list of configurations/platforms availalbe to a given project? (It must be the same list that is modified in Visual Studio. ie: adding/removing a configuration in Visual Studio, saving, exiting, and getting the list, would reflect the changes.)
Parsing the solution file as XML is not an option, as it wouldn't be stable if Microsoft decided to change how it is formatted.
You can't parse a solution as XML it's not a markup file without having MSBuild emitting a meta project first. I recommend you play the odds and be pragmatic, read the .sln as a text file and RegEx it on SolutionConfigurationPlatforms pairs, then build the ItemGroup and batch it. If you are truly utterly paranoid about Microsoft completely reengineering the solution file syntax then look inside Microsoft.Build.Construction and/or .Evaluation, the internal SolutionParser, or Roslyn or even Mono since if the syntax changes then those parsers and loaders would be updated accordingly and in case of Microsoft.Build and Roslyn -- simultaneously.
Related
I'm following many blog/StackOv posts to make this. Still I get blue lines. And my vedlegg folder is deleted.
I'm using MSBuild for publishing from command line.
In most cases you can safely ignore squiggly lines in MSBuild file. The XSD files that Visual Studio uses for MSBuild only support subset of MSBuild syntactical expressions. Most of the properties, groups and metadata for standard targets are reflected there, but not any custom build elements.
You can interpret the squigglies as anything that is outside of standard MSBuild properties and tasks. I also notices in many cases even standard tasks and properties are not present in XML schema for MSBuild files supplied by Microsoft, which is an obvious bug, but there is very little useful you can get from those XSD files anyway.
I have a build process (let's call it the "engine") that has been using a command line call to Visual Studio's devenv.exe to build a project. I have known for some time that VS is just building with MSBuild, so I finally got around to updating the engine to use MSBuild directly. However, I'm finding a strange anomaly with MSBuild.
For the sake of discussion, there's projects A, B, C, and D. Project A is the main project I'm building, a web app, that depends (through project references) on the other 3 projects. When built manually in VS, A\bin is populated with assemblies. When built in the engine with devenv.exe A\bin is again populated with the expected binaries. When built in the engine use MSBuild, A\bin contains nothing. However, B\Release\bin, C\Release\bin and D\Release\bin contain their binaries as they did using the former 2 build methods.
This happens with just a single project as well. The problem doesn't appear to be related to dependent projects.
I have attempted to explicitly set the MSBuild OutDir property, but it doesn't appear to have any affect.
I have run builds with diagnostic output on and can't see anything obvious (granted, there is a LOT there so it's possible I have yet to find something significant).
I've also been trying to figure out how to see the command line call to MSBuild that VS is making when run from devenv.exe but I can't seem to find it.
I have looked at several other SO posts (here and here) but they aren't the same problem.
Anyone have an idea of what this could be or where else I could look for an answer or more diagnostic information?
EDIT 1: The arguments pattern used for the call to MSBuild looks like this:
/nologo /target:Compile /property:Configuration=%%BUILDCONFIG%% /maxcpucount
/property:OutDir=%%OUTDIR%%\bin\ /verbosity:diag /detailedsummary "%%PROJPATH%%"
The lower half of that shows my attempt to force the output directory as well as the enhanced output to show more details of the process. Build engine code replaces with "%%TOKEN%%" items with the appropriate replacement values for the project being built.
EDIT 2: After more research and looking into suggested provided, I've decided to abandon the effort to use msbuild instead of devenv. It seems there is a lot more going on under the hood of devenv in preparation its own call to msbuild and I could likely break something else going on if I don't fully understand the entrance in msbuild. I did try to see if the call to msbuild from devenv is logged, but it doesn't seem to be. I've considered building a dummy msbuild app to just dump the command going into it and temporarily swap out the actual msbuild to generate this diagnostic information, but that's more effort than it's worth at this point. The performance gain isn't so great that it's worth pursuing further for now.
I would look at the Output path on the build tab of your project properties. There are more than few differences when using MSBuild and when using Visual Studio (Even from the command line). It could be you have A configured differently than B,C,D and synching A to the rest will make it work. Also, if you plan to build the projects individually, not as a solution make sure you don't use Solution Level macros that won't be available to the project file on it own.
You are supposed to set OutputPath instead of OutputDir.
Since you already used /verbosity:diag, why not redirect the output to a text file and carefully analyze where csc.exe (or another compiler in use) stores the binaries? That's quite simple and informative for you to learn how MSBuild works under the hood.
I've just learned the hard way that Visual Studio 2010 and MSBuild extremely lenient when it comes to which vcxproj MSBuild files they will successfully execute - they will overlook missing configurations for subtasks and single files and still successfully execute the build tasks. However this is causing problems for me as it is leading to inconsistent builds across multiple configurations, plus due to the internal inconsistencies in the project files I cannot necessarily edit them in Visual Studio's property view.
So far I have managed to get rid of the most problematic inconsistencies by editing the vcxproj files by hand but this is not really an acceptable strategy given that this particular solution contains over 80 project files.
Is there a tool that can check an MSBuild file for internal consistency and highlight missing configurations along the lines of "your project files says it offers configurations X, Y and Z but the custom build task for file X only supports configurations X and Z"?
Update: The specific problem I am trying to solve right now as opposed to the more general problem of linting the vcxproj file is that of missing conditionals for certain configurations. Unfortunately adding and updating the conditionals seems to require a little more than I can safely accomplish using a find-and-replace tool. Doing it programmatically and correctly would most likely require DOM manipulation and given that I am rather familiar with the internal structure of the build files so far it appears that using a text editor that is able to do basic structural XML validation is the quickest way to accomplish the task at hand.
What I would really like to see however would be a tool that can at least highlight these problems automatically to cut down on the time spent tracking them down.
Configurations are, in general, a VS concept. They are not built-in to MSBuild but achieved using Conditional attributes on property groups. Most likely your project files are valid MSBuild projects, but some of them don't build with default parameters - I'd suggest not to edit them by hand, but either
use a find-and-replace tool to fix them
write a small app that uses Microsoft.Build.Construction API to inspect and fix the project files
There's nothing that would perform this for you, I'm afraid.
This request is currently tracked under https://github.com/dotnet/msbuild/issues/1777
This is not a real answer yet, but as soon as the issue gets resolved to a tangible solution, I'll update it here.
I'm working on a project and we have a huge assembly if hundreds of types. I would like to add some kind of code analysis, but only on new types.
In FxCop I can chose the types and/or namespaces I want to have analyzed.
I can't seem to find a way to do so in VS2010 code analysis. Is it just me or is this not possible?
Yes, it's possible in VS2010, but there's no UI for creating the subset. Instead, you'll either need to either specify the inclusion/exclusion list via the CodeAnalysisAdditionalOptions MSBuild property (using the /types command line parameter that will be used when running FxCopCmd.exe) or via a .fxcop project file specified via the CodeAnalysisProject MSBuild property.
The latter approach caused problems in VS2008 since FxCop would attempt to load the target DLL twice if it was included in the project file. I haven't tried it in VS2010, but it's certainly worth giving it a shot before resorting to the CodeAnalysisAdditionalOptions approach.
N.B.: This is exactly the same answer already provided at http://social.msdn.microsoft.com/Forums/en-US/vstscode/thread/fd431e4d-401d-4b5b-b07d-144198e0dc30.
I have a question regarding the commandline options of msbuild. I am
currently using msbuild to build projects using the existing solution
files. These solution files have references to external dll which have
different paths on each machine. I am currently writing a build script
and passing the specific path to the project file via the /p: switch of
msbuild.
My current build line is:
msbuild test.sln /p:ReferencePath="c:\abc" /p:ReferencePath="c:\rca"
What i have noticed that Reference Path now contains only c:\rca and
not c:\abc. this is causing problems for me since, the external dlls
lie in two different directorys. I am allowed to keep multiple
reference paths via visual studio, but not via the commandline.
Is there any known way by which i can do this
I believe you can use this /p:ReferencePath="c:\abc;c:\rca"
At least that is what that link is hinting at, they are using %3B to encode the ";" within the build file.
Although the correct syntax for providing more the one reference path is listed above, I would suggest solving the root cause which in my opinion is the different locations of your referenced assembly. I would suggest you put all thirdparty dependencies, apart from the framework assemblies in your source code repository for the following reasons:
Relatitve paths are consistent across computers
The source code is always in sink with the correct version of your thirdparty assembly (if you for instance need to build an old version of your software 2 years from now).
Upgrading your thirdparty assembly is as easy as upgrading on one machine and then committing your changes to the repository. (In a previous project we even went as far as checking in the entire java runtime environment and were quite happy with the given setup.)
Try seperating your pathes with a semi-colon (;)
Like this:
c:\abc;c:\rca
You may be better off by synchronizing your libraries across machines. I have found that Visual Studio makes this easy. Simply add a solution folder, and add your libraries there. Then, in each project, reference the libraries from this common place. This way, each developer has them in the same place.
This will remove one of variables you have when trying to script out builds.
The command line options for setting the reference path will work just fine (assuming you escape the semi colon, it seems both %3B and ; will work). However, when the argument was passed in from nant (and I needed multiple paths), creating a 'Visual Studio Project User Options file' seemed to work better.
I just emit (echo) a file to the file system with the following format:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ReferencePath>
C:\abc;c:\rca
</ReferencePath>
</PropertyGroup>
I give the *.user file an appropriate name (given a project file MyProject.csproj, my user file would be MyProject.csproj.user)