I am trying to use C:\Prpgram Files (x86) on X64 machine and C:\Program Files on X86 machine in my build to refer to a VBA path like blow
I use the following path in my Project ->Properties -> C++ -> Additional Include Directrories
C:\$(MSBuildExtensionsPath32)\VBA6SDK\include
But I get compilation errors on a X86 machine since It cant find some header files located at
C:\Program Files\VBA6SDK\include
if I replace $(MSBuildExtensionsPath32) with "program files" no issues.
This is a MFC project that I am building using VS2010.
What am I missing ?
The $(MSBuildExtensionsPath32) property normally contains "C:\Program Files (x86)\MSBuild". The directory where MSBuild extensions are stored.
This of course has nothing to do with the VBA6SDK you are trying to use so the property is not very useful. You can use $(ProgramFiles) to use the system environment variable, it will be C:\Program Files (x86) on a 64-bit English operating system for the 32-bit toolchains. Don't prefix with C:\
Related
I'm using
cd C:\Program Files (x86)\Microsoft Visual Studio\VB98
vb6.exe /make Project1 /out %1
To basically compile my application, and I'm getting a compatibility issue (Saying doesn't work on my type of windows).
When compiling with the VB6 IDE (Make .exe) that works perfectly on my machine but this isn't, does anybody know how to fix this? Thanks
Error I receive when trying to open executable: "This version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 32-bit or a x64 64-bit version of the program, the contact the software publisher".
& It's a standard EXE application also.
I've tried running it as a administrator, trouble shooting / changing the compatibility to windows XP service pack 2 & 3, still didn't work.
Work prefer a good fix to this, like if there's anything I can do via console as a option or something or some option or anything.
Cheers! Please help ASAP
From the discussion in the comments, I believe the answer here is as follows (as identified by GSerg):
The problem is your use of the /make switch on the command line. The documentation says this about /out:
Outputs errors to a file when used with the /make or /makedll switch.
So, if you used vb6.exe /make Project1 /out Project1.exe, then Project1.exe would actually be a text file containing the error output from the compiler and thus would not be an actual executable, even though it had an .exe extension.
You actually don't specify the output binary when you use /make. The help output from running VB6.exe /? is a little more explicit:
Tells Visual Basic to compile projectname and make an executable file
from it, using the existing settings stored in the project file.
VB remembers the last filename and directory you used for compiling your project in the IDE, and it stores that in the .vbp file:
ExeName32="Project1.exe"
Path32="..\output"
I use a batch file to handle this issue. It sets the path to include both the 32-bit and 64-bit versions of the Program Files directories. Then just reference 'vb6.exe' and the correct one will be pulled from your path.
set PATH=c:"\Program Files (x86)\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files (x86)\Microsoft Visual Studio\VB98"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VB98"
vb6 /m foobar.vpb
I'm using
cd C:\Program Files (x86)\Microsoft Visual Studio\VB98
vb6.exe /make Project1 /out %1
To basically compile my application, and I'm getting a compatibility issue (Saying doesn't work on my type of windows).
When compiling with the VB6 IDE (Make .exe) that works perfectly on my machine but this isn't, does anybody know how to fix this? Thanks
Error I receive when trying to open executable: "This version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need a x86 32-bit or a x64 64-bit version of the program, the contact the software publisher".
& It's a standard EXE application also.
I've tried running it as a administrator, trouble shooting / changing the compatibility to windows XP service pack 2 & 3, still didn't work.
Work prefer a good fix to this, like if there's anything I can do via console as a option or something or some option or anything.
Cheers! Please help ASAP
From the discussion in the comments, I believe the answer here is as follows (as identified by GSerg):
The problem is your use of the /make switch on the command line. The documentation says this about /out:
Outputs errors to a file when used with the /make or /makedll switch.
So, if you used vb6.exe /make Project1 /out Project1.exe, then Project1.exe would actually be a text file containing the error output from the compiler and thus would not be an actual executable, even though it had an .exe extension.
You actually don't specify the output binary when you use /make. The help output from running VB6.exe /? is a little more explicit:
Tells Visual Basic to compile projectname and make an executable file
from it, using the existing settings stored in the project file.
VB remembers the last filename and directory you used for compiling your project in the IDE, and it stores that in the .vbp file:
ExeName32="Project1.exe"
Path32="..\output"
I use a batch file to handle this issue. It sets the path to include both the 32-bit and 64-bit versions of the Program Files directories. Then just reference 'vb6.exe' and the correct one will be pulled from your path.
set PATH=c:"\Program Files (x86)\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files (x86)\Microsoft Visual Studio\VB98"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VC98\bin"
set PATH=%PATH%;c:"\Program Files\Microsoft Visual Studio\VB98"
vb6 /m foobar.vpb
If an application is built on a 32-bit machine, when run on a 64-bit machine, how does it know the .dll is in C:\Program Files (x86) instead of C:\Program Files or it doesn't?
ERROR SUMMARY
[SCRIPT]: File not found: C:\Program Files\Common Files...\abc.dll.
However, in my 64-bit machine, abc.dll is in C:\Program Files (x86)\Common Files...\abc.dll
If it doesn't, where do I adjust the path because apparently it's not in the application's code.
First of all, you can cross-compile in either direction so being built on a 32-bit machine doesn't necessarily mean anything. It is really an issue of running 32-bit code on a 64-bit machine. In this case, there is a 32-bit emulation layer on 64-bit installations called Wow64. Part of this is file system redirection, which redirects file system requests from 32-bit programs. In this case, trying to access "C:\Program Files" from 32-bit code will transparently redirect to "C:\Program Files (x86)".
it doesn't?
No part of the default search path checks anywhere in Program Files or Program Files (x86) unless it is because the directory of the application is under one of those folders.
If you are getting that error from a 32bit application then something is set up unusually (like overriding the default install location under Program Files (x86)).
VS 2010 Premium :
I have a project which targets x86 platforms and I need to make it target x64 platforms.
I went to the Configuration Manager and from there to the Active Solution Platform, chose "new",added an 'x64' option and copied the settings from a Win32 platform (It's the only option I had).
So now the project should be targeting x64 platforms, if I'm not mistaken.
I have a code line in my project which asks for the file with this path :
Common Files\Microsoft Shared\OFFICE14\ACEDAO.dll
Yet it seems that during compilation, this file is being requested from the "Common Files" directory within the Program Files(x86) directory (the one for 32-bit). Naturally the compilation fails, since no such file exists in this path.
How can I make it to navigate to the (Program Files\Common Files ..) directory ?
The project should be targeting 64-bit after all and I require the 64-bit version of this dll.
The binary produced by the compiler and linker is indeed a 64-bit image. The compiler however is not, that's the one that reads the file so it is subject to file system redirection. The default 64-bit compiler is the one in the vc\bin\x86_amd64 directory. It is a 32-bit compiler that produces 64-bit code. You could select vc\bin\amd64 in the project's VC++ Directories setting to select the 64-bit compiler.
Something wrong with your machine setup though, I have this file present in c:\program files (x86). Windows 7 x64, Office 2010, VS2010. I have no clue why you don't have it, you could ask at superuser.com. Just copying the file is a simple workaround. Also beware that the 64-bit version of the ACE provider is not distributable.
Does anyone know if windows 7 will somehow defer back to the "ProgramFiles(X86)" environmental variable when the "ProgramFiles" variable is used?
We have a situation where a developer is using visual studio and the proj file references assemblies using "$(ProgramFiles)". The machine is 64-bit and the "ProgramFiles" variable points to "C:\Program Files", however the assemblies are in "C:\Program Files (X86)" yet the project builds. It does not build if the literal "C:\Program Files" path is used. The compiler says it cannot find the assemblies
Yes, Windows automatically maps folder and file access to c:\program files for 32-bit programs to c:\program files (x86). Visual Studio as well as MSBuild are 32-bit programs. Same is true for c:\windows\system32 vs c:\windows\syswow64.