I have developed a Win32 Console app DLL and a small tester application for it. As far as I know neither uses MFC, .COM, .NET or dot-anything else. Development platform is VS2009 on WinXP/SP3
When I give the DLL and EXE to someone else, they are unusable. Attempting to use them generates errors similar to "Application cannot be used, the application configuration is wrong." and "cannot find xxx.dll" (not exact wording on these error messages).
I have learned from reading that there are dependencies that must ship with the EXE and DLL. These dependencvies seem to be specific to VS 2009 abd should include the MSVCRT09, etc.
When I followed MS's instruction to make a setup.exe/MSI installer for a Setup and Deployment Project (http://msdn.microsoft.com/en-us/library/ms235317%28v=VS.90%29.aspx) I add the dll to the project, move it to the "MyLibrary" folder and no dependencies are found or listed in the Solution Explorer. Yet, I know there are dependencies, DEPENDS.EXE says so.
Can anyone walk me through this or name a better site with instructions. Once again, MS's help isn't all that helpful.
thanks,
Wes
Visual Studio 2008 is version 9.0. A program built with Visual C++ 2008 normally does have dependencies on the C run time library MSVCRT09, as you discovered. If the C run time library is not installed on the destination PC (either already installed or as part of your setup project) then your application fails, as you discovered. It is no surprise that DEPENDS.EXE displays the dependency. The only question seems to be why Visual Studio 2008 doesn't display the dependency in its Solution Explorer window.
Before building your Visual Studio setup project (MSI and setup file), Visual Studio might not have had any reason yet to search for dependencies. But after the setup project is built, in my experience the Solution Explorer does show the dependencies it found, next to other dependencies that you set explicitly. If those don't show up after building, something is weird.
Related
I have moved from VS2015 to VS2019. I've created a deployment and all is good locally, here on three machines. But when I shipped a test MSI out to an old laptop we got an MFC140.dll not found. I found the dependency in one of my dlls, thought it had something to do with not moving it up to UNICODE. Did that and it still depends on MFC140U.dll
I do have
toolset (VS 2019)vs142
SDK Version 10.0(latest installed)
I've googled and pulled hair out. But the lights are not coming on. Checked, and this is also happening to a second dll I build.
So I check another app that goes into the deployment. It does not use any of my dlls. Yet it also depends on MFC140U.dll as well as MFC142U.dll. The only libs linked in this one are BOOST and SQLITE3. And those don't have any MFC dependencies. This just adds to my confusion.
The only thing that would make sense to me is that a vs142 build has some 140 dependency and the deployment system is not picking that up. Note that deployment is not done with install shield as was done with vs2015.
Yes, I could fix it by shipping the MFC140U.dll but that just does not seem right. Either I, or Microsoft, has something wrong is all I can figure.
UPDATE:
I created a fresh MFC project with VS2019 and looked at the depends. Same thing, this is about Microsoft. And it looks like the deployment system includes MFC142x dlls but not the MFC140 that is required.
You don't mention what your "deployment system" is, so I'm not sure what installer technology you are using here.
But your application or one of your DLL's has a dependency on MFC. If MFC isn't needed, you'll want to check your build settings on the exe or dll in question. The other item to check is if you are errantly including the afx.h header in your project. The afx.h has #pragma comment(lib, xxx) entries that resolve to the proper mfc140xxx.lib depending on your build options.
If the MFC dependency is legitimate, you should be installing the VC runtime components using the vsredist packages designed for just that purpose. These should be installed to your hard drive under a path similar to C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.21.27702
Alternatively, you can download the latest using the following link:
The latest supported Visual C++ downloads
Sincerely,
I am able to run my app through the VS2010 environment. But cannot make it working as a stand-alone exe (to run it just by double click on exe). I don't know what files are required.
In VS in Additional Dependencies I have:
d3d11.lib
d3dcompiler.lib
d3dx11d.lib
d3dx9d.lib
dxerr.lib
dxguid.lib
winmm.lib
comctl32.lib
I tried to copy these files to the same directory where my exe is:
d3d11.dll
d3dcompier_43.dll
d3dx9d_43.dll
d3dx11d_43.dll
I also tried to find some dependencies, but the dependency walker crashes with some errors. So I used dependency scanner in InstallShield 2010, it said:
d3dx11d_43.dll
Microsoft (R) C Runtime Library
Microsoft OLE 2.40 for Windows NT(TM) and Window 95(TM) Operating Systems
VC User gdiPlus RTL X86
What are the last three things? What else can I do?
// EDIT
The app has been created by using DirectX SDK June 2010, so I have installed the DX End User June http://www.microsoft.com/en-us/download/details.aspx?id=8109 .
However, the app is working throught the VS2010, but the stand-alone exe (on the same computer) doesn't work, so I think the DX End User wasn't even necessary if I had SDK (the Visual C++ Redist was installed too).
I also tried to create a setup via VS2010, it copied these files:
COMDLG32.dll
d3d11.dll
d3dx11d_43.dll
IMM32.dll
MSIMG32.dll
OLEACC.dll
oledlg.dll
but it still doesn't work (while clicking on the exe it always displays the: Program xyz has stopped working. Windows can find a solution to this problem online. Find/Close/Debug buttons.)
Maybe it is something with the MFC?
Instead of just copying those DLLs, you'll need to install the DirectX End-User Runtime (the correct version, matching your development environment) on the user's system, as well as the Microsoft Visual C++ Runtime.
I wrote a tool that many users would use on their computers. I noticed however, that users who do not have visual studio installed, cannot open my executable. The error says that msvcp100.dll is missing. I found in internet a redistributable package from microsoft, that should apparently provide these dlls. My question is: is there another way to bypass this problem? Something like an option in the project properties?
Yes, you can change a compiler setting to link the C++ standard library classes into your program instead of having a dependency on the DLL. Right-click your project in the Solution Explorer window, Properties. Switch to the Release configuration (upper left). C/C++, Code Generation, Runtime Library setting. Select /MT.
Only do this when you only have a single monolithic EXE. When you use your own DLLs then you really need msvcr100.dll and msvcp100.dll so that the runtime library gets shared between all modules.
It is part of C++ runtime and the target machine needs it. THere are couple of ways to address it.
Please check following link from Microsoft MCVCP100.DLL
I'm not a a very experienced Windows developer, so I hope this all makes sense.
I created a Managed Assembly DLL using Visual Studio 2010. The DLL (Plip.dll) contains a C++ class that is using System.IO.SerialPort class to do some simple communication over a serial port.
In a second Visual Studio project I created a simple GUI that uses the class found in Plip.dll. In my GUI project I have the line : #using "Plip.dll" . In the Project Properties I set the 'Resolve #using References' value to the correct location of Plip.dll. The GUI builds just fine. If I copy the GUI.exe and Plip.dll to the same folder, the GUI runs just fine on my computer.
The problem I am having is that when I copy both files to a second computer, I cannot get the GUI executable to run. I get the following error : "System.IO.FileNotFoundException. Could not load file or assembly "Plip.dll" Vesion=.... ". I get this error even though both the exe and dll are located in the same folder.
Any suggestions on how to resolve this issue? Is there some option I need to set in my GUI project to load the DLL correctly at run time?
I suppose the problem is not the Plip.dll, but it's dependencies.
Use Dependency Walker on the second computer to see if it needs any other dll's (they might be installed in System folder or in %PATH% on your development computer, but not on the other).
If this second computer doesn't have Visual Studio installed, you are probably missing Microsoft Visual C++ 2010 Redistributable Package (you need to install it on the other computer)
Also make sure that you compile in Release because debug builds need debug dependencies.
I found the answer to this problem to be much simpler than Dependency Walker (but admittedly, that was fun to look at).
In my case, the issue was a mis-match between the .DotNet versions in the DLL and with the application's .net version. This was caused by building the "class library" using .DotNet 6.0 (dot net core?).
Instead, the entire class needed to be re-built using "Class Library (.NET Framework)"
enter image description here
I wrote an article on this problem.
https://keyliner.blogspot.com/2022/09/visual-studio-c-linked-dll-exception.html
Where can I find some official note, kb article or other documentation describing changes to the Visual Studio 2010 C/C++ runtime linking and deployment policy?
Under Visual Studio 2008 (with the VC90 runtime) a manifest was embedded in native images, and the runtime libraries were deployed as side-by-side assemblies (WinSxS). This caused problems when rebuilding a native exe or library using VS 2008 SP1, in that an updated version of the C++ runtime was required by the embedded manifest.
For VS 2010 and the MSVCR100 runtime version, the policy seems to have changed completely.
The file msvcr100.dll and the other C/C++ runtime libraries are no longer install as SxS assemblies.
When compiling under VS2010, no runtime 'dependency' entry is added to the embedded manifest, meaning that any version of msvcr100.dll might be loaded at runtime.
On machines with .NET 4 installed, the matching runtime is named msvcr100_clr0400.dll, and won't be loaded by native code, though a copy renamed to msvcr100.dll works fine. I think this means any process with C/C++ code will always have two versions of the same C/C++ runtime loaded.
This seems to be a significant change in policy, backtracking from the SxS deployment and manifest dependencies we had under VS 2008. Could anyone shed more light on what changed, and perhaps point to some documentation, a readme or blog post that describes these changes, the motivation and related impact?
It think it's better this way - the strong version manifest and SxS deployment was a nightmare - but I'm surprised at these unexpected and seemingly undocumented changes in VS 2010.
Bonus question: How can I compile my C++/CLI library under VS 2010 to link to msvcr100_clr0400.dll instead of msvcr100.dll? This idea is that the C++/CLI assembly should run with no dependencies other than that installed by .NET 4 (without static linking).
You already answered most of your question, the side-by-side deployment of the CRT was a nightmare that got way too many programmers in trouble. Microsoft agreed and gave up on it for the VS2010 release. It's back to a DLL in c:\windows\system32, named msvcr100.dll. And msvcp100.dll, vcomp100.dll, atl100.dll, mfc100.dll, mfcm100.dll, the other runtime support DLLs. The way it was for VS2003 and earlier editions. Now it is again the user's burden to sort out a DLL Hell problem. The person least likely to be able to do so but they do tend to have a budget to pay for support. Unlike programmers that need to get help from a free web site :)
But you can help, app-local deployment is now again enabled, you can deploy msvcr100.dll in the same directory as your main EXE. That was explicitly checked and forbidden in previous versions. App-local has some niceties, it isolates you from well-meant but unfortunate updates that break your app. Albeit that you are now yourself responsible for getting updates deployed that fix a security hole. If that's uncomfortable then deploy and rely on the copy in the system directory.
Do not try to link to msvr100_clr0400.dll, that's a private copy for use by the CLR. Much like msvcr.dll is a private copy for use by Microsoft DLLs. You don't have the .lib file you need to link to these DLLs.
Just a couple of links about the topic – I hope someone will find them useful:
Visual Studio 2010 changes for VC++ (part 5)
Visual C++ Application: How to use manifests and re-distributable assemblies?