[Mono-list] Helping out Windows Developers

[Jonathan Pobst]

[MonoTODO("Help out Windows developers")]

I was fortunate enough to speak with several Windows developers at the 
Mono Summit about their experiences using Mono coming from a Windows 
background, and what needs to be done to make it better.

Covering the 80/20 case, I think the following assumptions can be made:

- Developers are primarily concerned with their apps running on Windows, 
but would like their apps to run on Mono/Linux if there is little to no 
additional development work required.
- Windows developers are not interested in switching to Linux, or 
SharpDevelop, or MonoDevelop.  They want to program in Visual Studio on 
Windows, that is, using the tools they've used for years and are most 
productive in.
- Windows developers are not interested in learning how to use the 
various Linux tools like svn, make, yast, apt-get, rpm's, etc.
- Windows developers are not interested in Gtk#.  Since the primary 
concern is their apps on Windows, Gtk# is not useful.  (Gaim on Windows 
sticks out pretty bad.)

Obviously, there are exceptions to the above, but for the 80% case, it 
should work.


So, things that can be done to help Windows developers use Mono:
- Paco's VS plugin

I had never really looked at this, as the name (VSPrj2Make) implies it 
isn't useful to the 80% case (no interest in make).  I don't really have 
any use for most of the features, like making make files or 
importing/exporting MonoDevelop solutions, but there was one feature 
that I saw that is an absolute must have: the "Run In Mono" toolbar.  

The Run in Mono button removes the need to find the mono command line, 
and call mono on wherever your assembly happens to be.  I think this 
feature absolutely needs to be ported to VS2005, and renamed something 
more like "Mono Development Plugin" or something.  The other features 
can come along for the ride if they are ready, but I need this feature 
in VS2005 today.  :)

Great work on coming up with that Paco.

- Mono Not Supported / Implemented rules

Another great idea I heard was creating something to analyze assemblies 
for things that are not supported in Mono yet.  Most likely this would 
be a part of Gendarme (if it runs on Windows?).

Some portability rules would be:
  - Calling methods that do not exist in Mono (useful for seeing what 
2.0 features you use that mono does not have yet)
  - Calling methods that are marked with [MonoTODO]
  - Calling methods that throw a NotSupportedException

Ideally, this would exist in the above VS plugin.  At the very least, it 
should produce a report listing the errors.  More advanced, and if 
possible, some sort of integration to take you directly to places in 
your source code, or mark them as warnings on compile.

- Mono VMWare Image

First off, thanks to Wade for this.  This is so much easier than trying 
to install Linux and then Mono.  The issue is that it is always out of 
date.  The most immediate problem is that there isn't an image for 
1.1.18 yet.  However, even after that, the problem is that Mono 
(especially winforms) moves so much faster than Mono releases.  I tried 
to build mono from SVN inside the VMWare image without success.  At the 
meeting, Wade informed me that all the things needed to do that had been 
removed to make the image smaller.

Since the answer to most issues is "Try SVN", we need a simple way to 
update mono in the VMWare image.  This can be:
- Applying a nightly build to the image.
- Downloading and compiling SVN.

Either way, this just needs to be a button on the image desktop that 
does all the work for you.  That is, click the button titled "Update 
Mono to latest version", wait for the command window to stop scrolling 
and say "It's done, press Enter, and have fun".

- Run in Mono on Linux (or SLED)

This is something that Miguel discussed before the event.  The basic 
idea would be an option on the VS plugin called "Run in Mono on Linux" 
which would start the VM image (if not already running), contact a 
daemon or something in the image, and start the current VS project 
inside the image.  This way Windows developers can test their app on 
Linux with one click, just like they do to test it on Windows.

Obviously, the technical logistics of this are probably a nightmare, but 
it would certainly be very helpful if it could be done.


I think one of the most important things I came away from the meeting is 
Miguel's sincere commitment to courting Windows developers for Mono.  
However, I think there are roughly zero (?) Windows developers on the 
Novell team, so they don't really know the way Windows developers work 
and how they expect things to work.  They were very actively seeking 
feedback from Windows developers.  The above is a start.  Please be sure 
to add yours!

- jpobst