[Mono-dev] [PATCH] 2.0 profile version of resgen
monoman at gmail.com
Sat Apr 8 08:50:09 EDT 2006
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.
On 4/8/06, Gert Driesen <gert.driesen at telenet.be> wrote:
> 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.
> > -----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
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...
More information about the Mono-devel-list