We Keep Coding

Enums don't equal on different machines?

I'm using the Wix Bootstrapper Enum LaunchAction:
Microsoft.Tools.WindowsInstallerXml.Bootstrapper.LaunchAction
On my machine, a different laptop and a virtual machine when I do:
var m_state = LaunchAction.Install;
And then later on:
if(m_state == LaunchAction.Install)
It passes. Looking in the debugger m_state has the value Install. However on my colleagues machine the if statement does not pass. Looking in the debugger the values are exactly the same. My thoughts are that he might have an outdated / updated version of the WixBootstrapper DLL however that shouldn't actually have any effect because it would use that DLL when compiling.
Edit:
Comparing them as int values, on my machine and the laptop both values are 5. On my colleagues machine m_state is 5 and LaunchAction.Install is 4.
Edit 2:
So what we believe is happening is that the DLL he has on his machine is from the Wix toolset 3.9 whilst the other machines are using 3.10. In 3.9 the LaunchAction.Install is 4, whereas in 3.10 it is 5.
The custom bootstrapper has this DLL as a payload file. What we think has happened is that the payload file being added is a 3.10 version but when its originally compiled it's using the 3.9. Resulting the in the comparison being:
if(m_state == 4)
The answer being false because the value of m_state is using the 3.10 version so it reads 5.

You must rebuild bootstrapper applications and bundles when you switch versions of WiX. They're source-compatible buts BAs are not guaranteed binary-compatible.

An error appears when running Z3 in C#

Can anyone please help!
When I tried to run the code below, I got this error:
" Could not load file or assembly 'Microsoft.Z3, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=9c8d792caae602a2' or one of its
dependencies. An attempt was made to load a program with an incorrect
format "
Here is the code:
class Program
{
static void Main(string[] args)
{
using (Context ctx = new Context())
{
RealExpr c = ctx.MkRealConst("c");
BoolExpr Eqzero = ctx.MkGt(c, ctx.MkReal(0));
BoolExpr Gezero = ctx.MkGe(c, ctx.MkReal(0));
BoolExpr Lttwo = ctx.MkLt(c, ctx.MkReal(2));
BoolExpr Gtthree = ctx.MkGt(c, ctx.MkReal(3));
BoolExpr b1 = ctx.MkBoolConst("b1");
BoolExpr b2 = ctx.MkBoolConst("b2");
BoolExpr b3 = ctx.MkBoolConst("b3");
BoolExpr b0 = ctx.MkBoolConst("b0");
RealExpr[] lamb = new RealExpr[1];
lamb[0] = ctx.MkRealConst("lamb");
BoolExpr temp = ctx.MkAnd(ctx.MkGt(lamb[0], ctx.MkReal(0)), ctx.MkEq(b0, ctx.MkTrue()), ctx.MkEq(b1, ctx.MkTrue()), ctx.MkGe(ctx.MkAdd(c, lamb[0]), ctx.MkReal(0)), ctx.MkLe(ctx.MkAdd(c, lamb[0]), ctx.MkReal(3)), ctx.MkGe(c, ctx.MkReal(0)), ctx.MkLe(c, ctx.MkReal(3)));
BoolExpr exist = ctx.MkExists(lamb, temp, 1, null, null, ctx.MkSymbol("Q2"), ctx.MkSymbol("skid2"));
Console.WriteLine(exist.ToString());
Solver s1 = ctx.MkSolver();
s1.Assert(exist);
if (s1.Check() == Status.SATISFIABLE)
{
Console.WriteLine("get pre");
Console.Write(s1);
}
else
{
Console.WriteLine("Not reach");
}
Console.ReadKey();
}
}
}
}

The easiest way is to use build.cmd script in examples/dotnet folder and modify it according to your need. The script copies Microsoft.Z3.dll and z3.dll to the working directory and compiles the code on the corresponding platform.
If you compile from Visual Studio:
Make sure that Microsoft.Z3.dll's version you reference matches with the platform (x86, x64,...) which you're compiling to. There are two Z3 versions in bin and x64 folder.
Include the folder containing the Microsoft.Z3.dll in Project Properties->Reference Paths. The reason is that Microsoft.Z3.dll uses unmanaged z3.dll, which you cannot directly reference in Visual Studio.

In the comments to the previous answers to this question, reference to the x86 distribution and to the x64 distribution were made, and I am not sure this issue is resolved. To clarify:
When compiling a 64-bit binary (called x64 in visual studio), then the 64-bit versions of z3.dll and Microsoft.Z3.dll are required. Those are found in the folder called x64 in the Z3 distribution. Note that this does not depend on the actual machine that Visual Studio is running on.
When compiling a 32-bit binary, then the dlls from the bin directory are required. Again, this does not depend on the actual machine that Visual Studio is running on.
Visual Studio can cross-compile from 32 to 64 bit and vice versa, i.e., it is possible to compile a binary for the 32-bit architecture (called x86 as opposed to x64) on 64-bit machines. It is also possible to compile 64-bit binaries on a 32-bit machine. Depending on what kind of binary is being compiled, the right set of dlls must be added. The setting that matters is in the build configuration of your project in Visual Studio (on top, usually next to the where debug/release mode is selected). At this compilation stage, it does not matter what type of machine the compilation is being performed on. The actual machine only matters when an attempt is made to run a 64-bit binary on a 32-bit machine (but then the error message will be different from the one reported). Running 32-bit binaries on 64-bit machines usually works fine (but the maximum memory usage of the program will be limited).
I hope this helped to remove some of the confusion!
Also, we agree that the combined distribution including both versions creates some unnecessary confusion, so in the future we will consider distributing separate installers for the 32-bit and the 64-bit binaries.

