I am using Visual Studio 2010 but has received an external library developed for Visual Studio 2008. If I try to link the library into my program, I get the following error:
Activation context generation failed for "Tutorial.exe".
Dependent Assembly Microsoft.VC90.DebugCRT,processorArchitecture="x86",
publicKeyToken="1fc8b3b9a1e18e3b",type="win3
Is there any way that I can link the library anyway?
From the error message, it seems that you are linking the debug version of the external library that requires the debug version of VS2008 runtime library. Note that Microsoft do not distribute debug versions of their VC runtime library so either you have to
a) Install VS2008 itself so that it installs both debug and release version of VS2008 runtime library into the system.
OR
b) Install VS2008 re-distributable package and use only the release version of the external library in your project.
Related
I am porting an old MFC application from Visual Studio 2008 to Visual Studio 2019.
In the process, an old DLL library has been incorporated into the source code to remove the library building step in development.
Now, this program runs and functions perfectly when debugging in the default Debug configuration; however, in the Release configuration I get:
The code execution cannot proceed because MSVCR90.dll was not found
I imagine this means that MSVCR90d.dll is successfully found in Debug mode, but cannot find the release version of the DLL for some reason.
I've tried all the general steps of downloading Visual C++ Runtime redistributables, changing to statically linked runtime libraries, and most other things found in the first results on Google.
All intermediate versions of Visual Studio are installed locally on the development machine (2008, 2010, 2015, 2017, and 2019).
Is there anything else I could try?
All the speculation can be avoided, if you install Dependency Walker https://dependencywalker.com and see exactly what is missing where and what the differences of the release and the debug builds are.
I'm using Visual Studio 2015 with Universal Windows Project to build it on RaspberryPi 2 (ARM). For my program I need to use the Boost C++ Libraries, is this libraries compatible with Win10 IoT Core ? At the same time, I've linked Boost to Visual Studio 2015 but I've an error when cross-compiling : "LINK : fatal error LNK1104: cannot open file 'libboost_regex-vc140-mt-gd-1_63.lib'"
Need help please.
Thanks,
Azm0g.
The linking error message shows you're trying to reference the the wrong library format(x86 or x64) for your Windows ARM project.
You should be reference the arm build binaries for your Windows IoT project.
Since boost does NOT provide pre-built binaries for Windows ARM yet, meaning it's not yet officially supported.
I also found a nice tutorial on how to compile the boost library targeting ARM with Windows Phone, you may try it yourself.
Notice that not all Win32 APIs are available on UWP, even you're able to build it successfully, you may not have access to all the boost modules nontherless.
I have upgraded my C++ project from VS2008 to VS2015.
The Platform Toolset is set to Visual Studio 2015 (v140). If it matters, the Target Platform Version is set to 8.1.
I built boost using toolset=msvc-14.0 and put the built libraries into the place my project is expecting them.
When I build my project, I get a linker error:
LNK1104 cannot open file 'libboost_thread-vc100-mt-1_43.lib'
Why is it looking for the vc100 library and not the vc140 one?
It's the first project out of 2 that is failing.
In the .vcproj file there is no reference that I can see to vc100.
Linking to boost libraries on Windows is done automatically through auto linking and #pragma directives. The version number it looks to link against is defined in boost\config\auto_link.hpp where it goes through a bunch of #if and #elifs on your MSVC version and if the version is higher than any of the ones it knows about then it just sets the version number to the highest one it knows about. For boost 1.57 that is vc140, for your version of boost that is presumably vc100.
I'm creating a C++ application using Visual Studio 2013 and using libraries such as FMOD and SDL. I'm trying to package the application to run on other machines through the .exe. I have all my library paths correct and dependencies referenced locally, but when I run the .exe on another machine I get the "MSCVP120D.dll not found" error.
I have installed the Visual Studio 2013 redistributable on these test machines (Since it's 120.dll) and yet the error persists.
As far as I'm aware, other than the libraries specified, which all work, I'm only using standard libraries and windows.h.
I have been told another option is to install the dll file locally and link it statically to the CRT, but honestly I don't know enough to know if this is a correct option or not.
For more information, I'm on a Windows 8.1 machine and have tested on Windows 8 and 7, with no success other than on my own machine.
You are compiling your program in debug-mode and linking to the MS C++ debug-runtime.
Change to release-configuration, and either compile it statically or preferably add the Visual C++ Redistributable Packages for Visual Studio to your deployment (the last part is not neccessary if it's already installed).
I uploaded my (VS2013) project folder and provided it to the other members of my team, but when they tried to build/run it, using Visual Studio 2012 they got this error, it also happened on their version of Visual Studio 2013.
The program can't start because MSVCR100D.dll is missing from your computer. Try reinstalling the
program to fix this problem.
They reinstalled VS2010 but no go.
I also tried to statically link my project by using /MT in the Code Generation options but now I get:
Unresolved External Symbol __free_dbg libcmptd.lib cout.obj
....25 more...
How can I get it so my project can be build/ran on my team members pc? How do I resolve the unresolved externals? It seems to happen purely with regular Microsoft files.
You are mixing C++ libraries built with different versions of the compiler (and as we know some of them are linked against debug dynamic version of VC10 runtime library). This is not supported, as different compiler versions have different ABIs.
To fix the mess you need to find libraries built with parameters that match parameters of your project. They should be built:
with the same compiler version (ex. VS 2013)
with the same configuration (Debug/Release)
against the same platform (x86/x64/ARM)
against the same runtime library variant (static/dynamic + debug/release)
You could either try to find prebuilt versions on the web or to build libraries yourself from source codes. Often, you will want to have multiple configuration/platforms for your project and, thus, you will need multiple versions of your libraries.
If your search will not succeed (for example if there is no VS2013 build for a closed source library) you could roll back your project to another version of compiler and to start over.
Any attempts to link incompatible libraries even if somehow succeeded will lead to random crashes.
This message generally states that the dll is referred to directly or indirectly in your application and is missing.
The 'D' at the end show us this is the Debug version of the file, this is DLL file is provided with the Visual Studio 2010 installation. So the MSVCR100D.dll would be provided with the installation of Visual Studio 2010.
Of course, you could be missing other versions 2008 (MSVCR90D) 2010 (MSVCR100D) 2012 (MSVCR110D) or the 2013 (MSVCR120D), each dll is provided according to the Visual Studio version.
There are a few ways to solve this:
Check to be sure that you're compiling all the components of your
project in Release mode. If this does not solve the issue continue
to the next steps.
You could solve this locally by installing Visual Studio 2010 on your
machine. This is not what I would recommend, but it would surely
overcome the issue
You could also download the file from this third party website and
copy it to your projects bin:
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr100d
This option is the LEAST recommended option.
Run dependency Walker and see what file depends on the MSVCR100D.dll
and the try and fix that file in order to break your dependency. You can download depends here: http://www.dependencywalker.com/
Check to be sure that you're project is linking the correct version of
the CRT and any other libraries you may be using (e.g., MFC, ATL,
etc.)
Note: Installing the redistributables alone will NOT solve this problem, since the redistributables only contain the release version of the file MSVCR100.dll (notice no 'D')
Would it be possible that in your project you are somehow using some component/library built with Visual Studio 2010, which requires the MSVCR100D DLL?