32-bit build on 64-bit system is broken about nant HOT 17 OPEN

yup, sounds like a problem. I need to get ahold of a x64 build system of some kind to tackle 64-bit related issues like this.

from nant.

Hi,

So I have done some investigation and I think I see what is happening, I am just not sure the best way to proceed in addressing this issue.

On Windows/.NET machines, NAnt tries to locate which versions of .NET are installed on the machine it is running on via registry entries, which the registry paths are specified in the NAnt.exe.config file (the installRoot var, if I am not mistaken). The problem in this and Issue #56 is that on x64 machines, there are two different registry paths used to specify the which platform of .NET is being used (x32 or x64). .NET x64 uses the default registry path "SOFTWARE\Microsoft.NETFramework\InstallRoot" (which is what NAnt is coded for) while .NET x32 uses "SOFTWARE\Wow6432Node\Microsoft.NETFramework\InstallRoot". So, in this case, when the user tries to build a .NET application on a Winx64 machine that targets the x32 platform, NAnt is referencing the x64 libs during the build.

So that is what I think is happening. The problem I am having is trying to figure out the best approach to address this issue. The thoughts I have had so far entail quite a bit of reworking of how the .NET versions are located but I don't want to tear the thing down completely if I can help it. I am open to suggestions/comments/thoughts as to best approaches for solving this issue.

Thanks,
Ryan

from nant.

Hi Ryan

You could be very much right. When i tried to use the 64 bit VSS library in NantContrib and compiled . Then try to use it in my application it did not worked.

I also wrote a separate application to do some VSS work using the new VSS library dll. guess what when i compiled my new application with Any CPU or X64 it never worked.

So i guess for VSS library to work we have to use x86 . i do not know if this info helps. i just thought to share this with you.

Thanks
Jyoti

