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: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 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@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 

Attachment: resgen2.patch
Description: Binary data

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Reply via email to