Using mono-2.0 [was Re: [MonoDevelop] Import Visual Studio .NET Projects]

[Todd Berman]

On Tue, 2005-03-15 at 23:36 -0500, Dean Brettle wrote:
> On Tue, 2005-03-15 at 10:21 -0800, Todd Berman wrote:
> <snip>
> > I think to accept
> > allowing 2.0 assemblies to be used we have to have the following (all in
> > one single patch)
> > 
> > 1) Ability to pick gmcs/mcs and use it properly
> > 2) Only allow gmcs + 2.0 assemblies or mcs + 1.0 assemblies and not
> > allow mixing 1.0 and 2.0 assemblies.
> 
> OK, makes sense.  As a first pass, would you accept a patch that uses an
> env var (say MONODEVELOP_USE_MONO2) to determine whether to use gmcs+2.0
> assemblies?  A future patch could replace the env var with some GUI (say
> something in Edit->Preferences->MonoDevelop Options->Build?).  
> 

No. I would rather see it done right once without the hack, and the
potential for the hack to be more permanent than you thought.

> In the long run, perhaps it should be a project configuration option.
> However that looks like a considerably larger task.  Looks like it would
> require:

It should be a project configuration option.

> 1. changing .prjx schema to remove version info for GAC refs and add
> per-configuration attrs controlling mono-1.0 vs mono-2.0.

This isnt needed at all, or acceptable. You should (via the GUI) allow
one or the other, and for MONO-SYSTEM dlls, when the project option
changes, you change the references.

> 2. removing ref version info from the Edit References GAC tab 

Just don't show the references that match to the other set, removing ref
version info is bad, and will not be accepted.

> 3. changing SystemAssemblyService to provide the correct assemblies
> based on the project configuration.

This is trivial.

> 4. adding an option to the project config options to select mono-2.0 vs
> mono-1.0.

This is the important bit, the rest of the gui changes just hinge on
this one being correct.

However, in order to be forward thinking, instead of serializing this as
a bool, we might want to use something more flexible. Just something to
think about.

> 
> Sound about right?
> 
> Also, I'd appreciate any info on differences beteen gmcs usage and mcs
> usage?  "gmcs --help" and "mcs --help" produce almost identical results.
> 

There are none (that I know of)

--Todd