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

2010-03-25 Thread Ryan Boggs
Hi,

On Mar 25, 2010, at 3:14 PM, Christopher Brandt xtopher.bra...@gmail.com 
  wrote:

 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 /

I'll fix this tonight before running a new nightly.

 ---
 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
 nant-us...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/nant-users

Thanks,
Ryan

--
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
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers


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

2010-03-25 Thread Ryan Boggs
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 xtopher.bra...@gmail.com 
 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 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-us...@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#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
nant-us...@lists.sourceforge.net
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
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers