[Mono-dev] Ideas for Mono on Windows

[Eyal Alaluf]

Hi, all.

I'd like to chip in our Grasshopper experience with Mono. We found it always extremely useful and productive to be able to build the Mono class libraries from Visual Studio (in the Grasshopper version).
To me it would seem that the 1.1 profile is much less important then 2.0 and above. Also I find that the class libraries have precedence over the runtime - so (for instance) any investment in Express C++ should come last. Also, when effort wil be invested in building without requiring cygwin installed - I would first do it for the class libraries and only afterwards the Mono runtime build.

Eyal.

-----Original Message-----
From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf Of Miguel de Icaza
Sent: Wednesday, December 10, 2008 2:44 AM
To: Atsushi Eno
Cc: mono-devel
Subject: Re: [Mono-dev] Ideas for Mono on Windows

Hello,

Let us please not use stop energy from preventing this incredibly
important project from moving ahead.

The Mono Build on Visual Studio will not be able to solve every problem
ever, but for that we already have the Cygwin fallback. 

This discussion is about how we can gradually improve things for
developers that are mostly used by Visual Studio developers:

> First of all I'm not aware of any of "concensus on #monodev". Actually
> I find almost no reason to use VS to build our classlibs. The classlib
> build is not much slower on cygwin. The remarkable difference would
> happen only on the runtime build.

This was a consensus reached by those of us that were present at the
time.   

The goal is to make it simpler for contributors that are interested in
Mono to contribute effectively.    The reality is that setting up cygwin
is a painful process, and it is not always reliable and requires
contributors to be familiar with the Unix toolchain.

The gist of the discussion in #monodev was to achieve the same level of
ease of use as Google Chrome has: they shipped with Visual Studio
solutions and you can go from source code checkout to running Chrome
following the following steps:

	* Open Solution File.
	* Hit F5

That is it.    A fully working Chrome pops up in your screen after
this. 

So the goal is to come to this exact point: having a fully working Mono,
have an option to run its test suites, build programs against this Mono
and so on from Visual Studio with a single keystroke without requiring
people to learn any Unixisms.

We need to get there one step at a time, baby steps.  First being able
to build a runtime and the class libraries, then we will do the full
profiles, then we can even think about integrating this with our Visual
Studio plugin and so on.

> VS integration has another problem. You cannot really expect VS non-
> express versions installed and then there is no way to run NUnit tests
> (no addins are allowed in Express versions). It can never be a first
> citizen build environment.

For the F5 experience people would need to have Visual Studio
Professional installed as this would build runtime, support libraries
and class libraries.

For express users we could probably partition the problem: runtime built
with Express C++ and class libraries with Express C#.

> As I stated earlier, I don't care much about it as long as cygwin build
> is kept though. The minor issue I am afraid is that those VS users are
> likely to ignore our Coding Guidelines.

They still need to get their patch reviewed, and we can publish a set of
configuration settings for Visual Studio that follow the Mono Coding
Guidelines.   

I know that this is possible for per-user settings, but I am not sure if
there is a way of distributing these. 

Miguel.

> 
> Atsushi Eno
> 
> Jonathan Chambers wrote:
> > Hello,
> > 
> >       I broke down the 'Mono on Windows' topic into two distinct 
> > approaches. I have mainly been working on the second approach as it 
> > seemed to be easier and provide more value.
> > 
> > The first approach is to provide a way to build mono on windows without 
> > cygwin installed. This approach provides uses no MS tools and provides 
> > no VS integration for the class libraries. The runtime would still be 
> > built with MSVC at this point in the plan. It's simply a way for Windows 
> > developers to quickly build mono on windows. It should be much faster 
> > than the current cygwin based build and require let setup.
> > 
> > The second approach (the one I have been working on) was to provide a 
> > 'prepare' tool to generate csproj files for all the class libs. I also 
> > generate a solution containing all the projects. The user can then build 
> > all the mono class libraries (and unit tests) with one click (it's also 
> > per profile 1.1, 2.0, 3.5).
> > 
> > So as for an update to the second approach. I have a rudimentary 
> > Makefile parser and am using it to generate csproj files for the class 
> > libraries. I have run into a few problems/issues:
> > 
> > 1. The conscensus on #monodev was that the build could use the MS 
> > compiler, but that we should reference mono class libraries as 
> > references. So, I build corlib first and then try and build the 
> > System.dll referencing our corlib rather than the MS one via -nostdlib 
> > compiler option (for the 1.1 profile). Visual Studio 2008 allows users 
> > to specify what framework version to target for a specific project, but 
> > 2.0 is the minimum version (2.0, 3.0, and 3.5 are the options). The csc 
> > compiler errors out when building System.dll as it is looking for 2.0 
> > specific items in corlib. The specific error is:
> > 
> > error CS0656: Missing compiler required member 
> > 'System.Threading.Thread.get_ManagedThreadId'
> > 
> > I hacked around this by making that field public when build inside of 
> > Visual Studio. However, that is a hack and some in #monodev seemed to 
> > indicate we'd hit more issues going down this path.
> > 
> > So, in short I think we may be stuck trying to build 1.1 profile 
> > libraries (referencing our 1.1 corlib) using the csc compiler.
> > 
> > I have a couple questions that hopefully I can get some responses on.
> > 
> > 1. What's the impact of building the 1.1 class libraries against the 2.0 
> > corlib?
> > 
> > 2. Should this approach (VS integration) be able to build a fully 
> > working mono image?
> > 
> > 3. If so, are we confident enough that contributors could use this build 
> > mechanism to make changes/patches? Or would this be viewed as a second 
> > class, and we would expect them to build on Linux or with cygwin before 
> > actually commiting changes?
> > 
> > 4. If we don't expect this approach to build a fully working mono image, 
> > what exactly is the goal/use case? Is it just so Windows hackers can 
> > quickly build a single class library in VS? They can debug a class 
> > library in VS?
> > 
> > I'm still hoping to make things better on Windows for mono, but am not 
> > sure which direction to go now. Any (potential) mono hackers on Windows 
> > please let your opinions be known.
> > 
> > Thanks,
> > Jonathan
> > 
> > On Fri, Nov 14, 2008 at 4:42 PM, Miguel de Icaza <miguel at novell.com 
> > <mailto:miguel at novell.com>> wrote:
> > 
> >     Hello,
> > 
> >      > The upside of the mechanism I am using is that all of that would
> >     still
> >      > work the same, because I am still using the .sources files instead of
> >      > having a .csproj.  The downside is we still wouldn't have
> >     .csproj's, so
> >      > it doesn't make working in VS any easier, it just makes it
> >     possible to
> >      > build Mono for Windows in under two hours.
> > 
> >     Thanks for this information.
> > 
> >     Is there a reason why we could not generate the .csproj files from
> >     the .sources and the Makefile settings for the entire tree in one
> >     "prepare" step?
> > 
> >     We need to have a good Visual Studio experience from the get-go and not
> >     only a faster command line buidl.
> > 
> >     Miguel
> > 
> >     _______________________________________________
> >     Mono-devel-list mailing list
> >     Mono-devel-list at lists.ximian.com
> >     <mailto:Mono-devel-list at lists.ximian.com>
> >     http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > 
> > 
> 

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list