[MonoDevelop] Moving to MSBuild

[Lluis Sanchez]

Hi!

Some people asked me to comment on the move to MSBuild that I mentioned
in my blog.

So, what does it mean moving to MSBuild? it can mean several things:

     1. Use the MSBuild file format, instead of our current .mds
        and .mdp format.
     2. Use MSBuild as build engine, instead of our
        IDotNetLanguageBinding implementations.
     3. Use MSBuild as project object model for MD, instead of our
        Combine/Project classes.

Our plan is to do 1), do 2) at mid term, and we don't have plans to do
3).

Using MSBuild as file format (1) won't be hard. We already have a
MSBuild file reader/writer in our VS add-in. However, we'll have to do
some changes in the object model to better support the MSBuild format.
One of the changes is removing support for nested solutions, which will
be replaced by solution folders (in case you want to organize projects
inside a solution) and by workspaces (which will allow grouping several
solutions together). In any case, there won't be radical changes in the
public frontend API. If you want to write an add-in which gets
information from a project, such as files or references, or adds custom
data to projects, etc, that won't change much.

To use MSBuild as build engine for MD (2) we need a complete MSBuild
implementation, or at least one that is good enough for MD. XBuild
(Mono's MSBuild implementation) can build simple projects, but there is
still important work to do to make it fully usable in MD. Using MSBuild
as build engine will require important changes in the backend, so if you
are writing an add-in for supporting a new language, you'll face more
important changes. Maybe you are wondering if extensions to the build
engine will have to be written as MSBuild extensions or MonoDevelop
extensions. The answer is that it depends on what the extension is for.
If the extension is to be run only inside the IDE, you'll be able to use
the existing extension points (for example, that's what the Stetic
designer will use to hook up the gui code generation). If you want to
change the build behavior and make sure it works even when building the
project from outside the IDE, you'll have to use MSBuild extensions.

We are not considering the use of the MSBuild object model as project
object model for MonoDevelop (3) because it is too complex to use. We
need a more higher level, more generic and more simple API, which
supports MSBuild as backend, but can also support other build engines
and file formats, just like our current project model does.

My plan for the move to MSBuild is the following:

      * Do the necessary changes in the project class hierarchy to
        better fit the MSBuild project model.
      * Implement the new project reader/writer (or reuse the one we
        have in the VS add-in).

After those changes we'll be able to use msbuild as default file format,
although projects will still be built using our custom language binding
backend. This will be ready for the next major post-1.0 MD release.

The next steps would be:

      * Implement the missing bits in xbuild.
      * Change the MD's build engine, so it builds projects using xbuild
        instead of the custom language binding extensions.

I'm not sure when we'll be able to do this change, since it will depend
on how mature xbuild is. We'll also have to take into consideration the
MonoDevelop dependencies. The xbuild funcionality is implemented in
Microsoft.Build.* namespaces, which are provided by Mono. We can
implement the missing MSBuild features until it is good enough for MD,
but it means that MD will depend on bleeding edge Mono releases, and
that may be a problem in some distros.

So, that's it.

Lluis.