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

[Gert D. <ger...@pa...>]

MessageIan,

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 -----=20
  From: Ian MacLean=20
  To: 'Gert Driesen' ; nan...@li... ; =
nan...@li...=20
  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: nan...@li... =
[mailto:nan...@li...] On Behalf Of Gert =
Driesen
    Sent: Tuesday, February 25, 2003 2:20 PM
    To: nan...@li...; =
nan...@li...
    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