Hi Ian,
Thanks for you answer!
I think that, in the end, it should be possible to both specify a default framework
version on the buildfile level and override that framework version (and type, in case
of .NET Compact Framework) on the task level, certainly for all DotNetTasks. That
would also remove that need for specific tasks for the Mono or Rotor runtime, the
existing tasks would be able to change their behaviour based on the runtime
environment you've specified.
The MsftFXSDKExternalProgramBase class would also have to lookup the path for external
framework sdk tools in different registry keys :
- for .NET Framework 1.0 ->
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\sdkInstallRoot
- for .NET Framework 1.1 ->
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv1.1
- for .NET Compact Framework 1.0 ->
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\sdkInstallRoot + build
number eg. v1.0.5000
If the .NET Compact Framework is specified as Framework runtime, then the compilers
and assembly linker of .NET Framework 1.1 should be used. But the /noconfig and the
/nostdlib options should always be specifed and references to system assemblies (where
no full path is specified) should be resolved to files in the Compact Framework SDK
directory (eg. C:\Program Files\Microsoft Visual Studio .NET
2003\CompactFrameworkSDK\) + build number (eg v1.0.5000) + "\bin" + "\Windows Ce".
For converting resx files to the resource format, the ResGen task should be updated to
use the CF version of Resgen.Exe which is CFResgen.exe (and is located in the Compact
Framework SDK bin directory.
Ofcourse you'd also need to have a central repository that maps a framework version
(or type) to a build number, that can be used to located the path to the correct
compilers and sdk tools.
Regarding the options for building for the .NET Compact Framework : yes, I think both
options should always be specified for building assemblies that target the .NET
Compact Framework :
- the /notstdlib option prevents the mscorlib.dll (of the framework version of the C#
compiler) from being imported and allows you to import the mscorlib.dll of the Compact
Framework.
- the /noconfig option must be specified in order to prevent the C# compiler from
automatically including references to all system assemblies (in csc.rsp in the same
directory as the compiler).
What do you mean by saying ".... a set of default args could be added to
>the config file also." ? Which config file are you talking about ? The nant config
>file ? I don't want to specify these options hen I build an assembly for the .NET
>Framework (1.0 or 1.1), I only want to specify them when I build an assembly for the
>.NET CF.
I completetly understand that these changes can not be incorporated in this release,
but I do hope you consider them for the next release as this will be an important
issue for all (open-source) projects.
Thanks,
Gert
------------------------
Ian MacLean <[EMAIL PROTECTED]> wrote:
------------------------
>Gert ,
>you are correct. Right now NAnt will find csc in the framework directory
>or the runtime its running against. As you've noticed this is
>sub-optimal when you're working against multiple versions of the framework.
>What has been vaguely proposed is to define certain global settings in
>the .config file. So if the config file contained FrameworkDir="path to
>1.0 framework" then csc would be found relative to that path. I would
>also like the ability to override this setting from a given .build file
>so you can have a default and then have different build files targetting
> different frameworks.
>do you always have to pass /nostdlib and /noconfig when using the
>compact framwork ? If so then a set of default args could be added to
>the config file also.
>
>To answer your previous question I don't think its advisable to add this
>support to the upcoming release. This release is well past due time so
>now is not the time to be adding major changes.
>
>In the meantime you could work around it by hacking cscTask.cs
>
>change line 41 from
>public class CscTask : MsftFXCompilerBase to
>public class CscTask : CompilerBase
>
>this will cause nant to use the first csc.exe in the search path. You
>can add the required args manually with the tag.
>
>
>Ian
>
>
>> Hi,
>>
>> We're currently porting log4net to the .NET Compact Framework. For the
>> next release (1.2.0), we will be supporting .NET Framework 1.0, .NET
>> Framework 1.1 and .NET Compact Framework 1.0, so we want to use nant for
>> automating the build process.
>>
>> We have to be able to built the log4net assembly for all three .NET
>> runtimes, is this possible using nant right now ? Currently, I think
>> nant will always use the version of the commandline tools for the
>> runtime version nant is using (eg. if nant is using .NET Framework 1.1,
>> then the 1.1 version of the C# compiler and the assembly linker will be
>> used) or am I wrong ?
>>
>> I've figured out that, in order to compile an assembly for the .NET
>> Compact Framework, you have to specify both the /nostdlib and /noconfig
>> commandline options for the C# compiler (and of course you have to
>> specify the full path to .NET Compact Framework system assemblies).
>>
>> Will support for building assemblies for multiple platforms be
>> incorporated in nant ?
>>
>> Thanks,
>>
>> Gert Driesen
>
>
>
>
>-------------------------------------------------------
>This SF.NET email is sponsored by:
>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
>http://www.vasoftware.com
>_______________________________________________
>Nant-developers mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/nant-developers
>
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
