[Mono-dev] [PATCH] 2.0 profile version of resgen
gert.driesen at telenet.be
Sat Apr 8 03:37:01 EDT 2006
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 ?
> > 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
> > 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
> > 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
> 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
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 707 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060408/e21b5f43/attachment.obj
More information about the Mono-devel-list