[Mono-dev] Contributing to xbuild

Jean-Michel.Perraud at csiro.au Jean-Michel.Perraud at csiro.au
Thu Sep 19 23:15:31 UTC 2013

Hi Marcello,

I cannot provide knowledge on xbuld/msbuild as such but can give some background on the .csproj files.

I worked on the csproj file generation 1-2 years ago, and introduced the multiple csproj files with the profile as extension. The idea is to aim for solutions that should “just build” as they are under visual studio or monodevelop. Prior to that if my memory serves me right, the “build” process was generating successive versions of the framework libraries, and swapping libraries, and you’d need differing compilation flags and conditional cs file includes in csproj files etc. depending on the profile. Intellisense was going topsy-turvy, too. I reckon that multiple csproj is just plain simpler.

I mostly focussed on trying to get a working build process with VS of the System.*.dll libraries for .net 4.5; I could things to build OK though with a few passes. There is an unfortunate wart in the Microsoft compilation toolchain (admittedly would only ever show for one Mono assembly) to work around in profile 2.0.

Regarding specifically what you asked:

-          The availability of Microsoft.Build.Engine.csproj and xbuild.sln _may_ be a legacy (last commit from 2009); (Jonathan Chambers may want to comment on this)

-          I _think_ that in theory the Microsoft.Build.Engine-net_[2_0,3_5,4_0,4_5]. should reflect the conditional include in the legacy project, and be more up to date regarding the content.

-          I noticed that MonoDevelop does not support conditional file includes in projects, and there are indeed some in of Microsoft.Build.Engine.csproj

Hope this helps; I’d like to contribute more but like you, have limited “spare” time. I’d aim to document things better if anything.


From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Marcelo Zabani
Sent: Friday, 20 September 2013 12:01 AM
To: Alan
Cc: mono-devel
Subject: Re: [Mono-dev] Contributing to xbuild

Sorry to bring this thread up after so much time, but I haven't had too much time on my hands lately. I've been trying to understand XBuild's and Microsoft.Build.Engine's code in Mono to be able to contribute (even if just a little bit) but I'm having a hard time understanding what is going on. First, I had to do some "trickery" to get xbuild to build inside Monodevelop. More specifically, I tried opening /mcs/tools/xbuild/xbuild.sln with Monodevelop and build, but before I was able to do that, I had to do the following:

Include some files in /mcs/class/Microsoft.Build.Engine/Microsoft.Build.Engine.csproj. The files below were already included in Microsoft.Build.Engine-net_[2_0,3_5,4_0,4_5].csproj:
    <Compile Include="Microsoft.Build.BuildEngine\IBuildTask.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\ToolsetCollection.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\ToolsetDefinitionLocations.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\Toolset.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\ProjectLoadSettings.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\ExpressionEvaluationException.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\LogExtensions.cs" />
    <Compile Include="..\Microsoft.Build.Utilities\Mono.XBuild.Utilities\MSBuildUtils.cs" />
    <Compile Include="Microsoft.Build.BuildEngine\UnknownToolsVersionException.cs" />
    <Compile Include="..\..\tools\xbuild\SolutionParser.cs" />

  *   This didn't scare me too much, since I think what actually gets build are the versioned framework files (2_0, 3_5 and so on), but then why have a Microsoft.Build.Engine.csproj?
  *   What I really didn't understand is that I had to change the visibility of UnknownToolsVersionException and some more types from internal to public, since xbuild depends on these (and UnknownToolsVersionException is in the Microsoft.Build.Engine library). This led me to the conclusion that I really don't understand xbuild's build process, since of course when I build Mono it gets built successfully.
  *   When looking at the project files, I coul see some files were included on a per Configuration basis, but MonoDevelop showed them all in the tree view no matter what configuration I chose in the IDE. Is this intended behavior?

Sorry for the long email, and thanks in advance.

On Thu, Sep 5, 2013 at 12:13 AM, Alan <alan.mcgovern at gmail.com<mailto:alan.mcgovern at gmail.com>> wrote:

The correct thing to do is probably to build the entire mono class libraries first using the normal procedure for building mono on your OS. Once that's done you should not need to modify assembly references in the csproj files. You may need to add missing cs files to the csproj though.

I'm looking forward to your contributions!


Marcelo Zabani
(19) 9341-0221
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20130919/9f581293/attachment-0001.html>

More information about the Mono-devel-list mailing list