AnyCPU/x86/x64 for C# application and it's C++/CLI dependency

I'm Windows developer, I'm using Microsoft visual studio 2008 SP1. My developer machine is 64 bit.
The software I'm currently working on is managed .exe written in C#. Unfortunately, I was unable to solve the whole problem solely in C#. That's why I also developed a small managed DLL in C++/CLI. Both projects are in the same solution.
My C# .exe build target is "Any CPU". When my C++ DLL build target is "x86", the DLL is not loaded.
As far as I understood when I googled, the reason is C++/CLI language, unlike other .NET languages, compiles to the native code, not managed code.
I switched the C++ DLL build target to x64, and everything works now. However, AFAIK everything will stop working as soon as my client will install my product on a 32-bit OS. I have to support Windows Vista and 7, both 32 and 64 bit versions of each of them.
I don't want to fall back to 32 bits. That 250 lines of C++ code in my DLL is only 2% of my codebase. And that DLL is only used in several places, so in the typical usage scenario it's not even loaded.
My DLL implements two COM objects with ATL, so I can't use "/clr:safe" project setting.
Is there way to configure the solution and the projects so that C# project builds "Any CPU" version, the C++ project builds both 32 bit and 64 bit versions, then in the runtime when the managed .EXE is starting up, it uses either 32-bit DLL or 64-bit DLL depending on the OS?
Or maybe there's some better solution I'm not aware of?
Thanks in advance!

