I use the latest nightly and it works ok. But, I explicity let the
targetframework property in the scripts.
I also use the msbuild task rather then the csc task.. but I assume it uses the
same mechanism to determine which to use.
BOb
From: Christopher Brandt [mailto:xtopher.bra...@gmail.com]
Sent: Thursday, March 25, 2010 6:14 PM
To: nant-users@lists.sourceforge.net
Subject: [NAnt-users] Target Framework net-3.5 Configuration
This is related to my previous post on Windows 7 & VS2008.
After some help I realized that the target framework on my desktop was .Net 3.5
whereas on my build server (Windows 2003 Server) it was .Net 2.0. The was
causing some problems between the two environment in how csc.exe was importing
includes. The build server required our files to explicitly specify the paths
to the .Net 3.5 dlls, but on my desktop it choked on build files with explicit
paths (error was that the libraries had already been imported).
The difference between the target frameworks, terms of how NAnt functions, is
specified in the NAnt.exe.config file. The configuration for each target
framework is specified with the reference assemblies to load. That is why in
one environment they are loaded by NAnt and in the other our build file had to
specify where to get them from.
The root of my problem then was why my build server was still targeting the
net-2.0 framework rather than 3.5. We've had .Net 3.5 installed on that server
for well over a year (has it been out that long?). NAnt attempts to determine
the highest available framework as the default. In our case the best it could
find was 2.0. The reason is in the configuration for the net-3.5 framework. The
<project> element in the config file lists the places where NAnt attempts to
look for clues to see what frameworks are available. We are running 0.86 on the
build server and it's config file specifies that it should look for a registry
key:
SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v6.0A\WinSDKNetFxTools\InstallationFolder
However on our build server the key is in:
SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v6.0\WinSDKNetFxTools\InstallationFolder
v6.0 not v6.0A
I see that the configuration in NAnt 0.9 has v6.0A, v6.1, v7.0. And my desktop
does have v6.0A.
So a simple modification to the NAnt.exe.config to add a <readregistry> element
for v6.0, fix our problem.
I would guess that we're not alone with this wonky SDK version. So someone
should probably add the the following to at least the configuration for the 0.9
build:
<readregistry
property="sdkInstallRoot"
key="SOFTWARE\Microsoft\Microsoft
SDKs\Windows\v6.0\WinSDKNetFxTools\InstallationFolder"
hive="LocalMachine"
failonerror="false" />
---
Chris Brandt
Continuous improvement is better than delayed perfection. - Mark Twain
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
NAnt-users mailing list
NAnt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users
