Alexander Köplinger fa1cb5bbf4 [msvc] Update order.xml and csproj files 10 years ago
..
.gitattributes b293948fb7 EOL handling 15 years ago
.gitignore b4a9c31f19 [csproj] Small fixes to the genproj readme 10 years ago
Makefile 56dc31d943 [msvc/scripts] Update order.xml file with Makefile changes, update generator 11 years ago
README b4a9c31f19 [csproj] Small fixes to the genproj readme 10 years ago
TODO 38253abf8c Add solution files 15 years ago
csproj.tmpl 26fa5fd9e8 [genproj] Do not define DEBUG in debug mode since it breaks reference sources. 10 years ago
genproj.cs a8d6b4abff [genproj] Skip Facades, mcs and Microsoft.Web.Infrastructure. 10 years ago
genproj.csproj f07d6c58bc [genproj] Some hygiene changes to genproj, to be able to even digest this 11 years ago
mcs.pre 0dbf0040d6 Update to support the compiler buidl 16 years ago
monowrap.cs 8e186eaaef rename net_2_1 to moonlight 16 years ago
net_4_x.sln bfa642cd73 [msvc] Update order.xml and csproj files 10 years ago
order.xml fa1cb5bbf4 [msvc] Update order.xml and csproj files 10 years ago
prepare.cs 2602bea504 Fix compiler build, make sure generated solutions include the actual HintPath so VS does not turn lib/basic/System.dll into GAC system.dll, so pass the entire relative path 16 years ago

README

README Last updated: 2013-01-09

Visual Studio Build Setup for Mono's Managed Code
=================================================

The scripts in this directory are used to create the various .csproj
for each one of the modules in Mono. To avoid accidentally making
changes on the Makefile system that is not reflected on the csproj
system, the .csproj files are generated from the actual Makefile
settings.

This requires a couple of steps:

* Extract the order, compiler and compilation flags for all
managed code in Mono on Linux by using the existing Makefile
system.

* Generate csproj files from the previous step

The idea is to ensure that we do not miss any compilation flag,
define, resource, reference, icon or any other element that might be
necessary to build the Mono class libraries.

* Extracting the Compilation Metadata

The first step is to extract the compilation metadata from the
existing Makefiles. This is done in stages, first a fully
working Mono compilation setup is required, and second the data
is extracted.

The extraction is done like this, from the toplevel Mono
directory run:

make update-csproj

With this input, it is possible to generate an XML file, to do
this do:

make package-inputs

This will generate order.xml, this contains the ordered list in
which directories must be compiled as well as the command line
options used to build it.

* Generate .csproj and .sln files

Run the genproj.exe executable in this directory.

On Windows:
cd msvc/scripts/
/cygdrive/c/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe genproj.csproj
./genproj.exe

On Mac:
cd msvc/scripts/
make genproj.exe
mono genproj.exe

One output of genproj is the solutions for the successive profiles,
like net_4_x.sln.

The command
./genproj.exe -h
lists a couple of options, notably to limit the scope of
the output solutions for each profiles to System*.dll assemblies
and dependencies.

* Compiling from Visual Studio

Before you try to compile from Visual Studio, you are *strongly*
advised to set the maximum number of parallel project builds
to 1 (Tools -> Options -> Projects and Solutions -> Build and Run)
Due to the iterative building process for some of Mono's
assemblies, there can be clashes writing to /obj/Debug for
some projects

* KNOWN ISSUES

* We are currently not running "sn" to sign the assemblies

* We do not have an "install" target, perhaps we should generate
this based on something similar to the update-csproj setup

* Audit: every Makefile for "local" changes, as those are not
visible to this tool.

* OLD KNOWN ISSUES

* Many assemblies still fail to compile, due to missing project
references output by genproj, or other issues yet to determine

* The first build of a solution may have a large number of
failing compilations, more than subsequent solution Builds

* The .NET 2.0 profile assemblies end up targetting the
v4.0 runtime, even when requesting 2.0 in the csproj file
(http://social.msdn.microsoft.com/Forums/en-US/msbuild/
thread/6c9cd0e1-7fb8-480a-b006-f034b5926e03)