[Nant-users] Re: [nant-dev] multiple runtime support

[Gert Driesen]

Title: Message

Ian,   But the config file won't let you discover the location and availability of runtimes.  You also need to be able to have the task behave differently within the same buildfile.  It's no use being able to define which framewokcompiler directory the csc task should use in a config file, because it would have to be different when you compile the .NET Framework 1.0 and 1.1 versions in the same buildfile, and in the same run.   I don't think it make sense to store these runtime configuration in a configuration file.  What does make sense is, to allow users to specify additional runtimes in the configuration file.  That means you'd the internal collection of available runtimes first filled wih the runtimes we know about, and that we can automatically retrieve information about (using the registry) and next, add other runtimes from the information in the configuration file.   I would perfer discovering runtimes automatically when possible, than to store these in the configuration file.   But a combination of both, seems very powerful !   But we really should be able to specify the runtime configuration on both the project (the default runtime) and task level, by adding an additional attribute.  It's no use having to set both directory locations, compiler names and other setting for every task.  This would really complicate the buildfile a lot.  Setting an attribute indicating the runtime environment identifier (and thereby automatically getting the right directories, compiler names, ....) is definitely the way to go.   Again, just my 2 cents   Gert   ----- Original Message ----- From: Ian MacLean To: 'Gert Driesen' ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Tuesday, February 25, 2003 6:46 AM Subject: RE: [nant-dev] multiple runtime support I'm already looking at this problem by having settings stored in the config file. ie there would be a FrameworkCompilerDir and a FrameworkSDKDir paramater. These values will accessible from tasks and changeable from the build file. There will also be task specific settings so for the cscTask you could specify the compiler name - csc or mcs for mono.   The runtimeinfo idea looks useful. I would prefer to load runtimeinfo definitions from the config file than to hardcode identifiers for each one.   Ian -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Tuesday, February 25, 2003 2:20 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [nant-dev] multiple runtime support Hi,   I'm sorry for crossposting to both the users and developers list, but I think this is something that needs everyone's attention.   In my opinion we urgently need to come up with a strategy for implementing support for multiple runtimes, and for making tasks runtime-aware.  The release of the .NET Framework 1.1 is imminent, and Mono is making good progress so the chance that projects need to build assemblies for multiple runtimes is increasing.   I suggest that we create a RuntimeInfo class that will have the following properties :       - Identifier (eg. NET-1.0, Mono-1.0)     - Name (eg. Microsoft .NET Framework)     - Version (eg. 1.0)   This class would also have properties or methods for retrieving the framework directory (eg. C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705, this can be read from the registry) and sdk directory (eg. C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1) for the runtime which it represents and a method or bool for determining whether it's available.   We could have strong-typed RuntimeCollection class and the Project class would have two properties :       - SupportedRuntimes (collection of RuntimeInfo classes)     - AvailableRuntimes (collection of RuntilmeInfo classes that are available on the current system)   The Project class could also have a method that accepts a runtime indentifier and that will return bool indicating whether the runtime is currently available on the system.  The question is, when is a runtime available ? When both it's framework directory (the directory containing the assemblies) and the sdk directory are available (sdk is installed) ?   The project class and element would also get a new attribute for specifying the default runtime.  If no default runtime is provided, then the runtime under which is running is the default.   On the task level (would this be implemented on the base Task class or a new RuntimeAware task from which tasks that need to be aware of the targeted runtime environment should derive ?) we would be having a runtime attribute that accepts a runtime identifier.  In no runtime was explicitly specified on the task level, this property should return the default runtime that was set on the Project level or the runtime in which nant is running, if no default runtime was specified.   Th setter of this property would immediately check if the specified runtime is supported and available, and throw a buildexception otherwise.  The base class for the runtime-aware tasks would have method for retrieving the framework and sdk directories.  Which would return the directory for the runtime that was specified on the task level, if it's supported and available.  It would return the information about the default runtime, if it was specified on the project level. Or it will return the information of the runtime in which nant is running, if no runtime was specified on the task level and no default runtime was specified on the project level.   I'm just brainstorming a litle here (it's 6 am here, so don't count on all this being very accurate), but I think we need to get this discussion started (this and a good logging infrastructure need to get attention urgently)   Miguel de Icaza (from the Mono project) is willing to change the windows setup package for Mono to register it's location(s) and version(s) in the registry, he just wants some help for implementing it in the setup package.  That would allow us to discover the location and availability of both .NET Framework 1.0, .NET Framework 1.1, .NET Compact Framework 1.1 and Mono runtimes without using hacks.   Just my 2 cents,   Gert