MSBuild should be fixed instead of hacked with MSBee

Topics: For MSBee Users
Aug 17, 2006 at 12:01 AM
migrated from power toy forums
originally posted by jrett
------------------------------------------------------

Granted, I know very little about msbee at this point, due to the lack of documentation, but it seems that it is a hack.

I would argue that instead of msbee, msbuild should be able to support ANY build target through the use of custom targets. I understand that msbuild does support custom targets, so why not just add a target for .NET 1.1?

I would further argue that if msbuild doesn't properly work with custom targets, such that one could easily target .NET 1.1, or C++ or any other arbitrary build, then there is a problem with msbuild at its core.

This all boils down to a simple question. Am I missing something?
Aug 17, 2006 at 12:01 AM
originally posted by jrett
------------------------------------------------------

I'd like to get some feedback on this. If you read this and agree or disagree or share a similar thought, please reply to this thread and let me know.

Thanks..
Aug 17, 2006 at 12:01 AM
originally posted by Bertan Aygun - MSFT
------------------------------------------------------

MSBee is actually several custom target files that tells MSBuild to use compilers for .NET 1.1 instead of .NET 2.0.

You can find more information on MSBee at its Codeplex project site: http://www.codeplex.com/Wiki/View.aspx?ProjectName=MSBee
Aug 17, 2006 at 12:02 AM
originally posted by DanMoseley
------------------------------------------------------

I'm not on the MSBee team, so I can't answer for them. I can try to answer from the perspective of the MSBuild team.

In my opinion, MSBee is essentially not a "hack". It's using the extensibility points that were built into MSBuild -- such as Importing custom targets that override default targets, and using custom tasks.

One way MSBee is a little unusual compared to a typical customization of MSBuild build process, is that it runs some of its tasks on the .NET 1.1 framework (by running processes out of proc). This is because those tasks behave differently depending on the framework they run on and they need to

In future, most likely MSBuild will support building projects to target arbitrary previous runtimes. It would do this by using the tasks and targets (what we call together the toolset) that shipped with those previous runtimes. Of course, MSBuild didn't exist when 1.1 was released, so MSBee has to be a little different in that respect. In future, if the multitargeting feature is added to MSBuild, something like MSBee shouldn't be necessary for versions of the redist after 1.1. It would most likely still need a mechanism to run certain tasks out of proc, for the same reason MSBee needs to do this.

The final way MSBee is a little "odd" is that it requires a separate download for something that arguably should be shipped with msbuild itself. Again this is because MSBuild was not shipped with 1.1 because it didn't exist then. A future multitargeting feature it would remove the need to download something like MSBee separately for targeting 2.0 and later -- you would just need the previous runtime installed side by side.

Comments welcome -- please copy the email below as I'm not often on this forum.

Dan (msbuild@microsoft.com)

This posting provided as-is, with no warranties.
Aug 17, 2006 at 12:02 AM
originally posted by DanMoseley
------------------------------------------------------

Bit more info based on emailed questions.

Ø I feel that MSBuild should be target agnostic. I don't understand why a build system has to know anything about the targets it is building. Take the good old 'make' system for example. A target can be anything. It doesn't even have to build software. I don't understand why MSBuild isn't like this? All it would need to do is be able to call any command line program, such as a C compiler, a C++ compiler, text processors or file system tools such as mkdir or anything arbitrary including any version of a C# compiler.

This is already true for MSBuild. MSBuild does not care what tools (tasks, essentially) and targets it runs. The confusion – and we should make this clearer – perhaps stems from the fact that we shipped MSBuild with tasks and targets to build VB, C#, and J# projects designed to run on the .NET 2.0 platform. MSBuild can use any other targets and tasks, but we haven’t shipped them. For example, we build all of Visual Studio with targets and tasks we have written to build C/C++ code, and targets we have written to traverse through a source tree. We just haven’t shipped those yet.

Put another way, we consider tasks (and matching tools they may launch) plus targets files to usually be associated together into a “toolset”. A toolset is typically specific to a runtime target, because many of the tools (like compilers) are designed to be specific to that target. The toolset we shipped in .NET 2.0 was specifically for targeting .NET 2.0. We will likely ship a similar toolset for targeting .NET 3.0, and so on. But the MSBuild “engine” is a platform agnostic of toolsets. Specifically,


-“Platform” or “Engine” shipped in .NET 2.0

Msbuild.exe, microsoft.build.engine.dll, microsoft.build.framework.dll


-“Toolset” or “Library” for targeting .NET 2.0

Microsoft.build.tasks.dll v2, microsoft.build.utilities.dll v2, microsoft.common.targets v2


-Toolset for targeting .NET 1.1

Implemented as the .NET 2.0 toolset, overlaid with tasks in MSBee.dll, and some msbee targets.

We’d like future msbuild platforms to be able to use arbitrary toolsets. So for example with MSBuild v3, you could build some parts of a tree for .NET 2.0 and some parts for .NET 3.0, and some parts as native code, and so on. In fact, we’re likely to formalize the concept of toolsets and make it easier to switch between them.

MSBee is an example of a “toolset” for targeting .NET 1.1. (As an implementation detail, it’s done by modifying the targets we shipped for .NET 2.0.). As I mentioned, you could equally have a toolset for native code, but we haven’t yet shipped one

PS One other reason why “make” can seem more agnostic about tools is that in makefiles, you can just insert calls to arbitrary executables. In MSBuild targets files, you either have to use the Exec task to do this, or create a wrapper task that exposes a pretty interface over the executable. In future versions, we would like to make creating wrapper tasks much easier.

Ø Is there a web site which gets into details about creating a build system with MSBuild which will work well with a large complex build tree on which targets various 'targets' throughout that tree?

Not that I know of yet, unfortunately. We hope to do a better job with that in the future. I’d especially like to let people know what we learned from converting the build of Visual Studio itself: and ship targets files just to traverse a tree. Right now we’re concentrating on features for the next version. Today, you can build .sln files that point to .csproj and .vbproj files in your tree. With a little work using the <MSBuild> task, you can create a simple targets file that would traverse your tree of .csproj and .vbproj, using, say, dirs.proj files listing child nodes at each node above the leaves.

Dan msbuild@microsoft.com

“This posting provided AS-IS, with no warranties”