Moving to MSBuild

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.

_______________________________________________
Monodevelop-list mailing list
Monodevelop-listlists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-li
st

Moving to MSBuild

Thread: Moving to MSBuild