When I started the installer for VS 2017 the default installation directory was set to Program Files (x86). I am using Windows 10 x64 OS on a 64 bit machine.
I downloaded from this link https://www.visualstudio.com/downloads/. I just want make sure I am installing the right thing before proceeding.
This happens when the program is a 32-bit version, and you have a 64-bit version of Windows.
You have downloaded the 32-bit version and that's why its going to that folder. If you were to download a 64-bit version of Visual Studio(a), it would be placed (by default) in to "Program Files".
(a) Unfortunately no such beast exists, so VS will always end up in the x86 variant unless you explicitly put it elsewhere. In other words, what you're seeing is totally normal.
Related
The development environmeng is x86, and the target is to compile .EXE that for both 32-bit or 64-bit Windows systems. Which folder shall I install? Seems the default installation folder is C:\programs files (x86), though I'm on a 64-bits Windows 7 OS. what's the difference on either one to install?
Visual Studio is a 32-bit program so just let it install where it wants to.
You can still develop and debug 64-bit programs though, those things are orthogonal.
I used some stupid SDK (e.g. ADS) which doesn't work with path including '()', and I wast a lot of time to find the problem.
I you have such kind SDK to use, do not install it in C:\programs files (x86).
I built an application in C++ using Visual Studio 2010 Express. When I tried to run it on a certain computer today I got this error:
MyApplication.exe - Bad Image
C:\Path to My Application\MSVCP100.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.
The DLL mentioned is one of the Visual C++ Redistributable DLLs. My application’s installer used to launch Microsoft’s installer for those DLLs but I recently tweaked it just to install msvcp100.dll and msvcr100.dll alongside my application. The new way worked fine on a handful of other computers, though I can’t rule out the possibility that that was only because the DLLs had already been installed at system level on those other computers.
What is causing this sudden DLL mismatch?
That's STATUS_INVALID_IMAGE_FORMAT, the Machine property in the DLL header doesn't match the architecture of the application.
Do keep in mind that you are likely to have two copies of this DLL on your build machine, the x86 and the x64 version. Later versions of VS have a 3rd copy, the ARM version. So very high odds that you picked the wrong one. Usually you'd target x86, the one you tested your program with is stored in the c:\windows\syswow64 directory. The 64-bit version is in c:\windows\system32.
How these directories got these seemingly backward names is a story for another day :) Favor using the vc/redist subdirectory of the VS install directory as a source for the copy, it is less ambiguous.
This .dll file is related to the Microsoft Visual C++ 2010 Redistributable x64 Package.
Try removing the Microsoft Visual C++ 2010 Redistributable x64 Package by using the Add or Remove Programs item in Control Panel.
Then, install the latest version Visual C++ (file name= vcredist_x64.exe) from the site:
http://www.microsoft.com/en-us/download/details.aspx?id=26999
Hope that helped..
If all above suggested solutions not worked for you than download MSVCR100.dll 32 bit or 64 bit as per your system configuration.
Download DLL from below link
https://www.sts-tutorial.com/sites/downloadCenter.php?MSVCR100
Follow da steps
1.Download the dll from here
https://www.sts-tutorial.com/sites/downloadCenter.php?MSVCR100
2.open with winrar
3.Extract MSVCR100.dll to C:\Windows\System32
hope it will work c:
I am a non-admin user on a Windows 7 (32 bit) computer, and also an admin user on a Windows 7 64-bit computer. I am trying to build the Vim text editor from source code to install on the 32-bit machine (to a place I have access, like C:\Vim).
Now, I have successfully built both a 64-bit and 32-bit version of Vim on my 64-bit computer. Both of them run fine on the 64-bit computer. I can verify with "dumpbin.exe" as detailed here that the 32-bit build really actually is a 32-bit build. Doing ":version" within Vim while running the 32-bit build also confirms this.
But when I try running that same executable on the 32-bit machine, I see "This version of gvim.exe is not compatible with the version of Windows you're running. Check you computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher." For kicks, I tried the 64-bit build of Vim and got the same message. I tried setting compatibility mode on the executable before running it, but get the same result. Additionally, only "Windows Server 2008" and a few version of "Windows Vista" appear in the list of compatibility modes: I was going to try Windows XP but it does not appear in the list.
Now, when I download an installer from cream.sf.net instead of trying to build my own Vim, Vim installs fine and then launches fine. I can see the full list I originally expected in the compatibility mode list of the installed executable. So I must be doing something wrong when I build.
The only difference I can think of, is that I'm compiling on a 64-bit machine, and using Visual Studio 2010 rather than Cygwin to build. But it is very strange that neither the 32-bit nor the 64-bit build works; I would always expect at least one of them to work! What could I be doing wrong?
It's not related to Vim. Recent versions of MSVC use a new format for 32-bit binaries, which is not compatible with XP. You can change back to the old format in MSVC with a flag/config option. I'm certain this works with VS 2013 (compiling on a 64-bit machine) and 2012 SP1. According to this post it's also possible with 2010 if you define NTDDI_<version> and _WIN32_WINNT.
I'm making installers for plug-ins using the InstallShield LE built in to Visual Studio 2010. The plug-ins run in separate processes, so they are always 32-bit even if the host application is 64-bit. The plugins must be installed to the same directory as the host application. Therefore, the plugins should always install in Program Files even on 64-bit Windows - not Program Files (x86).
InstallShield's [ProgramFilesFolder] predefined folder detects that the project output is 32-bit and evaluates to Program Files (x86) on a 64-bit machine.
I thought I could get around this by using a fixed folder instead of [ProgramFilesFolder]. But Installshield appears to change it to Program Files (x86) anyway! I guess it's trying to be helpful.
Is there any way to get around this?
The redirection is done by the OS, not by InstallShield. The same applies for MSI packages built with other setup authoring tools. I explained this with more details in
How to install VS help using WIX x86 installer on a x64 platform?
Have GHC 6.8.3 and wxHaskell-0.10.3 on a Windows XP computer. Installed both as binary distributions, not by building from sources. Built a sample with the following command:
ghc --make Paint.hs
It works on that same computer it was built on (with GHC and wxHaskell installed), but fails if transferred to another one (with neither of them installed). It throws an "Application error" box with "The application failed to initialize properly (0xc0150002). Click OK to terminate the program."
The only non-system dll it wanted was wxc-msw2.6.4-0.10.3.dll, which I copied to it's folder.
What might be the reason?
The error comes from dependencies that are mentioned in the manifests of DLL's (presumably the third-party ones with wxHaskell) that your system is expecting to find installed in places such as WinSxS and SoftwareDistribution in your Windows directory. I am guessing the wxHaskell installation puts the files there.
You may be able to find what files the program is looking for by looking in the event viewer on the failed machine. You may even be able to fix them by moving the files from a working machine, However, VC++ 2005 runtimes are the most likely, as suggested - the wxHaskell troubleshooter suggests you try the VC++ 2005 service pack 1 redistributables:
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en
My guess is, you want to install the VC++ runtime redistributable files onto the target computer. The redistributable files for applications built with visual studio 2005 are available from here:
http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
Datapoint: Works for me on an XP sp2 box.