There is a way: to have an "AnyCPU" C# wrapper and a C++ project per architecture, and let the C# wrapper load the right C++ project at run time.
For the C++ project, create one version per different architecture (x86, x64), and build them all. Then in the wrapper do:
public class CppWrapper
{
// C++ calls that will be dynamically loaded from proper architecture:
public static readonly Func<long> MyCplusplusMethodUsableFromCsharpSpace;
// Initialization:
static CppWrapper()
{
if(Environment.Is64BitProcess)
{
MyCplusplusMethodUsableFromCsharpSpace = CppReferences64.MyCplusplusClass.Method;
// Add your 64-bits entry points here...
}
else
{
MyCplusplusMethodUsableFromCsharpSpace = CppReferences32.MyCplusplusClass.Method;
/* Initialize new 32-bits references here... */
}
}
// Following classes trigger dynamic loading of the referenced C++ code
private static class CppReferences64
{
public static readonly Func<long> MyCplusplusMethod = Cpp64.MyCplusplusMethod;
/* Add any64-bits references here... */
}
private static class CppReferences32
{
public static readonly Func<long> MyCplusplusMethod = Cpp32.MyCplusplusMethod;
/* Add any 32-bits references here... */
}
}
And in the C++ code, I use the same sources as I said, but will compile to different namespace depending on the build architecture:
#ifdef _M_X64
namespace Cpp64 {
#else
namespace Cpp32 {
#endif
public ref class MyCPlusPlusClass
{
public: static __int64 Method(void) { return 123; }
};
}

There is no easy way around it. If you have native code (i.e. your C++) and you need to support x86, then you have to compile x86 (unless you want to work in WOW world...ie. running 32 bit code in both 32 and 64 bit envrionments). You can have both an x86 and x64 distributions, but if you're supporting both 32 and 64 bit, and you have native code or COM introp' then you have to have both 32 and 64 bit binaries. "Any CPU" only really is useful when there is no native code or interop, then you get that benifit.

C# Directive to indicate 32-bit or 64-bit build

Is there some sort of C# directive to use when using a development machine (32-bit or 64-bit) that says something to the effect of:
if (32-bit Vista)
// set a property to true
else if (64-bit Vista)
// set a property to false
but I want to do this in Visual Studio as I have an application I'm working on that needs to be tested in 32/64 bit versions of Vista.
Is something like this possible?

Can you do it at runtime?
if (IntPtr.Size == 4)
// 32 bit
else if (IntPtr.Size == 8)
// 64 bit

There are two conditions to be aware of with 64-bit. First is the OS 64-bit, and second is the application running in 64-bit. If you're only concerned about the application itself you can use the following:
if( IntPtr.Size == 8 )
// Do 64-bit stuff
else
// Do 32-bit
At runtime, the JIT compiler can optimize away the false conditional because the IntPtr.Size property is constant.
Incidentally, to check if the OS is 64-bit we use the following
if( Environment.GetEnvironmentVariable( "PROCESSOR_ARCHITEW6432" ) != null )
// OS is 64-bit;
else
// OS is 32-bit

You can use a #if directive and set the value as a compiler switch (or in the project settings):
#if VISTA64
...
#else
...
#endif
and compile with:
csc /d:VISTA64 file1.cs
when compiling a 64 bit build.

What I use in my C# code is IntPtr.Size, it equals 4 on 32bit and 8 on 64bit:
string framework = (IntPtr.Size == 8) ? "Framework64" : "Framework";

You can use Predefined Macros to set the properties on compilation
#if (_WIN64)
const bool IS_64 = true;
#else
const bool IS_64 = false;
#endif

I am not sure if this is what you are looking for but I check the IntPtr.Size to detect 32bit versus 64bit runtime. Note that this tells you the runtime environment, you might be running in WOW64
if (IntPtr.Size == 4)
{
//32 bit
}
else if (IntPtr.Size == 8)
{
//64 bit
}
else
{
//the future
}

I know that this is an old topic, but I recently had to achieve the same result (i.e. determine at build time, not run time)
I created new build configurations (x86 debug, x86 release, x64 debug, x64 release) and set BUILD64 or BUILD32 in the "Conditional compilation symbols" box in the application properties for each configuration.
When I needed to do something different between builds (like change the signature on some x86 exported methods from a .dll), I then used standard build directives to achieve what I needed. for instance:
#if BUILD64
// 64 Bit version
// do stuff here
#endif
#if BUILD32
// 32 Bit version
// do different stuff here
#endif

Open the Configuration Manager from the Build. From there you should be able to set the Active solution platform and create configuration that specifically target x64, x86, or Any CPU. From there you can have code that conditionally compiles based on the current configuration.
Note that this is usually a very bad idea, though. .Net programs are normally distributed as IL rather than native code. This IL is then compiled by the JIT compiler on each local machine the first time the user tries to run it. By leaving the default "Any CPU" selected, you allow the JIT compiler to make that determination for each individual machine.
The main exception for this is when you have a dependency on a 32bit library. In that case, you don't want the JIT compiler to ever compile for x64, because it could break your interop with the library.

There is nothing built in that will do this for you. You could always #define your own symbol and use that for conditional compilation if you wish.

C# - How to get Program Files (x86) on Windows 64 bit

I'm using:
FileInfo(
System.Environment.GetFolderPath(
System.Environment.SpecialFolder.ProgramFiles)
+ #"\MyInstalledApp"
In order to determine if a program is detected on a users machine (it's not ideal, but the program I'm looking for is a right old kludge of a MS-DOS application, and I couldn't think of another method).
On Windows XP and 32-bit versions of Windows Vista this works fine. However, on x64 Windows Vista the code returns the x64 Program Files folder, whereas the application is installed in Program Files x86. Is there a way to programatically return the path to Program Files x86 without hard wiring "C:\Program Files (x86)"?

The function below will return the x86 Program Files directory in all of these three Windows configurations:
32 bit Windows
32 bit program running on 64 bit Windows
64 bit program running on 64 bit windows
static string ProgramFilesx86()
{
if( 8 == IntPtr.Size
|| (!String.IsNullOrEmpty(Environment.GetEnvironmentVariable("PROCESSOR_ARCHITEW6432"))))
{
return Environment.GetEnvironmentVariable("ProgramFiles(x86)");
}
return Environment.GetEnvironmentVariable("ProgramFiles");
}

If you're using .NET 4, there is a special folder enumeration ProgramFilesX86:
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)

Environment.GetEnvironmentVariable("PROGRAMFILES(X86)") ?? Environment.GetFolderPath(Environment.SpecialFolder.ProgramFiles)

Note, however, that the ProgramFiles(x86) environment variable is only available if your application is running 64-bit.
If your application is running 32-bit, you can just use the ProgramFiles environment variable whose value will actually be "Program Files (x86)".

One way would be to look for the "ProgramFiles(x86)" environment variable:
String x86folder = Environment.GetEnvironmentVariable("ProgramFiles(x86)");

I am writing an application which can run on both x86 and x64 platform for Windows 7 and querying the below variable just pulls the right program files folder path on any platform.
Environment.GetEnvironmentVariable("PROGRAMFILES")

One-liner using the new method in .NET. Will always return x86 Program Files folder.
Environment.Is64BitOperatingSystem ? Environment.GetEnvironmentVariable("ProgramFiles(x86)") : Environment.GetEnvironmentVariable("ProgramFiles"))

C# Code:
Environment.GetFolderPath(Environment.SpecialFolder.ProgramFilesX86)
Output:
C:\Program Files (x86)
Note:
We need to tell the compiler to not prefer a particular build platform.
Go to Visual Studio > Project Properties > Build > Uncheck "Prefer 32 bit"
Reason:
By default for most .NET Projects is "Any CPU 32-bit preferred"
When you uncheck 32 bit assembly will:
JIT to 32-bit code on 32 bit process
JIT to 32-bit code on 64 bit process