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 >
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
