3

After having found the answer to my question about the 64-bit version of MSBuild attempting to load 32-bit extensions, it has now become necessary for me to determine whether the 64-bit or 32-bit version of MSBuild is running so I can load the correct version of the DLL.

I can check the $(MSBuildBinPath) variable against a list of known paths, but that will not work if MSBuild is running from some non-standard location. This is not an elegant solution.

Is there some way to reliably determine whether the currently running MSBuild (or other process hosting the MSBuild engine) is 32-bit or 64-bit?

Community
  • 1
  • 1
Mark
  • 11,257
  • 11
  • 61
  • 97
  • Can you provide more details on what you are trying to do, and/or what is invoking MSBuild? (That is important, as programmatic invocation is based on the reference to the Microsoft.Build.x dll) – Taylor Bird Aug 31 '10 at 19:04
  • I'm just running MSBuild from the command line. I need to know whether to load the 32-bit or 64-bit version of an extension, because MSBuild always tries to load it from the 32-bit extension path (see the referenced question for more details on that particular bug). – Mark Aug 31 '10 at 19:20
  • In that case, its simply whichever version you invoked. If you invoke MSBuild.exe from the C:\windows\microsoft.net\framework .... folder, then you are hitting 32bit. If its from the "Framework64", than its the 64bit version. – Taylor Bird Aug 31 '10 at 21:05
  • 1
    That's not helpful at all. I have an MSBuild "project" file that needs to know, because it needs to set variables differently depending on which was invoked. – Mark Aug 31 '10 at 21:37
  • I'm saying that's 100% buried in the caller. MSBUILD does not expose that information. They designed the 64bit version to be fairly agnostic (aka it basically assumes 32bit). You need to be explicit in the call OR install all your extensions in one static location. I know that answer sucks, its just that way they designed MSBuild in 3.0 and 4.0. If you can give more detail as to what you are doing, I may have a better solution ... but given the question as asked, thats it – Taylor Bird Aug 31 '10 at 21:51
  • possible duplicate of [Find out the "Bit"ness of the current OS in MSBuild](http://stackoverflow.com/questions/3505285/find-out-the-bitness-of-the-current-os-in-msbuild) – Ruben Bartelink Sep 01 '10 at 07:53
  • 1
    Not a duplicate at all. I don't need to know the bitness of the OS, I need to know the bitness of the running MSBuild (which could definitely be 32-bit even on a 64-bit OS) – Mark Sep 01 '10 at 14:43

2 Answers2

1

Have you considered writing a custom MSBuild task that returns bitness of the current process?

See How to detect Windows 64-bit platform with .NET? for an example.

Community
  • 1
  • 1
Arnold Zokas
  • 8,306
  • 6
  • 50
  • 76
  • Yes, I believe that this is going to be the only way... If only there were something that didn't require a whole new task... – Mark Sep 27 '10 at 13:58
  • If you are using MSBuild 4.0, you could write an inline task (http://msdn.microsoft.com/en-us/library/dd722601.aspx ). This would save you having to create a custom task assembly. – Arnold Zokas Sep 27 '10 at 14:49
-1

There is a related question at Find out the "Bit"ness of the current OS in MSBuild. In that question there is an answer by Blindy stating:

On a 64-bit OS, the following variables are defined:

ProgramFiles=C:\Program Files
ProgramFiles(x86)=C:\Program Files (x86)

So just test for ProgramFiles(x86) and if it's empty, use ProgramFiles.

Community
  • 1
  • 1
Sayed Ibrahim Hashimi
  • 43,864
  • 17
  • 144
  • 178
  • 1
    I don't care what the bitness of the current os is, I need the bitness of the current *PROCESS*. – Mark Sep 01 '10 at 14:41