Re: [NAnt-users] Target Framework net-3.5 Configuration

Actually, this is something that keeps coming up because of the way  
Microsoft has been organizing the sdk directory structures since 3.0.  
We have been just dealing with them as they come in so there may be  
other reg keys out there that we don't know about yet.

Please keep these emails coming in.  :)

Thanks,
Ryan

On Mar 25, 2010, at 3:24 PM, Christopher Brandt <[email protected] 
 > wrote:

> 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 <[email protected]>  
> 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:[email protected]]
> Sent: Thursday, March 25, 2010 6:14 PM
> To: [email protected]
> 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&#174; 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/nant-users

------------------------------------------------------------------------------
Download Intel&#174; 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-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/nant-developers