[Mono-dev] Ideas for Mono on Windows

Atsushi Eno atsushi at ximian.com
Tue Dec 9 19:14:57 EST 2008


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.

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.

Also note that we cannot bring VS apporach to our automated build unless
we get working xbuild.

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.

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

More information about the Mono-devel-list mailing list