I am trying to use MSBuild to compile a solution with a few BizTalk 2010 projects (maps, schemas, pipelines) and a few non-BizTalk projects (console app, web app).
MSBuild gets triggered by Nant. The problem is that, everytime I run the compilation, the BizTalk projects get recompiled (and the assembly version number changes). This happens even if there are absolutely no changes to any part of the entire solution.
In other words, If I build the solution once, the assemblies get created fine. Immediately, if I build again, the non-BizTalk assemblies do not get re-created (MSBuild reports Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files). But, the BizTalk assemblies happily get re-created. This is annoying.
Please can someone help/advise?
BizTalk Server 2009 and 2010 .btproj project files are, indeed, MSBuild projects. As you have noticed, the way standard BizTalk targets are authored prevents incremental build of BizTalk projects.
Fortunately, MSBuild is extensible and can be customized in many ways. Please, follow the instructions on this post to to alter the standard build logic of .btproj files in order to add incremental support for your build system.
Related
My solution consists from C# projects. I need one build definition that builds the whole solution. Most of projects have project to project referencies (like ProjectReference Include=) but some projects have explicit dependencies stored in solution file (ProjectSection(ProjectDependencies) in sln file).
old connect.microsoft.com article
claims that MSBuild ignores order specified in solution "Project dependencies". Are situation the same in TFS 2015? What MSBuild version does TFS 2015 use nowadays?
Does TFS 2015 Team Buider that uses MSBuild order building of projects properly according to dependencies stored in solution file?
It does, at least on solutions I have seen (consisting of 10-15 projects) dependencies never give issues.
Additionally TFS2015 have Visual Studio build step which is run not by standalone msbuild but Visual Studio installed on the build server. Naturally this build step completely replicates your local build behavior.
I have an WCF project that if i use the Visual Studio option "Publish" gets published fine.
But if I use the MSBuild parameter DeployOnBuild it does not get published correctly. I'm getting an "Could not load type" error, and all of de dlls are there.
I using the MSBuild in a Build Definition in order to have a Continuous Integration Build.
The build parameters I'm using are:
/p:DeployOnBuild=true
/p:DeployTarget=MSDeployPublish
/p:MSDeployPublishMethod=RemoteAgent
/p:MsDeployServiceUrl=http://host/msdeployagentservice
/p:username=#####
/p:password=****
My main problem with this scenario is that the build targets are the same, and the build definition actualy publishes the files, but somehow they are not the same.
Any insights ???
I dont like to answer my on question, but since it may help someone else is the cause of the problem.
One of the projects had a post-build command to copy the resulting
dll to another project specific directory (its not a reference
because it using dependency injection in runtime).
The dlls did not get checked in to TFS because they are not checkout automaticaly
The
Continuous Integration Build fetches the sources from TFS and the dlls are out of sync
The solution was to checkout the dlls before the build so that the checkin updates them
We are using a Cab Builder project in VS2008 to generate our CF cab files. This works well until we make changes that affect the dependencies. The Cab Builder project decides we need all sorts of additional libraries (mscorlib, etc.) that we don't need to actually deploy in our cab. We select the libraries and explicitly exclude them and commit the changes to svn -- when the build server gets the latest of the project and builds it the rogue libraries are back. We have to actually open the cab project on the build server and (again) manually exclude the libraries we don't want to include.
Is this normal behavior for the cab builder?
Is there a work around?
Will we have less pain if we give up and generate our .inf files with a different method and run the exe on the build server to generate the cabs instead of using the project?
Thank you
Ah, the CAB deployment project. I swear that thing was an afterthought and tasked out to a couple interns to develop. It's absolute garbage for anything but the most simplistic packaging scenarios.
What we do is we hand roll the INF and then call cabwiz manually. I've done this with the aid of MSBUILD to make automation pretty simple.
I seem to have missed Day 1 of MsBuild 101. I find myself asking "What does it do, what does it replace, and when do I need it?" since I can just hit F5 and compile my application.
What is the bigger picture I'm missing?
MSBuild is the build platform that enables all build activity in the Visual Studio world.
A better, more practical example would be to state that
The .csproj files (every C# project) are msbuild files
When you hit F5, you basically (oversimplifying) call msbuild.exe and passing in your .csproj file.
MSBuild empowers all the things that make hitting F5 work. From creating the "debug" or "release" folder, to dropping references into the bin\ directory, to invoking CSC ... and everything in between ... MSBuild "powers" all that.
If all you will ever need from a build is the output that F5 gives you, then you know about all you probably need to know about MSBuild.
In most commercial/practical development scenarios, however, there will come a time where there is a need to customize the build process. The most common approach is automating the build process (using either TeamBuild or some homegrown system). You may also need to
create a "packaged" deployment
link to another library outside of your project that is also actively
being developed
publish your build to an FTP and send an email to a customer notifying
them of its availability.
The use of a unified and extensible build platform (ie MSBuild) is what makes all these these possible, while still being part of the build process ... keeping the "build" part of the development pipeline simple and contained.
It's useful when you want do automated builds, and have to implement a build process
The F5 Key Is Not a Build Process and links therein (e.g this) is a good read in that regard.
Also, your Visual Studio project files are msbuild files. If you want to do more advanced stuff when you build (e.g. run a javascript minifier, have more control over autogenerated version identifiers, post processing of files etc.) , you'll have to dig into msbuild.
msbuild is used when you want to build your project from the command line. Whenever you see a continuous integration product that will automatically build your project, it will call msbuild to perform the actual build step.
I think that build servers should have the option to press F5 key in a simpler way than via windows API.
I know this is pretty stale, but here's my take on MSBuild.
It's a scriptable build tool really similar to ANT. They both use XML for configuration, so you'll be able to figure it out fairly quickly. Both have the concept of "Targets" for instance, lots more similarities in thinking, if you know ANT the switch shouldn't be tough.
MSBuild files generated from Visual Studio is really like the generated ANT scripts you get from Eclipse that build your projects, remember your includes and define your dependencies. You can modify them directly for fun and profit.
I like MSBuild, it fixes some of the stuff I find annoying about ANT.
Can anyone explain what advantages there are to using a tool like MSBuild (or NAnt) to build a collection of projects versus running DevEnv.exe from the command-line?
A colleague I had worked with in the past had explained that (at least with older versions of Visual Studio) using DevEnv.exe was much slower than the other techniques, but I haven't read any evidence of that or if that is now a moot point now that starting with 2005, Visual Studio uses MSBuild under the hood.
I know one advantage of using MSBuild allows you to build your projects without requiring Visual Studio to be installed on the build machines, but I wasn't sure if there were others.
One reason is because there's much more to building a product than just compiling it. Tasks such as creating installs, updating version numbers, creating escrows, distributing the final packages, etc. can be much easier because of what these tools (and their extensions) provide.
While you could do all this with regular scripts, using NAnt or MSBuild give you a solid framework for doing all this. There's a lot of community support for both, including additional tasks that can be downloaded (such as the MSBuild Community Tasks Project). Plus, there's support for them in numerous third party and open source products.
If you're just interested in compiling (and not the entire build process), you may find one time saving benefit of MSBuild is the support for building with multiple processors.
The obvious answer from my team is that not everbody has visual studio installed, in particular we do not install Visual Studio onto our build/CI servers.
The prime reason for using an external build tool like NAnt or MsBuild is the ability to automate your build process and thus provide continous feedback on the status of your system. Also they can be used for loads of things besides a "pure" build and that's where you really start to get value from them, it's an extremly valuable thing to be able to build and test your application with a single command.
You can also start adding stuff like collection of metrics, packinging of release binaries and all sorts of nifty stuff like that.
As far as C# goes, devenv.exe 2005 runs the compiler in-proc, which may cause out of memory exceptions for sizable solutions. Msbuild resorts to launching csc.exe process for each project. Projects that don't compile with devenv /build work fine with msbuild. Hope you like this reason.
We are experimenting with switching from DevEnv to a tool (Visual Build Pro) that uses MsBuild under the hood and we got a "Reference required to assembly 'System.Drawing..." error for a project which doesn't need it and which builds fine in Visual Studio.
We have a large system consisting of C#, managed C++, and plain old unmanaged C++ assemblies/dlls. There is C++ code that depends on managed C++ code that depends of C# code that depends of managed C++ code that depends on plain old C++ code (whew!). When we were setting up our automated build environment a few years ago we discovered that MSBuild.exe didn't properly handle all of the dependencies that we have.
Working with Microsoft we were able to solve some of the issues but not all of them. If my memory serves me, we never could get the C# assemblies that depended on managed C++ dlls to build. So we ended up making a custom build script that called devenv.exe from the command line and it worked just fine.
Of course, that was with VS2005, it might be fixed now, but the script is still working so we haven't revisited the issue.