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.
Cheers, On 4/8/06, Gert Driesen <[EMAIL PROTECTED]> 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: [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 > > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@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...
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
