[Mono-dev] Ideas for Mono on Windows
Hello, I'm writing a .NET application that uses Spring.NET and NHibernate, my development tool is VS 2008 standard (I've also tried MonoDevelop, but it is a bit far from VS for now). My final goal is to create an application that runs without (major) changes on Win/.NET and Linux/Mono, I strongly believe in this fantastic project (Mono) and in free OSes. In my intentions the (cyclic) dev process will be: 1. develop on Win/VS 2. quick test on Win/.NET and Win/Mono for architecture validation 3. unit test on Win/.NET and Linux/Mono Unfortunately, I'me blocked on stage 2. because of a bug in Mono that prevents Spring XmlApplicationContext from initializing correctly by assembly embedded resources. This bug has been resolved a few days ago (http://lists.ximian.com/pipermail/mono-bugs/2009-January/084625.html). I could grab a snapshot of source code and build it by myself, but I haven't time for setting up the needed environment and build Mono, I have to go on quickly on my project. Sadly, I have to wait for the next Windows/Linux build to go ahead on step 2. If I had a simple way to build Mono on Windows, the (in)famous F5, I could go on peacefully. Despite this hassle, I think Mono is a great work and I hope It will play an important role in my future. Thanks to all! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hi, SuperCiccio wrote: Sadly, I have to wait for the next Windows/Linux build to go ahead on step 2. If I had a simple way to build Mono on Windows, the (in)famous F5, I could go on peacefully. I don't mind running the code if you need a hand (using Fedora rawhide). My box is updated from svn roughly every day... TTFN Paul -- View this message in context: http://www.nabble.com/Ideas-for-Mono-on-Windows-tp21622111p21622154.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
On Fri, Jan 23, 2009 at 11:40 AM, PFJ pjohns...@uclan.ac.uk wrote: Hi, SuperCiccio wrote: Sadly, I have to wait for the next Windows/Linux build to go ahead on step 2. If I had a simple way to build Mono on Windows, the (in)famous F5, I could go on peacefully. I don't mind running the code if you need a hand (using Fedora rawhide). My box is updated from svn roughly every day... TTFN Paul -- So how's the progress with getting Mono easy to compile on Windows going? I'm getting stuck on exception that's been already mentioned on the list ( http://n2.nabble.com/Re:-Mono-devel-list-Digest,-Vol-44,-Issue-48-td1757065.html ) and can't find any solution for this. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Ideas for Mono on Windows
Paul, thanks for your helpfulness. At present time it is non so simple, for various reasons: - I need testing almost continuously, in this initial phase; - there are no deployment/setup procedures so it takes a bit porting the application on other machines: for me it is very simple to access the same resources (database, files, etc..) on the same configuration with .NET and Mono Anyway, I've appreciated your offer. It would be a great help for me if you had a procedure for setting up and mantaining an up-to-date Fedora/Mono system. Regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
You can try to use Mono's VM image which is an tailored-OpenSUSE, upgrading it to newer mono releases or using it to build and run mono from svn trunk is far easier than building mono in windows. It also may help you find real portability issues, like what happens when the linux user doesn't have the fonts you use in your WinForms, or file access issues.. Hope it helps, On Fri, Jan 23, 2009 at 9:52 AM, SuperCiccio sc_030...@yahoo.it wrote: Paul, thanks for your helpfulness. At present time it is non so simple, for various reasons: - I need testing almost continuously, in this initial phase; - there are no deployment/setup procedures so it takes a bit porting the application on other machines: for me it is very simple to access the same resources (database, files, etc..) on the same configuration with .NET and Mono Anyway, I've appreciated your offer. It would be a great help for me if you had a procedure for setting up and mantaining an up-to-date Fedora/Mono system. Regards ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Rafael Monoman Teixeira --- I myself am made entirely of flaws, stitched together with good intentions. Augusten Burroughs ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
It's not ideal, but you can grab daily precompiled assemblies from here: http://mono.ximian.com/daily/ , and place them in your Mono's GAC: C:\Program Files\Mono-2.2\lib\mono\gac. (Or use Mono's gacutil to register them.) Jonathan SuperCiccio wrote: Hello, I'm writing a .NET application that uses Spring.NET and NHibernate, my development tool is VS 2008 standard (I've also tried MonoDevelop, but it is a bit far from VS for now). My final goal is to create an application that runs without (major) changes on Win/.NET and Linux/Mono, I strongly believe in this fantastic project (Mono) and in free OSes. In my intentions the (cyclic) dev process will be: 1. develop on Win/VS 2. quick test on Win/.NET and Win/Mono for architecture validation 3. unit test on Win/.NET and Linux/Mono Unfortunately, I'me blocked on stage 2. because of a bug in Mono that prevents Spring XmlApplicationContext from initializing correctly by assembly embedded resources. This bug has been resolved a few days ago (http://lists.ximian.com/pipermail/mono-bugs/2009-January/084625.html). I could grab a snapshot of source code and build it by myself, but I haven't time for setting up the needed environment and build Mono, I have to go on quickly on my project. Sadly, I have to wait for the next Windows/Linux build to go ahead on step 2. If I had a simple way to build Mono on Windows, the (in)famous F5, I could go on peacefully. Despite this hassle, I think Mono is a great work and I hope It will play an important role in my future. Thanks to all! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
- Original Message - From: Rafael Teixeira To: SuperCiccio Cc: mono-devel-list@lists.ximian.com Sent: Friday, January 23, 2009 10:43 PM Subject: Re: [Mono-dev] Ideas for Mono on Windows You can try to use Mono's VM image which is an tailored-OpenSUSE, upgrading it to newer mono releases or using it to build and run mono from svn trunk is far easier than building mono in windows. It also may help you find real portability issues, like what happens when the linux user doesn't have the fonts you use in your WinForms, or file access issues.. IMO, a major source of the building issue is likely the GLib dependency (or, at least, a kind of GLib-dummy can be provided). if one can eliminate most of the dependency on libraries and tools which don't work well, or are not present, in a typical Windows environment, it should build easier. for example, trying to get it to build in my case, required going and getting bison, and then trying to get this to build, but then having to go and tweak this as well to make it build (due to Windows not having API calls like 'fork()', ...). but, in my case, none of this looks good to me, as I have a policy of doing more or less self-contained (and modular) code, such as that apart from areas defined to have a dependency (usually as a basic part of their operation), there are not dependencies. even then, dependencies are often wrapped such that things can be re-routed if needed, ... IMO, it makes the code cleaner, easier to maintain, and easier to port (ok, yes, it is sad that much of my current project has dependencies on the x86 and x86-64 instruction sets... but it is not so easy to abstract automated code generation from the particular arch...). (and also, my effort is much easier to build on Windows, as I code mostly for Windows...). but, alas, my effort continues, although granted being able to JIT higher-level bytecode formats is posing many subtle difficulties. a recent example is that, both JBC and CIL are different enough from the way my existing approach works (and is backwards of the typical C-order on x86 and x86-64, ...), that I considered things and made a decision to go over to a custom calling convention for these cases. this calling convention differs in some fairly major ways from cdecl and sysv and similar, primarily in that it uses an explicit frame structure and is based around CPS (the CPU stack then is used primarily for calculations and for native calls). however, I am mildly worried about the performance (for code with large numbers of small functions, the performance is not likely to be good). at least on the upside, the convention itself is only trivially different between x86 and x86-64 (the main difference being whether to use EAX or RAX, ...). but, alas, I am not sure if Mono went and also paid the costs of using frames, ... or if it managed to keep all this stuff strictly on the CPU stack. BTW, for my uses, I have also gone and come up with an alternative representation for the metadata (apparently the need for metadata being an almost inescapable issue). my representation differs somewhat from that used in CIL, namely that as opposed to using tag-indices and tables, I am using a pointer-and-value compression scheme (mostly differential pointers and VLC). I had realized that using raw pointers, ... the space overhead of metadata would likely be huge, ... but tables require keeping track of the table structure, which would be a big hassle and probably a performance cost, so the idea then was to instead use a special coding scheme to allow the pointers to be compressed while still keeping their independence... in general though, these pointers are not visible to the linker (note, all this is at the ASM/machine-code level), so any external pointers are typically stored in a special metadata entry, which holds linker-visible (AKA conventional) pointers (these would be pointers into code or data, or other chunks of metadata). but, it does save from me having to make my linker aware of these oddities (actually, I am not even sure if it would be practical/possible to link this kind of pointer-compressed data, as trying to do so is likely to involve having to restructure the whole thing...). note that the metadata is still byte-structured (no LZ or Huffman, ...) and so it is still possible for machine code to hold pointers into the metadata (likewise, the representation can be easily decoded in place, .. at the cost of some loss of compression ability). (none the less, a field definition could be concievably stored in 5-7 bytes, as opposed to 20 or 32 on x86 or x86-64). note that it will not likely be a 1:1 transcription of CIL metadata, but is actually likely to be built by the JIT compiler (which may have in turn have gained its information from CIL, or also from '.class' files, ..). technically, it is structurally closer to the contents of '.class
Re: [Mono-dev] Ideas for Mono on Windows
Not sure nobody will be interested in 1.1. We are! :-) Daniel Morgan escribió: 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 [EMAIL PROTECTED] wrote: From: Jonathan Chambers [EMAIL PROTECTED] Subject: Re: [Mono-dev] Ideas for Mono on Windows To: Miguel de Icaza [EMAIL PROTECTED] Cc: Atsushi Eno [EMAIL PROTECTED], mono-devel mono-devel-list@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 [EMAIL PROTECTED] 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
Re: [Mono-dev] Ideas for Mono on Windows
Hello, 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. Yes, it's available in VS2008 under Tools-Import and Export Settings. Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
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 [EMAIL PROTECTED] wrote: From: Jonathan Chambers [EMAIL PROTECTED] Subject: Re: [Mono-dev] Ideas for Mono on Windows To: Miguel de Icaza [EMAIL PROTECTED] Cc: Atsushi Eno [EMAIL PROTECTED], mono-devel mono-devel-list@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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
On Wed, Dec 10, 2008 at 1:14 AM, Atsushi Eno [EMAIL PROTECTED] wrote: 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. It is possible with a bit of a hack (no violating-licence-to-install-plugins, as some projects did earlier). One needs to add a StartAction and StartProgram to the .csproj (details: http://skolima.jogger.pl/2007/07/02/debugging-nunit-tests-in-visual-studio-2005-express/ ). I have used this for over two years (VS 2005 Express and VS 2008 Express), before my employer finally bought VS Standard. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hey Jonathan, My interest is mainly the first approach, but building class libraries is an important part of either approach, so thank you for your effort on this. :) I would say especially for your use case, we probably don't need to worry about the 1.1 profile currently. All contributing is probably going to happen in the 2.0+ profile, given how complete and obsolete 1.1 is. The only concern then is libraries that we only ship runtime 1.1 versions of. Mono.Cecil.dll had been mentioned as one of these. We probably need to come up with the list of assemblies that this includes. Most, if not all, would probably be fine if they were compiled against 2.0 for users' local testing. Obviously, there are other factors in play such as correctness and cross-platformness, but I don't see any reason why users' patches wouldn't be accepted if they were written on Windows. jpobst 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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
Re: [Mono-dev] Ideas for Mono on Windows
Hello, 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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hello, I think it would help to keep in mind what the objective is for the second approach: to make Mono easier to hack on for Windows developers and to encourage contributions. We agreed on the second approach (Hit F5 in Visual Studio, get a fully built Mono): 1. What's the impact of building the 1.1 class libraries against the 2.0 corlib? I am wondering if there is a lot of value in building the 1.0 and 2.0 profiles of Mono with Visual Studio. The 1.0 profile so far has limited uses: bootstrapping and embedded scenarios, they are both valuable, but they probably should not be mandatory for the F5 experience which is to say: how do we enable more developers on Windows to easily hack on Mono. The multi-stage build process from Mono (where we build mscorlib a number of times) might not be necessary to achieve this goal, I would postpone this for now and not bother too much with this. I saw the discussion about some of our libraries that we still compile against the 1.0 profile. I think that we can do two things here: * We could build policy files that remap 2.0 to the 1.0 assemblies on Linux so that executables built on Windows using these 2.0-based applications continue to work. * Alternatively, have a new stage that redirects the code to a 1.0 profile API to ensure full compatibility (this is what JB suggested online). 2. Should this approach (VS integration) be able to build a fully working mono image? In order of priority I think we want: * Ease of use for developers to get started with Mono hacking. * Ease for users to get a version of Mono, and build a version from SVN that they can use. * Eventually be able to produce a fully compatible Mono from Visual Studio with a single command. I believe that we can achieve the last point with some custom tools in the future, using a last stage pass that uses our runtime and a monolite component. I say a last stage merely because I think that we should postpone a full build of Mono that includes the 1.0 profile from Visual Studio if this is too difficult. 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? I do not anticipate to find too many problems with the partial approach (where the 2.0 is the only platform tested). There certainly will be some, but those problems even happen today with people using Linux or Cygwin. If it becomes too much of a problem, we can revisit at that point the setup and augment it. Miguel. 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 [EMAIL PROTECTED] 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
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
Re: [Mono-dev] Ideas for Mono on Windows
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
Re: [Mono-dev] Ideas for Mono on Windows
As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. I agree;Point (2) is probably one of the most important thing that we can do and we are missing important contributions by making it hard for the Windows developer community to work with Mono. I would like to follow on Google's footsteps here and make sure that the Mono development experience is Check out the source, open the solution, hit F5 and you are done. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. I like this plan. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. I am fine with either solution myself. I do like the idea of reusing msbuild and completing the implementation of xbuild myself, although we have dropped the ball on xbuild numerous times. Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
There is no need for .dll.sources for (ms|x)build - use wildcards: ItemGroup Compile Include=../../build/common/*.cs / Compile Include=**/*.cs / /ItemGroup gmcs is self-hosting compiler so there is no obstacles to have unified self-hosting build engine like xbuild for entire project. The only problem is developers that like spend time in command line insted of developing/debugging. -- View this message in context: http://www.nabble.com/Ideas-for-Mono-on-Windows-tp20449573p20512725.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Atsushi Eno wrote: Classlib hackers who uses Visual Studio: how do you do those tasks? I'm no classlib hacker, but do use Visual Studio for my game project that is running ontop of mono. We currently use scons as our build software, and have visualstudiosolution as a seperate target. the scons script will basically scan trough my project's filesystem in a way I have told it to, and look for all .cs files. It then creates .csproj's for each assembly, and a .sln file containing all those projects. Creating those files is as simple as taking a template .csproj file prepared by me, and adding a line for each .cs file. When you do an svn-update you just have to regenerate your visualstudio solution, which takes about a second. When you add new files yourself trough visual studio, you don't need to do anything. I might not have a helicopter view of the problems with building mono, but at least this works great for our project. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
On 11/11/08 Jonathan Chambers wrote: 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. So this is already done by you, AFAIK. I even add new .c files to the MSVC build files (when I remember about it:). it). Another option is to moved to MSBuild/xbuild for the class libraries. I think you're taking it from the wrong side. There is no need to move the Linux build system to xbuild or whatever. As other have mentioned, the build files can be generated from the .sources files quite easily. You can write the conversion script in perl or even C# and we can have rules in the makefiles to run them automatically when the source files are modified. AFAIK, the only two things missing are: 1) a windows developer that volunteers writing the script and MSBuild/xbuild files. 2) a windows developer that documents the thing for other windows developers so they are not tricked into going down the cygwin route anymore and just click on the right buttons instead. As you see we only need some windows developer to step up to the plate. I suggest starting to build the complete assemblies first, without going into the details of bootstrapping. This should take an hour or two. And then we (mostly hari I guess) can help with the bootstrap details. So, who volunteers? lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Paolo, Thanks for the response. On Thu, Nov 13, 2008 at 9:01 AM, Paolo Molaro [EMAIL PROTECTED] wrote: On 11/11/08 Jonathan Chambers wrote: 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. So this is already done by you, AFAIK. I even add new .c files to the MSVC build files (when I remember about it:). it). Another option is to moved to MSBuild/xbuild for the class libraries. I think you're taking it from the wrong side. There is no need to move the Linux build system to xbuild or whatever. As other have mentioned, the build files can be generated from the .sources files quite easily. You can write the conversion script in perl or even C# and we can have rules in the makefiles to run them automatically when the source files are modified. AFAIK, the only two things missing are: 1) a windows developer that volunteers writing the script and MSBuild/xbuild files. I have started writing this tool in C#. It correctly generates a csproj file from the Makefile and the library.dll.sources files. It already works on most assemblies in mcs/class. I'm working on generating the corresponding NUnit projects as well.I'll hopefully post something in a couple of days. 2) a windows developer that documents the thing for other windows developers so they are not tricked into going down the cygwin route anymore and just click on the right buttons instead. I can also look into this once a full build is working. Not to mention the fact the xbuild needs a good bit of work. As you see we only need some windows developer to step up to the plate. I suggest starting to build the complete assemblies first, without going into the details of bootstrapping. This should take an hour or two. And then we (mostly hari I guess) can help with the bootstrap details. So, who volunteers? I would appreciate any help offered by others ;-). Hacking on xbuild (including contributing tests) would be expecially useful... Thanks, Jonathan lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
On 11/13/08 Jonathan Chambers wrote: I have started writing this tool in C#. It correctly generates a csproj file from the Makefile and the library.dll.sources files. It already works on most assemblies in mcs/class. I'm working on generating the corresponding NUnit projects as well.I'll hopefully post something in a couple of days. Excellent news! IMHO, the sooner you commit your script, the sooner other windows developers can help improving it. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
This is awesome news. However, this doesn't change the fact that a Windows developer will have to remember to change the makefiles if she contributes a patch with files included/removed (and a Win developer usually doesn't know how to do this as well). But if you write your tool to be able to do the opposite thing as well, you could just call it in the MSbuild files in order to change them as a part of the build, right? If this can be done, even the non-Windows developers that aren't used to AutoTools will benefit from it when xbuild is finished. Andrés Jonathan Chambers wrote: Paolo, Thanks for the response. On Thu, Nov 13, 2008 at 9:01 AM, Paolo Molaro [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On 11/11/08 Jonathan Chambers wrote: 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. So this is already done by you, AFAIK. I even add new .c files to the MSVC build files (when I remember about it:). it). Another option is to moved to MSBuild/xbuild for the class libraries. I think you're taking it from the wrong side. There is no need to move the Linux build system to xbuild or whatever. As other have mentioned, the build files can be generated from the .sources files quite easily. You can write the conversion script in perl or even C# and we can have rules in the makefiles to run them automatically when the source files are modified. AFAIK, the only two things missing are: 1) a windows developer that volunteers writing the script and MSBuild/xbuild files. I have started writing this tool in C#. It correctly generates a csproj file from the Makefile and the library.dll.sources files. It already works on most assemblies in mcs/class. I'm working on generating the corresponding NUnit projects as well.I'll hopefully post something in a couple of days. 2) a windows developer that documents the thing for other windows developers so they are not tricked into going down the cygwin route anymore and just click on the right buttons instead. I can also look into this once a full build is working. Not to mention the fact the xbuild needs a good bit of work. As you see we only need some windows developer to step up to the plate. I suggest starting to build the complete assemblies first, without going into the details of bootstrapping. This should take an hour or two. And then we (mostly hari I guess) can help with the bootstrap details. So, who volunteers? I would appreciate any help offered by others ;-). Hacking on xbuild (including contributing tests) would be expecially useful... Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
El dc 12 de 11 de 2008 a les 10:43 +0100, en/na Rolf Bjarne Kvinge va escriure: Hi, As one of the true maintainers of classlibs I'm completely against ideas to drop cygwin support as it completely destroys my hacking life (note that I don't mean I dislike adding VS build support), but anyways here I agree with jpobst on the part to keep using dll.sources. Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? In MWF land there's a sources-csproj converter. In vbnc land there's a vbproj-sources converter. I guess it depends on whoever is maintaining the code. IMHO as a starter it would be nice to have csproj's for all classlibs in svn, generated automatically in the makefiles (they way it's done in MWF), especially now that MD doesn't seem to be able to open the Makefiles anymore I'm not aware of any problem opening Mono's Makefiles. (this isn't only for VS people, it would be useful for MD people too). Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Atsushi Eno wrote: Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? 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. Classlib hackers who uses Visual Studio: how do you do those tasks? I manually add new classes to the project in VS. Before I commit, I manually add those classes to the .sources file. I then write my ChangeLog by hand. I then commit using TortoiseSVN, where I just click the files I want to commit, and TortoiseSVN handles doing adds or commits or whatever. In MWF, there is script that builds the .csproj from the .sources file, however it is written in bash, so it isn't usable on Windows without cygwin/bash. Therefore, I just manually maintain my own .csproj. This works for MWF because it is very rare at this point to add any new classes. For other projects, that may not be true. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
2008/11/11 Jonathan Chambers [EMAIL PROTECTED]: 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. Have you thought about using a gcc-to-cygwin cross compiler running on Linux? I do that with some of my projects, and it's a whole lot faster. I'd never want to go back to building on pure cygwin. (Side note: we even build our Delphi applications that way at work, because it turns out the command-line Delphi compiler runs fine under Wine... more than twice as fast as under Windows XP.) gdb on Windows is a total disaster, though. Not that it's much better on Linux. You may want to do what we do at work, and use a Linux-based cross compiler for your autobuilder/releases, and MSVC for active development and debugging. Have fun, Avery ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Because of notorious problems (and slowness) of cygwin, I have followed the same path that Daniel Morgan has (only stable Mono on Windows, hacking goes on Linux). An msbuild/xbuild solution for whole Mono sounds great. First - because of eased debugging with Microsoft tools and much faster builds. Second - because this might mean that xbuild finally matures to be a more usable tool. Regards, Leszek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hi, As one of the true maintainers of classlibs I'm completely against ideas to drop cygwin support as it completely destroys my hacking life (note that I don't mean I dislike adding VS build support), but anyways here I agree with jpobst on the part to keep using dll.sources. Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? In MWF land there's a sources-csproj converter. In vbnc land there's a vbproj-sources converter. I guess it depends on whoever is maintaining the code. IMHO as a starter it would be nice to have csproj's for all classlibs in svn, generated automatically in the makefiles (they way it's done in MWF), especially now that MD doesn't seem to be able to open the Makefiles anymore (this isn't only for VS people, it would be useful for MD people too). Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Daniel Morgan wrote: Where is this sources-csproj converter and how do you setup and use it? It is part of the normal mcs checkout. Go to mcs/class/Managed.Windows.Forms, and run build-csproj2k5. Note that it is all hardcoded to build the MWF csproj. It is not a general .sources - .csproj converter. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Considering that a visual studio solution/project files are in xml, could there be some configure macros created to autogenerate these solution/project files? Automake takes a Makefile.am file as input and spits out a Makefile file. I wonder how other free software project deal with a hybrid build system of gnu autotools/make/gcc on free software operating systems vs. visual c++ on windows. To answer Eno's question for mono classlib development, I use Visual Studio for: 1. creating tests to make sure they work on .net first 2. text editor 3. manually create solution/project to step debug a problem In rare circumstances to debug a problem, I have manually created a solution and project for each assembly I needed to create and manually add files to each project. Such as, to debug something in SybaseClient, I needed System.Data, Mono.Data.Tds, etc. I had to modify certain source files to set various defines, such as, NET_2_0. However, the text editor is problematic because you cannot get the formatting to be exactly like the mono style guidelines. I'm not brave enough to build mono using Visual Studio. It would be truly awesome if we could get the entire unmanaged and managed parts building on Visual Studio. Of course, the Visual Studio solution and project files would be autogenerated via configure. --- On Wed, 11/12/08, Atsushi Eno [EMAIL PROTECTED] wrote: From: Atsushi Eno [EMAIL PROTECTED] Subject: Re: [Mono-dev] Ideas for Mono on Windows To: Cc: mono-devel mono-devel-list@lists.ximian.com Date: Wednesday, November 12, 2008, 12:36 AM As one of the true maintainers of classlibs I'm completely against ideas to drop cygwin support as it completely destroys my hacking life (note that I don't mean I dislike adding VS build support), but anyways here I agree with jpobst on the part to keep using dll.sources. ... Classlib hackers who uses Visual Studio: how do you do those tasks? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Avery Pennarun wrote: Have you thought about using a gcc-to-cygwin cross compiler running on Linux? I do that with some of my projects, and it's a whole lot faster. I'd never want to go back to building on pure cygwin. We do have cross-compiling: http://www.mono-project.com/Compiling_Mono#Cross-compiling_on_Linux_using_MinGW But if we have things setup to run without cygwin/make on Windows, we can probably do a full compile in the same amount of time on Windows without having to have a second machine or VM to do it. Chambers is quoting 30-120 seconds for the unmanaged part. Based on my work, I would guess about 4-5 minutes for the managed part, significantly less if parallelized. The linux buildbots are currently taking about 25-30 minutes to build. I don't know why that is, they used to take around 7-8 minutes to build. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Ideas for Mono on Windows
Hello All, Mono on Windows has never been easy. However, lately things to have continually gotten worse (or I and others have just gotten more annoyed). Setting up an environment takes a lot of effort for a normal windows developer. Cygwin and the whole Makefile based process is very foreign for Windows developers. Not to mention the busted make in cygwin and cygwin issues on Vista (amd64). Most people have had enough interest in building mono on windows that they took the time to work things out (usually at least a day). But that's just the first time; try setting everything up again on a different machine or updating your cygwin and things start over. I see the basic issues as: 1) Cygwin development environment is less than ideal. It's foreign to most Windows developers and is a barrier to entry for most people. 2) Debugging is mostly impossible. gdb seems to provide little help on Windows (echoed by others on #monodev) 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. Simply opening a csproj file for a class library, hacking on it, testing under .Net and mono, and then contributing the changes seems a like a good goal to aim for in regards to contributors. The build/packaging guys can respond with what they are looking for on Windows. Any thoughts/responses on making mono better on Windows is appreciated. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Jonathan, I year ya! I stopped hacking on mono on windows. I only run released versions of mono on windows via Novell's windows installer. As for hacking on mono, I've been using the mono / open suse vm ever since. At first, you could create a branch in svn which would be a place to start so others could participate in hammering mono on windows into shape. Then when it stabilizes, merge into svn trunk. A Windows Installer designed to install Cygwin, gtk+ and dependencies, and whatever else necessary to build mono on windows out-of-the-box. I believe Paco may have tried to create something like this, but it was the size of a CD to download. If you look at other free software projects, they use gcc on Linux but they use Visual C++ on Windows, ie. OpenOffice.org and Mozilla. So, it makes sense that we do the same. Anyways, I like your idea Jonathan. I believe Miguel and others are open to the idea too. It just requires someone to get it started. --- On Tue, 11/11/08, Jonathan Chambers [EMAIL PROTECTED] wrote: From: Jonathan Chambers [EMAIL PROTECTED] Subject: [Mono-dev] Ideas for Mono on Windows To: mono-devel mono-devel-list@lists.ximian.com Date: Tuesday, November 11, 2008, 5:10 PM Hello All, Mono on Windows has never been easy. However, lately things to have continually gotten worse (or I and others have just gotten more annoyed). Setting up an environment takes a lot of effort for a normal windows developer. Cygwin and the whole Makefile based process is very foreign for Windows developers. Not to mention the busted make in cygwin and cygwin issues on Vista (amd64). Most people have had enough interest in building mono on windows that they took the time to work things out (usually at least a day). But that's just the first time; try setting everything up again on a different machine or updating your cygwin and things start over. I see the basic issues as: 1) Cygwin development environment is less than ideal. It's foreign to most Windows developers and is a barrier to entry for most people. 2) Debugging is mostly impossible. gdb seems to provide little help on Windows (echoed by others on #monodev) 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. Simply opening a csproj file for a class library, hacking on it, testing under .Net and mono, and then contributing the changes seems a like a good goal to aim for in regards to contributors. The build/packaging guys can respond with what they are looking for on Windows. Any thoughts/responses on making mono better on Windows is appreciated. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
Hey Jonathan, I'm glad to hear that you have the runtime building nicely on Windows. In my spare time, I have been playing with making an MSBuild script for the managed pieces, and was hoping you might have something similar for the unmanaged part. (Which I know nothing about.) The route I took (and this is my first time playing with MSBuild) was to write an McsTask that simply calls (g)mcs with the same command line as the make system. In this way, I simply use the existing .sources files. This may be an easier scenario to achieve than switching over to .csproj files, as it allows people to continue doing things the way they always have. It would be nice to have all platforms build with xbuild, but if that's not possible, at least the burden of maintaining two build systems this way is a lot less than if we tried to maintain changes to .csproj files. Jonathan Jonathan Chambers wrote: Hello All, Mono on Windows has never been easy. However, lately things to have continually gotten worse (or I and others have just gotten more annoyed). Setting up an environment takes a lot of effort for a normal windows developer. Cygwin and the whole Makefile based process is very foreign for Windows developers. Not to mention the busted make in cygwin and cygwin issues on Vista (amd64). Most people have had enough interest in building mono on windows that they took the time to work things out (usually at least a day). But that's just the first time; try setting everything up again on a different machine or updating your cygwin and things start over. I see the basic issues as: 1) Cygwin development environment is less than ideal. It's foreign to most Windows developers and is a barrier to entry for most people. 2) Debugging is mostly impossible. gdb seems to provide little help on Windows (echoed by others on #monodev) 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. Simply opening a csproj file for a class library, hacking on it, testing under .Net and mono, and then contributing the changes seems a like a good goal to aim for in regards to contributors. The build/packaging guys can respond with what they are looking for on Windows. Any thoughts/responses on making mono better on Windows is appreciated. Thanks, Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ideas for Mono on Windows
As one of the true maintainers of classlibs I'm completely against ideas to drop cygwin support as it completely destroys my hacking life (note that I don't mean I dislike adding VS build support), but anyways here I agree with jpobst on the part to keep using dll.sources. Here is what I do for adding new source files into svn: - Update *.dll.sources file: ls ../../build/common/*.cs */*.cs | sort System.Foo.Bar.dll.sources make - Collect which files should be mentioned in ChangeLog: svn diff FooBar.dll.sources - copy the rectangle(s) on the console output - Add new files to svn (and svn propdel svn:executable): copypaste those lines in svn add command line. Can these tasks ever easier by switching to your beautiful xml csproj? In MWF land did we create csproj-sources converter? Classlib hackers who uses Visual Studio: how do you do those tasks? Atsushi Eno Jonathan Pobst wrote: Hey Jonathan, I'm glad to hear that you have the runtime building nicely on Windows. In my spare time, I have been playing with making an MSBuild script for the managed pieces, and was hoping you might have something similar for the unmanaged part. (Which I know nothing about.) The route I took (and this is my first time playing with MSBuild) was to write an McsTask that simply calls (g)mcs with the same command line as the make system. In this way, I simply use the existing .sources files. This may be an easier scenario to achieve than switching over to .csproj files, as it allows people to continue doing things the way they always have. It would be nice to have all platforms build with xbuild, but if that's not possible, at least the burden of maintaining two build systems this way is a lot less than if we tried to maintain changes to .csproj files. Jonathan Jonathan Chambers wrote: Hello All, Mono on Windows has never been easy. However, lately things to have continually gotten worse (or I and others have just gotten more annoyed). Setting up an environment takes a lot of effort for a normal windows developer. Cygwin and the whole Makefile based process is very foreign for Windows developers. Not to mention the busted make in cygwin and cygwin issues on Vista (amd64). Most people have had enough interest in building mono on windows that they took the time to work things out (usually at least a day). But that's just the first time; try setting everything up again on a different machine or updating your cygwin and things start over. I see the basic issues as: 1) Cygwin development environment is less than ideal. It's foreign to most Windows developers and is a barrier to entry for most people. 2) Debugging is mostly impossible. gdb seems to provide little help on Windows (echoed by others on #monodev) 3) Compilation takes forever. I am working on a Dual Quad Core machine (8 cores) at 3.6 Ghz. The mono build process still takes hours on my machine. This may be aggravated by virus scanners or other similar software, but the fact remains that all Windows users run virus scanners. As to not just be a complainer, I am offering some suggestions/ideas and hoping for others to do the same (or at least critique mine ;-)). Before I offer any suggestions, I think we need to balance between two things. One is making life easy for the mono build/package team to produce a Windows product. It's not real easy now, but we shouldn't make it any harder. The second thing is making life easy for those who wish to work/contribute to mono on Windows. This second item is tough at this point. 1) We should consider using MSVC as the default compiler for C code on Windows. I can compile the entire Visual Studio solution for the runtime in minutes. It takes 20-30 seconds if I do a parallel build. We can also use the Visual Studio debugger on Windows, which IMO is betten than gdb on Windows. 2) Two propositions for the class libraries have been mentioned previously. One is a lightweight, 'managed make' system that could be run easily on windows in place of all the build infrastructure provided by cgywin. This obviously allows us to keep using Makefiles on other platforms and keep a unified build process, but requires someone write the tool (and maintain it). Another option is to moved to MSBuild/xbuild for the class libraries. This would change the build process on all platforms, and require some fixing of our current xbuild tool. MSYS/MinGW has also been mentioned, but I don't consider that much better than Cygwin. I attempted to get it working one time, but gave up after a few days of hacking. Simply opening a csproj file for a class library, hacking on it, testing under .Net and mono, and then contributing the changes seems a like a good goal to aim for in regards to contributors. The build/packaging guys can respond with what they are looking for on Windows. Any thoughts/responses on making mono
