I'm trying to compile a simple 32-bit Hello World application written in C using Visual Studio 2010 on a 64-bit machine on a Windows 7 fresh install. I also installed the "Windows SDK for Windows 7 and .NET Framework 4" after installing Visual Studio.
I built the application selecting "Win32" as platform. It works on Windows 7 but if I run the application on my 32-bit machine with Windows XP Professional (fresh install also this, without softwares and Service Packs) it seems not working getting this error:
"This application has failed to start because msvcr100.dll was not found"
If it can be useful Dependency Walker detects 2 errors (see the linked picture for details):
"Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module."
"Error: Modules with different CPU types were found."
http://img820.imageshack.us/img820/4725/errordp.png (PIcture)
How can I solve it? Thanks!
The machine on which it is run needs the runtime libraries. See this MSDN information.
Don't trust Dependency Walker on this... It clearly shows your exe is 32 bit. Your problem is with the VC redistributables, which are the CRT dlls - look for vcredist_x86.exe in your VS installation. You should run it before you run your app.
Another option is to statically link the CRT. See the /MT option. Will make your exe larger, but save the vcredist stuff.
The problem here is the C runtime used by the compiled program is missing on the Windows XP machine. Visual Studio 2010 will by default us the 10.0 (msvcr100.dll) runtime which is not available on XP by default. You need to manually deploy the C runtime on your machine in order for your program to run.
You may want to read the following MSDN article which discusses the issues around deploying C applications built with Visual Studio 2010
http://msdn.microsoft.com/en-us/library/zebw5zk9.aspx
There may be additional 32 / 64 issues at work but this appears to be the primary problem
The answers about the runtime library are correct. Another possible solution is to link to the static runtime libraries rather than to the DLL versions. This way you can build an executable that you can drop onto any machine without extra deployment hassles.
It's a trade-off, but, without knowing more about your situation, it might be worth considering.
Related
I made a Windows application with C++ WinAPI by using Visual Studio 2019.
After finishing, I built it, and executed with my computer. It works perfectly.
Then I sent to my friend who didn't have Visual Studio. It said that it needs "msvcp140d.dll" "ucrtbased.dll" "vcruntime140_1d.dll" "vcruntime140d.dll" to open it.
Then I found them in my computer, put them in the same dir with my application, and sent them to my friend. It worked fine, too.
But My question is "Is there any way to pack them with just Visual Studio 2019?" A small application with lots of DLLs is just a little bit weird.
First you're sending the wrong files. Files with d suffix like that are for debugging only and must not be distributed
You cannot redistribute all of the files that are included in Visual Studio; you are only permitted to redistribute the files that are specified in Redist.txt or the online "REDIST list." Debug versions of applications and the various Visual C++ debug DLLs are not redistributable. For more information, see Choosing a Deployment Method.
Determining Which DLLs to Redistribute
Final executable files must be compiled in release mode and use the release version of those DLLs. Don't give out debug binaries. They're seriously slow due to the logics added for debugging purposes
And you don't actually need to send the DLLs but you should tell the user to install the corresponding VC redistributable package. It's the runtime (CRT) for Visual Studio projects containing functions like printf, memcpy... for you. You don't need to find any other DLL if you don't use any DLLs in the project
It's also possible to link the runtime library statically by changing the option /MD to /MT. That way the final exe file will be self-contained (no need for additional runtime DLLs) but it'll also be larger and you lose the ability to use the newer library functions when the package is updated to fix bugs or performance issues. Again, you must compile in release mode regardless of whether you're linking statically or dynamically
See also
Compile to a stand-alone executable (.exe) in Visual Studio
Compile C in Visual Studio 2012 without MSVCRT runtime
How to make a Single Executable VS 2010
Is there any way to compile some Windows API code without installing any development environments to Windows?
Does Windows come with a C Compiler built in that I could just write some code in notepad, and run it through a cmd or a batch file?
.NET includes a command line compiler for C#. (not exactly what you asked for, but it might suit you.) I believe .NET is preinstalled on modern versions of Windows. Look in the folder \Windows\Microsoft.NET\Framework\v4* and see if you have a file called CSC.EXE. This is the command line compiler for C#.
See
"How can I compile a .NET project without having Visual Studio installed?"
Working with the C# 2.0 Command Line Compiler
Is it possible to install a C# compiler without Visual Studio?
For more information and examples.
You can also get the free version of Visual Studio that supports C++. Download Visual Studio Community 2013
No version of Windows I am aware of comes with a C compiler.
No, Windows does not come with a C compiler.
And I don't mean to sound patronizing, but why do you think it'd make sense for it to come with one? Sure, it'd be handy --- if it were a decent compiler --- but beside that, it is not required for normal OS operation. An optimizing compiler is a complex piece of software that would not see any use at all from most users (since most users aren't developers --- and even they might prefer using a compiler of their choice instead of something that just happened to be around).
I should note that at least some Linux distros also come without a compiler by default (as long as it's not needed as a dependency for something else --- which, granted, can happen easily).
As others have pointed out, Windows does not come with a preinstalled C compiler. There are several good free one available for download (including a freeware version of microsoft visual c), but that does not mean you can't access with Windows API/SDK.
If you need to make API/SDK calls without the requirement you install anything, you can use Windows Script Hosting https://en.wikipedia.org/wiki/Windows_Script_Host. It supports a number of languages out of the box, such as Jscript, VBScript, and has the ability to add even more options. Using Windows Script Hosting you can create any call you require into the Windows API/SDK.
Newer versions of windows have started to move towards powershell which is even more powerful -- but is not yet universally available which might mean having to install addition software (which I assume is what you are trying to avoid).
I think you may want Visual Studio Express.
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
You do not mention which version of Windows. Also Windows API calls are customarily built with Visual C++. Although you could build with C# or VB.NET and wrap the calls. As another poster mentioned, if your version includes a .NET, then there are command line building tools available
The situation
I have an app created in Visual Studio 2013 written in C. It work flawlessly on my computer (Windows 7) and on other Windows 7 computers that I have tested the app on.
The Issue
In order for my app to work, Microsoft Visual C++ Redistributable has to be installed otherwise a couple of other .dll files are needed (MSVCR120.DLL for example). When I tried this on Windows XP I confronted with the following error:
C:\path\to\app.exe is not a valid Win32 application
and found no way of solving that.
The Question
How can I solve all the problems and have a single .exe file that works on any Windows system regardless of its configuration without the need of extra files or an installer?
Bonus Question
What are these MSVCR***.dll files?
You can statically link to the vc runtime and that should eliminate the need for installing dependencies. Note that the .exe will be larger because the dependencies are compiled in.
Set /MT for Release and /MTd for Debug in Project Settings -> C/C++ -> Code Generation
You can also set v120_xp in General -> Platform Toolset for your program to be able to run in Windows XP (http://supportxpdotcom.wordpress.com/2013/07/16/xp-targeting-support-in-the-visual-studio-2013-preview/)
The MSVCR*** files are C run-time library files that hold the functionality for C run-time functions used in a program. When you statically link a program, you compile them in to the .exe and so don't have to distribute them separately. (http://msdn.microsoft.com/en-us/library/aa272081(v=vs.60).aspx)
I have VS.NET 10.0.40219.1 SP1 in 2 computers and when I create a new C# Winform app only do it with Properties/Build/Platform x86, and the target let me choose AnyCpu/x64, but can't set it in the configuration (however, libraries work fine).
If I try to change it in the project file manually, I get a lot of nasty errors. Is this normal behavior, a bug or a problem in my installation?
P.D: When I change manually the project, this happend:
Warning 1 The OutputPath property is not set for project '*.csproj'.
Please check to make sure that you have specified a valid combination
of Configuration and Platform for this project. Configuration='Debug'
Platform='x86'. This error may also appear if some other project is
trying to follow a project-to-project reference to this project, this
project has been unloaded or is not included in the solution, and the
referencing project does not build using the same or an equivalent
Configuration or
Platform. c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets
When I reopen the project, ALL the references become invalid
It is normal for Visual Studio to create WinForms projects with just an x86 platform. I have no idea if that's because historically x86 was the only platform type or because x86 is the most commonly used value or for some other reason.
It's also normal to have problems when the project file is manually modified, try to avoid doing that where possible.
To create another platform configuration in a C# project
Select Build | Configuration manager
Select <New...> in the Active Solution Platform field
Select the new type you want
Click on OK
Visual Studio used to create AnyCPU apps by default. I think both VS2005 and VS2008 did this, though they may have changed it for VS2008. Here's what happened: a lot of AnyCPU apps ended up broken on 64-bit systems, because they were built with dependencies on 32-bit libraries. If you tried to run an AnyCPU app that had a 32bit dependancy on a 64bit system, you got a 64bit process that would crash as soon as it tried to load your 32bit dll.
To fix this, the default was changed to use the x86 option. If you want to use AnyCPU, you must now setup the environment for it.
I created a WPF project in VS2008 and compiled it with Any CPU, x64 and x86. Any CPU and x64 works, but compiling to x86 the application is hanging when running through VS2008 and crashing when running without debugging. Debugging it with WinDbg I can see a StackOverflowException and sometimes a MissingMethodException relating to WPF methods.
Common sense is telling something here that the CLR is not loading the correct assemblies or something when running 32bit WPF apps. I tried reinstalling .NET Framework 3.5 SP1, but it does not fix the problem. I don't know how to go about checking if the correct assemblies are loaded or used.
Any ideas?
UPDATE: Not a real solution but the best I could do quickly was to reinstall Windows 7
Try to force the right compiler in all projects of your solution :
Properties
Build
Platform target
Try forcing Windows to always use the 32bit CLR and see if it still crashes:
C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\Ldr64.exe setwow
-Oisin
I think I ran into this issue also. If I remember correctly, I had a problem where a dependency was compiled for x86 and the main app was compiled for x64, or the other way around. i.e. say I had a library and an app with a main function. I think they both need to compiled the same way. i.e. I don't think you can mix and match. This might not have been the exact same issue. I would go through all the projects in the solution make sure they all have the same settings.