João Matos a373c3d989 [build] Generated up-to-date net_4_x MSBuild projects. 10 лет назад
..
.gitattributes b293948fb7 EOL handling 15 лет назад
Makefile 56dc31d943 [msvc/scripts] Update order.xml file with Makefile changes, update generator 11 лет назад
README caa7615328 [genproj] Set the output directory to the Mono one, not an intermediary one 11 лет назад
TODO 38253abf8c Add solution files 15 лет назад
csproj.tmpl 26fa5fd9e8 [genproj] Do not define DEBUG in debug mode since it breaks reference sources. 10 лет назад
genproj.cs a8d6b4abff [genproj] Skip Facades, mcs and Microsoft.Web.Infrastructure. 10 лет назад
genproj.csproj f07d6c58bc [genproj] Some hygiene changes to genproj, to be able to even digest this 11 лет назад
mcs.pre 0dbf0040d6 Update to support the compiler buidl 16 лет назад
monowrap.cs 8e186eaaef rename net_2_1 to moonlight 16 лет назад
net_4_x.sln a373c3d989 [build] Generated up-to-date net_4_x MSBuild projects. 10 лет назад
order.xml a373c3d989 [build] Generated up-to-date net_4_x MSBuild projects. 10 лет назад
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 лет назад

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.

One output of genproj is the solutions for the successive profiles,
from net_2_0.sln to from net_4.5.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)