[Mono-dev] [PATCH] 2.0 profile version of resgen

[Gert Driesen]

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com 
> [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf 
> Of Rafael Teixeira
> Sent: zaterdag 8 april 2006 14:50
> To: Gert Driesen
> Cc: Miguel de Icaza; mono-devel mailing list
> Subject: Re: [Mono-dev] [PATCH] 2.0 profile version of resgen
> 
> No need for a mbas2 wrapper as that could confuse people making then
> expect VB.NET 8.0 (the one in .NET 2.0) features. I expect mbas to run
> with any profile, if that is not the case, I would like to know how to
> make it so, to avoid the cited potential confusion.

mbas does not support emitting .NET 2.0 assemblies and also does not support
referencing .NET 2.0, which is why I proposed to also build an mbas.exe in
the 2.0 profile. 

I know that mbas does not have any VB.NET 8.0 features, but one should still
be able to use it to compile applications that use .NET 2.0 BCL features.

Whether or not an mbas2 wrapper script should be created, is another
question...

Gert
 
> On 4/8/06, Gert Driesen <gert.driesen at telenet.be> wrote:
> > Hi,
> >
> > The attached patch modifies the Makefile for resgen to 
> support a different
> > output assembly for each supported profile, and adds a 
> 'resgen2' wrapper
> > script for executing the 2.0 profile version of resgen.
> >
> > This change was discussed with Miguel a few weeks ago (see below).
> >
> > Are there more changes necessary to get the 2.0 version of 
> resgen and its
> > wrapper script in the distribution ?
> >
> > Is ok to also create a 2.0 profile versions of mbas, xsd 
> and al ? I would
> > submit a separate patch for these ofcourse.
> >
> > Gert
> >
> > > -----Original Message-----
> > > From: mono-devel-list-bounces at lists.ximian.com
> > > [mailto:mono-devel-list-bounces at lists.ximian.com] On Behalf
> > > Of Miguel de Icaza
> > > Sent: zaterdag 25 maart 2006 22:38
> > > To: Gert Driesen
> > > Cc: 'mono-devel mailing list'
> > > Subject: Re: [Mono-dev] 2.0 profile version of Mono tools ?
> > >
> > > Hey,
> > > > This is because resgen is a 1.1 (1.0 profile) assembly
> > > (which loads some 1.1
> > > > system assemblies) and hence you end with a 1.0 runtime,
> > > which ofcourse
> > > > can't deal with 2.0 assemblies.
> > > >
> > > > Why not just build all Mono tools in both 1.0 and 2.0
> > > profile ? Even if the
> > > > source code is exactly the same, you still need these
> > > profile-specific
> > > > assemblies.
> > > >
> > > > We would then have, for example, a resgen.exe in
> > > $prefix/lib/mono/1.0 and
> > > > $prefix/lib/mono/2.0. You can then even have a small
> > > wrapper script (named
> > > > resgen) that executes one of these assemblies based on some
> > > environment
> > > > variable (MONO_PROFILE) or something.
> > > >
> > > > Isn't this better than having wsdl, wsdl2, wsdl3, ... ?
> > > >
> > > > Any feedback is appreciated ...
> > >
> > > Although I like the idea, am not sure how we control the profile.
> > >
> > > And I am not sure if we want to do this change with an environment
> > > variable that would control the executable to run, or if 
> we should do
> > > this with something at the runtime level.   I think we 
> need to explore
> > > the various avenues before making a commitment to a particular
> > > direction.
> > >
> > > That being said, I think that an immediate thing to do would be to
> > > create the scripts and executables for the second profile and
> > > get those
> > > on SVN, at least you get a workaround.
> > >
> > > A second stage would be to create the new wrapper scripts 
> that would
> > > invoke one-or-the-other script based on the name.   In this second
> > > stage, I would probably still want to have tool, tool1 and
> > > tool2, where
> > > tool does the default-or-configured invocation;  tool1 is
> > > always the 1.0
> > > version and tool2 is always the 2.0 version.
> > >
> > > But this should really be a stage 2.   As part of this, 
> we should come
> > > up with the smallest possible "multiplexing" script that 
> would invoke
> > > one or the other.  We should not bloat these scripts as they
> > > are used a
> > > lot.
> > >
> > > Miguel.
> > > _______________________________________________
> > > Mono-devel-list mailing list
> > > Mono-devel-list at lists.ximian.com
> > > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> > >
> >
> >
> > _______________________________________________
> > Mono-devel-list mailing list
> > Mono-devel-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/mono-devel-list
> >
> >
> >
> >
> 
> 
> --
> Rafael "Monoman" Teixeira
> ---------------------------------------
> As I'm currently working a lot with Java and even fixing Java VMs
> (JamVM/Kaffe) and GNU Classpath code, I think I may partly borrow the
> title (Javaman) from my friend Bruno Souza and become the
> MonoNJavaMan. Yeah, I may currently be crazier than usual...
>