From: Ryan Boggs [email protected]
To: nant/nant [email protected]
Sent: Thursday, September 13, 2012 3:18 PM
Subject: Re: [nant] 32-bit build on 64-bit system is broken (#54)

Hi,
So I have done some investigation and I think I see what is happening, I am just not sure the best way to proceed in addressing this issue.
On Windows/.NET machines, NAnt tries to locate which versions of .NET are installed on the machine it is running on via registry entries, which the registry paths are specified in the NAnt.exe.config file (the installRoot var, if I am not mistaken). The problem in this and Issue #56 is that on x64 machines, there are two different registry paths used to specify the which platform of .NET is being used (x32 or x64). .NET x64 uses the default registry path "SOFTWARE\Microsoft.NETFramework\InstallRoot" (which is what NAnt is coded for) while .NET x32 uses "SOFTWARE\Wow6432Node\Microsoft.NETFramework\InstallRoot". So, in this case, when the user tries to build a .NET application on a Winx64 machine that targets the x32 platform, NAnt is referencing the x64 libs during the build.
So that is what I think is happening. The problem I am having is trying to figure out the best approach to address this issue. The thoughts I have had so far entail quite a bit of reworking of how the .NET versions are located but I don't want to tear the thing down completely if I can help it. I am open to suggestions/comments/thoughts as to best approaches for solving this issue.
Thanks,
Ryan
—
Reply to this email directly or view it on GitHub.

from nant.

I had a similar issue recently. I setup a new build machine for our Visual Studio 2012 products. It is 64-bit. I initially tried the latest download of NAnt, but builds failed. So, I got the source and modified it to accommodate Visual Studio 2012 solutions and .NET 4.5 targets. This got some of the simple builds going, but ran into trouble with any solution that utilized the Visual Studio SDK. Upon further research, I found what Ryan and Jyoti found above about the registry keys. To get around this, I built NAnt as x86. All of my builds now work. Granted, this is not an ideal solution, but could help for now.

from nant.

I'm gonna try to see if I can set NAnt to target the x86 platform during the build process and see what happens. Right now, it is defaulting to "anycpu" which targets whatever platform it is running on which seems to be part of this problem. I think that the reason why 0.91 doesn't have this problem is because that was the last version that was built using .NET 1.0 csc compiler, which doesn't have the /platform command line option (I think .NET 1.0 was only for x32). 0.92 alpha1 was the first version we built using the .NET 2.0 compilers.

from nant.

I'm guessing something changes between 0.91 and later as 0.91 just works. Any reason for the change in the first place?

Sent from my iPhone

On Sep 24, 2012, at 2:34 PM, Ryan Boggs [email protected] wrote:

I'm gonna try to see if I can set NAnt to target the x86 platform during the build process and see what happens. Right now, it is defaulting to "anycpu" which targets whatever platform it is running on which seems to be part of this problem. I think that the reason why 0.91 doesn't have this problem is because that was the last version that was built using .NET 1.0 csc compiler, which doesn't have the /platform command line option (I think .NET 1.0 was only for x32). 0.92 alpha1 was the first version we built using the .NET 2.0 compilers.

—
Reply to this email directly or view it on GitHub.

from nant.

Yean, we wanted to start using .NET 2.0 features in NAnt. Which we started using with the 0.92 release.

from nant.

I just did a build with the fix that was suggested above. I will see if I can test it tonight on a x64 machine but if anyone wants to give it a try, it's located here. The zip file is called issue_54.zip.

from nant.

FYI - The branch I am using to address this issue is in my fork. It can be found here.

from nant.

This is related to #78
The assemblies in "%ProgramFiles%\Reference Assemblies**" are MSIL, so that they can be referenced for all platform types (MSIL/x86/x64). Assemblies in framework folder might be built for specific platform, so they will generate warning if build platform differs.

from nant.

I solved this myself by changing the Nant.exe.config, by adding this:

frameworkdirectory="${path::combine(string::replace(installRoot, 'Framework64', 'Framework'), 'v1.1.4322')}"

And replacing all occurrences of installRoot for NET1.1 xml section only!

As far as i know, NET1.1 never runs on x64 because it does not support it at all, therefore the method that tries to obtain the NETFramework path is wrong in NANT0.92, and it should not rely on this.

I only put for net1.1 but probably also applies to net1.0.

from nant.

We discovered the same thing with the NAntContrib msbuild task. As others indicate, I think it's because of how the framework dir is discovered (MSBuildTask is decorated with [ProgramLocation(LocationType.FrameworkDir)]).

from nant.

For those of you trying to get around this error, try adding this to your <csc/> task for now:

<nowarn><warning number="1607"/></nowarn>

I've been trying to work on this for the past few days or so. Based on my research, these are superficial compiler warnings by the compiler saying that the libs you are linking to are not on the same platform you are targeting. When you run the resulting program, it should work fine because it ends up pointing to the correct libs anyway. I've tried it on some samples and it seems to be true. Adding the nowarn line above allows for the script to succeed.

Now, I am not saying this should be the solution since this would require user script updates. I'm still trying to find the best approach for a long term solution. So far, I've tried switching the FrameworkDir to point to the Wow6432Node to get the 32bit compiler, which works for this scenario but breaks if you try to specify x64 as the platform. Then there is the platform switching idea (dynamically switching between x86 and x64 compilers based on the compiler task attributes) but this would involve extensive work and probably a lot of moving parts behind the scenes, which makes me nervous.

Does anyone have any other ideas for approaches?

from nant.

What about using assemblies in "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework" for referencing? AFAIK that is what Visual Studio does.

from nant.

It's already doing that in the app.config, unless you are referring to something else.

It doesn't really matter which assemblies are being referenced. I was able to recreate the error described above with a simple "hello world" program on the command line without additional assemblies.

from nant.

c:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /platform:x86 /noconfig /nostdlib /reference:"c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.2\mscorlib.dll" Program.cs
does not produce warning
c:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /platform:x86 /noconfig Program.cs
does warn that
warning CS1607: Assembly generation -- Referenced assembly 'mscorlib.dll' targets a different processor

from nant.

Oh! That's interesting! I'll check that out. Thanks for that idea, @gkello.

from nant.