My buildbot has been running for 3 years using devenv.com to compile the projects on Windows.
Now devenv.com has troubles to build for 64 bits versions: passing the configuration as "Debug|x64" generates command line errors because of the pipe character. Escaping and enclosing between quotes result into other errors, some because of the spaces in the directory names, some because of strangely understood command line.
I tried both vcbuild.exe, and MSBuild.exe. vcbuild.exe works perfectly: I'd like to stick to it. MSBuild.exe, on the other side, has a completely strange and complicated output that my coworkers feel terrible. But it is touted everywhere as THE way to build.
The question is: which of devenv.com, vcbuild.exe, and MSBuild.exe is the method that is most likely to last in time?
MSBuild (before Visual Studio 2010/.NET 4) doesn't itself build C++ projects. It calls out to vcbuild.exe. So if you are happy not using MSBuild then I would stick to that for the C++ projects. For managed projects (and for C++ using VS 2010) use MSBuild.
MSBuild is the method "most likely to last". VCBuild.exe is dead; it's last release was 2008. MSBuild 4.0 will still use it, if it needs to build a VC project from VS2008 or earlier. As for devenv.exe -- of course, it's just headless Visual Studio. Functionally it is the same as hitting build in VS. That means that these days, it's essentially just handing off to MSBuild, but sometimes with less parallelism than msbuild.exe will get. The main reason you might still have to use devenv.exe is .vdproj (Deployment) projects. These legacy things have a build process hard coded into VS. I recommend an alternative like WiX or Installshield which are MSBuild based. Not long now until everything build in VS is MSBuild.
In short -- MSBuild is the future, use it unless you have deployment projects or other special circumstances.
Dan
I ran into the same problem, and solved it by Windows-shell-escaping the pipe character:
"Debug^|Win32"
msbuild.exe does not (did not?) know how to build setup projects. devenv.exe does.
Related
I have a Cmake/wxWidgets project that builds fine on my pc.
I compile wxWidgets using nmake /f makefile.vc BUILD=release TARGET_CPU=X86 and generate the CMake project using cmake .. -G "Visual Studio 16 2019" -A Win32 -DCMAKE_CONFIGURATION_TYPES=Release.
Like I wrote, this compiles fine on my pc. When I want to build it using a github action on Windows 2019 Image I first pull wxWidgets, compile it using the above statement, generate wxWidgets using the aboce statement and trigger the build using a cmd-script containing "%programfiles(x86)%\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild.exe" ".\build\NaCl-Configurator.sln" /p:Configuration=Release /p:Platform=Win32 /p:PlatformTarget=x86
But when doing this I always get the following error:
wxmsw31u_core.lib(corelib_wincmn.obj) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'x86' [D:\a\abc\abc\build\abc.vcxproj]
If I switch everything to x64 it compiles fine, but I need a x86 build. Is there any system setting I'm missing?
This is not an answer, this is a recommendation.
But after spending hours looking into your issue, I am seriously pulling my hair at the Microsoft documentation for MSBuild.
Just use Ninja. This is what we use to build our x64/x86 binaries.
You might need to learn a little bit about cmake toolchains, but at least you don't have to deal with this msbuild nonsense.
Ninja is faster, works much better with cmake, is a very tiny executable, etc.
Seriously using msbuild/visual-studio on your servers isn't worth it.
Again I apologize this isn't a direct answer to your question, if you do continue down this path I'm curious to see the answer.
====================================================
What I found out though:
I will say I'm very confused about the difference between PlatformTarget and Platform. Because all the visual studio solutions I generate don't even have PlatformTarget as a property anywhere. I scanned the generated solution files and didn't see this anywhere. Granted I'm using vs2019 so maybe it's deprecated I dunno.
Prefer to expand the /p -> /property that's just good practice for your build server scripts.
Perhaps try using the platform property "x86" instead. I literally couldn't find concrete information on which was preferred/correct. Win32/x86.
And as a final guess please start printing out your compiler, and toolchain information from cmake.
Resources:
How do I specify the platform for MSBuild?
https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-target-framework-and-target-platform?view=vs-2019
Me looking at the msbuild command line, and looking at my generated visual studio solutions.
I was using another github action to access nmake to build wxWidgets. Within this action I had to specify the architecture.
So using
- name: Preparing nmake
uses: ilammy/msvc-dev-cmd#v1
with:
arch: x86
- name: start building wx widgtes
run: |
cd ${{ env.WXWIN }}${{ env.wxMSW_VER }}\build\msw
nmake /f makefile.vc BUILD=release TARGET_CPU=X86
and then going on did the trick. It was only the with: arch: x86 that was missing
While making a build automation I came across an issue. Along with upgrading Visual Studio 2013, the path to MSBuild has moved as described here http://timrayburn.net/blog/visual-studio-2013-and-msbuild/
I've updated my system path to point to this new location for msbuild. Using a regular cmd prompt msbuild resolves just fine. But running my scripts in powershell, it seems to still pick up the old one, and showing the issue as described in the link. How can I see and change where powershell and psake picks up msbuild from, so I can point to the expected version?
PSake supports more MSBuild versions on one box. You can choose version and platform eg. 4.0x64 with framework directive. Path to MSBuild tools is not taken from $env:path but is computed. It uses registry to find proper path.
VS 2013 and MSBuild Tools are supported since PSake 4.3
In PS type [Environment]::GetEnvironmentVariable("Path")
Do you see both paths? In what sequence do they appear? What occurs in cmd vs ps when you switch the order?
I am compiling the OpenCascade Community Edition (https://github.com/tpaviot/oce/) on Windows 7. The build files are generated with CMake 2.8.8.
When I use the "Visual Studio 10" generater and compile the projekt with msbuild from a console the whole build process takes 17 minutes. On the other hand, if I select "Eclipse CDT4 - NMake Makefiles" and start the build process in Eclipse, it takes 87 minutes.
Does anyone know the reason for this difference? Is there a way to make the Eclipse build much faster?
With msbuild I do NOT use parallel builds. Also when I take a look at the task manager it seems as if the CPU usage of both build processes is nearly the same.
I have searched a lot, but did not find any clue. Thank you in advance.
Yes, VS IDE projects do parallel builds. nmake does not. One think you could try is jom or some other tool, see here for information:
http://www.kitware.com/blog/home/post/434
I did not notice that you said msbuild is not doing parallel. How did you do that? It will be default do parallel target builds.
I have a .net app which has an MVC3 front end and 2 windows services.
It all depends on 2 RavenDB installations which can either be ran as windows services or IIS - I'm not bothered here.
The services are built using TopShelf and testing is done with straight NUnint. I use Github as my repo.
Ideally on each successful 'Release' build I'd like a build, test, wipe directories and RavenDb data dirs and then deploy (web and services) and then start the processes to run finishing off on a console app i'm building which can run in a default set of data.
How would you manage the deployment here? I have no CI server yet. I have a completely fresh server that I can do as I please with. I haven't done CI/CD for a long time and I suspect the weapons have changed.
Should I be looking at MSBuild/NAnt? PSake, Rake? Team City?
How would you manage the post build processes?
I've been using Jenkins with psake and it's working very well. To be honest psake does most of the work, with Jenkins simply pulling down the source and then invoking my psake script, but as Nick Nieslanik says you can easily have Jenkins call MSBuild/NUnit/etc directly if you like.
Jenkins
From a peruse of Jenkins vs. CruiseControl(.NET) threads on StackOverflow, the general consensus appeared to be to go with Jenkins. Having not really tried CruiseControl I can't vouch for that, but I will say that Jenkins is very good. I found Jenkins easy to set up. I had a quick peek at CruiseControl.NET and found Jenkins easier to get started. I haven't looked at TeamCity at all so can't speak to that.
CI: Hudson with .Net vs CruiseControl.Net
What is the difference between Hudson and CruiseControl for Java projects?
How and why do I set up a C# build machine?
Jenkins has a nice plugin system, and a lot of plugins, including one for Powershell which makes it easy to call through to a psake script.
Psake
So far I think psake is awesome. It's based on rake syntax, but is a wee bit more native to Windows than rake. As it's sitting on top of powershell, you can leverage a lot of the handy Windows admin functionality that comes with that. For example, see this post
for a great example of setting up and tearing down IIS app pools and sites direct from your psake tasks. I think that's great, and I'm not sure how you'd go about doing that in MSBuild, Nant, or rake. Basic file system operations are also it's bread and butter -- seems better than having a bunch of angle brackets just to copy some files somewhere.
As for MSBuild and Nant, I think they're both pretty powerful, but editing XML files for this kind of thing just feels painful. Powershell is a proper scripting language with deep Windows integration. psake is a DSL for building and other tasks on top of that. It's a good combo.
That said, for actually building, I just farm that out to msbuild from within psake and call it on the solution/project files I want to build. psake has a built in command for calling msbuild and specifying which version to use, etc. (Truth be told the most pain so far is from msbuild borking up on solution files that build just fine in Visual Studio.)
As you're working with RavenDB, you might be interested to know that they're using psake for building RavenDB (and Rhino-ESB).
For some good psake tips in general, see this post.
Long story short, personally I'd recommend Jenkins and psake. That combo will integrate nicely with git, msbuild, NUnit, IIS, and probably even windows services.
I'd use Jenkins as the job execution engine. Then I could create a set of MSBuild scripts to perform the core-build and use the Jenkins plug in model to add pre & post build tasks as necessary (i.e. NUnit execution and result parsing, Powershell script execution for some deployment) etc. Jenkins has great integration with Github using Post/Pre-commit hooks that allow you to set up CI builds quite simply.
I am currently writing a deployment script in MSBUILD, and after downloading several extensions, I have found myself looking at the build file and thinking:
What was the point in doing this in MSBUILD?
This deployment script is completely procedural: stop website, delete folder, copy files, change permissions, start website, etc. There is no fancy dependency stuff which I assume is the natural domain of tools like MSBUILD, NANT and MAKE.
The only reason I can see to use MSBUILD is that it comes as standard, and its easy to put the extensions into your SVN so builds 'just work'.
The problem with it is I have to spend all this time working out how to do 'basic stuff' in MSBUILD (locating extensions, working out syntax) which would be trivial (although more verbose) in Powershell or even command line.
So to sum up:
Are procedural tasks suited to MSBUILD or are you better of using something like Powershell?
Check out PSAKE and see what you think.
http://www.jameskovacs.com/blog/IntroducingPsake.aspx
http://powerscripting.wordpress.com/2009/01/25/episode-56-james-kovacs-talks-about-psake/
http://code.google.com/p/psake/
Experiment! Enjoy! Engage!
Jeffrey Snover [MSFT] Windows Management Partner Architect
MSBuild is not a scripting language and shouldn't be used as such. It's almost unfortunate that MSBuild has such a rich extensibility and is flexible enough to be used for just about anything. Use the tools that are most appropriate to the task, if you find yourself spending too much time creating functionality that is too limited and too low quality compared to what you'd be able to create with other technology, you should switch.
It really depends on your situation. If it were up to me, though, and you were using Visual Studio - I would say yes, stay with MSBuild for the sake of integration.
On the other hand, I would choose MSBUILD, as while the tasks are very procedural, it gives you the flexibility to extend this build process later on to handle more complex tasks.
msbuild comes with .NET. You have to add powershell to servers / users must add it - at least through Windows XP, server 2003. That may or may not be a problem in your environment.
I don't think procedural tasks are suited for writing in MSBUILD, simply because the shorter the msbuild, the better as far as I am concerned. I might use msbuild to call them, but would probably write an extension library to implement them.
I think it depends on how your release and deployment process flows, as to wither it makes sense to use an MSBuild extension or execute power-shell. MSBuild allows the flexiablity to handle all your process steps in one self contained execution flow.
If you need it to occur all at one time then MSBuild gives you control over the 'Events' or targets that can be overridden to meet your requirement.
If the requirement is deploy your artifacts after compiling your code then MSBuild is well suited to do this since you can use the 'AfterBuild' target that gets triggered during an MSBuild standard execution. It can make your process self contained.
Powershell cannot build your code. It would have to call MSBuild from within your script. To me it is a matter of having your build and deployment self-contained and therefore would be organized better.
MSBuild is the core Microsoft build platform and engine.