The problem only exists if you have a wonky version of the 6.0 SDK. Most
seemed to be named 6.0A, but on our server it was installed as just 6.0.
---
Chris.
Continuous improvement is better than delayed perfection. - Mark Twain
On Thu, Mar 25, 2010 at 3:22 PM, Bob Archer <bob.arc...@amsi.com> wrote:
> 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
