[Mono-dev] Ideas for Mono on Windows

[Daniel Morgan]

I think building Mono with Visual Studio is good for several reasons - debugger is awesome, mono.exe should run faster built with visual c++ instead of gcc, and easier to edit files.

As for coding guidelines using visual studio text editor, it is not easy because it autoformats C#.  Even when you tweak the settings to be like mono's coding guidelines, they still are not correct.  So, you end up having to manually go back and fixup the problems.

As for the 1.1 profile, those building mono using visual studio will not interested in the 1.1 profile anyways - they want to see the "cool" new stuff.



--- On Tue, 12/9/08, Jonathan Chambers <joncham at gmail.com> wrote:

> From: Jonathan Chambers <joncham at gmail.com>
> Subject: Re: [Mono-dev] Ideas for Mono on Windows
> To: "Miguel de Icaza" <miguel at novell.com>
> Cc: "Atsushi Eno" <atsushi at ximian.com>, "mono-devel" <mono-devel-list at lists.ximian.com>
> Date: Tuesday, December 9, 2008, 2:41 PM
> 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> 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
> >
> 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