I'm embedding MSBuild directly into a more complex build tool. The relevant code looks roughly like this:
// assume 'using Microsoft.Build.BuildEngine;'
Engine e = Engine();
BuildPropertyGroup props = new BuildPropertyGroup();
props.SetProperty( "Configuration", Config.BuildConfig );
e.BuildProjectFile( projectFile, new string[] { "Build" }, props )
My question is how to cancel this build once it's started, without doing something drastic like terminating the thread. Also, if the project being built is a C++ project, the build will involve at least one sub-process, so canceling the thread isn't even going to really cancel the build.
I don't see any cancel method on the Engine class - does someone know of a way?
This question has come up a few times on the MSDN boards, and unfortunately I haven't seen any other way, apart from terminating the thread. Sadly, in this case, terminating the thread isn't really drastic with it being the only real option.
On a random side note, I am not sure to what extent you are using MSBuild with what you are doing currently. Just wanted to recommend taking a look at the MSBuild Extension Pack on Codeplex if you work with MSBuild on a regular basis.
I had done something similar by running msbuild from command. This starts a process which you could terminate.
From my experience, it is far easier and flexible to manipulate the project files using xml tools and then execute msbuild than it is to programmatically configure your projects the way you have described. It is also more manageable.
It appears is that there's no official way to do this.
For C# builds it's not a huge deal, since they are typically really fast. The best workaround I've come up with for C++ builds is to locate the child processes that are created by the VC build process and terminate them, which stops the MSBuild build. This can be done using a Toolhelp32 snapshot, something like this (omitting P/Invoke garbage):
CreateToolhelp32Snapshot( ToolHelp.SnapshotFlags.Process, 0 );
From here you can determine the parent/child relationship between processes and find the processes spawned by the app that's invoking MSBuild.
Related
Background:
I'm working on two projects in visual studio 2015 - one that produces a file (I'll call it "Generator"), and one that uses said file at runtime (I'll call it "Consumer").
What I want to do:
I'm currently working on the file produced by Generator. In order to see how Consumer is affected after modification of Generator I have to:
Build and run Generator,
Switch startup project to Consumer,
Build and run Consumer,
Switch startup project back to Generator.
I'd like to have all of this done in a single Ctrl+F5.
What I've tried to do:
In the solution properties->startup project there is an option called "Current selection" that makes this tedious process a bit faster, but this is only a partial solution.
I tried to use "multiple startup projects", but this approach isn't for me - it runs these projects simultaneously and I want Consumer to wait until Generator is done.
In my most succesful approach I made a .bat that runs Generator and added it to one of build steps in Consumer (doesn't really matter what step - I used "prebuild event"). I also added Generator to Consumer's Build Dependencies. It works perfectly when I modify both Generator and Consumer. The problem appears when I modify Generator only - in such case build of Consumer doesn't trigger at all - which means that my bat file won't run Generator (I think that Consumer should be build, because dependent project was modifed).
What I don't want to do:
My solution contains other projects, some of which take long time to build - I don't want to rebuild whole solution or any projects other that the two I was talking about.
Answer to this question isn't for me - I don't want to alter Consumer only to simplify the building process, because Generator is merely a utility to create some file used in the main program (Consumer). On the other hand I don't mind adding some additional projects.
To summarize:
If you know how to force project to be rebuild when it's dependency is out of date I'd be happy. If you know any other way to deal with my problem I'd be happy either.
I found a "how did I not think about it before?" kind of solution:
Since I want to run Generator after it's modification I in fact want to run it after it's build. So instead of trying to run it in Consumer's build i do this as Generator's Post-build Event.
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 have a little program I wrote to download all NuGet packages for a solution. I would like to setup a pre-build event that would run this program every time I build.
But I need it to run before the first project starts to build. I could look at what is currently building first, and put it on that project's pre-build event, but that is fairly brittle. Any time I add a new project or update references between projects, I would have to double check that the "first" building project is still the first one.
So, what I really need is a way to do this before any building really starts. I have heard of Visual Studio macros. But those are not something that gets checked in so I would prefer to not use those (but if that is my only option, I would use them).
You could try this: http://sedodream.com/2010/10/22/MSBuildExtendingTheSolutionBuild.aspx
Unfortunately it only works called from the command line via MSBuild. Seems to be a design flaw that the behaviour is different and these events are not available via the IDE.
You could also modify your base MSBuild tasks to include the action based on a specific flag/file existence/solution name, but this is all sorts of evil.
Otherwise, you are pretty stuck with a prebuild on each project.
I call nuget install from the prebuild event for any project that uses nuget packages. It is smart enough to only download packages that have not already been downloaded.
So this is a question for anyone who has had to integrate the building/compilation of legacy projects/code in a Team Build/MSBuild environment - specifically, Visual Basic 6 applications/projects.
Outside of writing a custom build Task (which I am not against) does anyone have any suggestions on how best to integrate compilation and versioning of legacy VB6 projects into MSBuild builds?
I'm aware of the FreeToDev msbuild tasks at CodePlex but they've been withdrawn at the moment.
Ideally I'm looking to version and compile the code as well as capture the compilation output (especially errors) for the msbuild log.
I've seen advice on encapsulating this functionality in a custom task, but really wondered if anyone has tried another solution (aside from executing shell commands) -
In essence, does anyone have a "cleaner" solution?
Ideally, executing commands using would be a last resort..
The VB6 task will be back on Monday. With regards to versioning, there is no explicit vb versioning task in the pack, however you could make use of the TfsVersion (TaskAction="GetVersion") and the File (TaskAction="Replace") tasks. If you think there is value in creating a new task to encapsulate / provide other functions, then please let me know and I will add it to the pack for the benefit of the whole community.
Apologies for the withdrawal, but come Monday I'm sure all will understand.
I am using Nant to build VB6 projects daily. This does resort using the Nant execute command to do the builds (we build 4 projects as part of one "solution").
It also allows you to label versions in your source control repository, get latest code, check in, check out, all the normal requirements, compile the update/setup programs copy the files to required locations and send emails of the results.
The logged results are fairly minimal though as you only get the output provided by a VB6 command line compile.
For versioning, I had to write a small app to extract the version number of my compiled executable and write it to a text file that Nant could then read and use (for labels, file names etc. (A bit of a pain but VB generated version numbers don't comply anyway).
For help with other non-core tasks see NAntContrib - from the NAnt link above.