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,
Related
I have a problem with our executable. I'm running this C++ 32-bit executable on my Windows 7 64-bit development box that also has all those Microsoft applications (Visual Studio 2008 + 2010, TFS, SDK, Microsoft Office)...
And it's still running just fine.
Now I got the client installation of the very same program and was asked to test it with a clean Windows 7 installation. Thus I got one Windows 7 64-bit VMware and updated it to Windows 7 SP 1 (the very same version my developer box is tuning).
But while on my developer box everything is fine the program does not work with the VMware (30 days trial) box.
The x86 Dependency Walker is telling me that the following DLL files are missing:
API-MS-WIN-CORE-COM-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ERROR-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-ROBUFFER-L1-1-0.DLL
API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL
API-MS-WIN-SHCORE-SCALING-L1-1-0.DLL
DCOMP.DLL
GPSVC.DLL
IESHIMS.DLL
I googled for those API-MS-WIN-... DLL files and found they should actually already be part of Windows 7 (some sites claiming the belong to Windows 8 and Windows Server 2012 though).
I already tried the suggested fixes I found, which are:
running 'sfc /scannow'
installing Visual Studio 2008 SP1 runtime executables
But that didn't solve anything. :-(
Side note: My development box does not have them either, and does not seem to need them. For example, the user32.dll on my box does not link against one of those, while the installation on the VMware does.
Any idea on how to fix this issue?
I tried to find a suitable download / fix on the Microsoft pages, but I failed.
After solving my issue I wanted to report what I found out, and I can't post this as an answer because the question has been closed.
Actually all the DLL files reported missing by the Dependency Walker tool, namely those
* API-MS-WIN-CORE-...
type DLL files were not part of the actual problem.
In my case the registration of three OCX files was missing and after that everything was just fine, BUT Dependency Walker tool still listed all the very same DLL files as before even when the program was just running fine now.
The gist of it: As someone elsewhere stated, the tool is a bit dated by now and does not always work properly with a newer OS. Thus keep an eye open and don't get mislead by missing 'API-MS-WIN-CORE-COM-L1-1-0.DLL', ... the problem probably lies entirely elsewhere.
This problem is related to missing the Visual Studio "redistributable package." It is not obvious which one is missing based on the dependency walk, but I would try the one that corresponds with your compiler version first and see if things run properly:
Visual Studio 2015
Visual Studio 2013
Visual Studio 2010
Visual Studio 2008
I ran into this problem because I am using the Visual Studio compilers, but not the full Visual Studio environment.
Going to dare to inject a new link here: The latest supported Visual C++ downloads. Stein Åsmul, 29.11.2018.
I just resolved the same problem with C++ Qt 5 and Windows 7 64 bits with MSCVC 2012.
In the beginning I thought it was a MSVC/Windows DLL file problem, but as BorisP said, the problem was in my project dependencies. The key is "How to know your project dependencies in Qt 5?".
As I didn't find any clear way to know it (Dependency Walker didn't help me a lot...), I followed next the "inverse procedure" that takes no more than 5 minutes and avoid a lot of headaches with DLL file dependencies:
Compile your project and take the executable file to an empty folder: myproject.exe
Try to execute it, It will retrieve an error (missing DLL files...).
Now, copy all the DLL files from Qt (in my case they were in C:\Qt\Qt5.1.1\5.1.1\msvc2012_64_opengl\bin) to this folder.
Try to execute again, it will probably works fine.
Start to delete progressively and try every time your executable still works, trying to leave the minimum necessary DLL files.
When you have all the DLL files in the same folder it is easier to find which of them are not valid (XML, WebKit, ... whatever..), and consequently this method doesn't take more than five minutes.
I just resolved the same problem.
Dependency Walker is misleading in this case and caused me to lose time. So, the list of "missing" DLL files from the first post is not helpful, and you can probably ignore it.
The solution is to find which references your project is calling and check if they are really installed on the server.
#Ben Brammer, it is not important which three .ocx files are missing, because they are missing only for Leo T Abraham's project. Your project probably calls other DLL files.
In my case, it was not three .ocx files, but missing MySQL connector DLL file. After installing of MySQL Connector for .NET on server, the problem disappeared.
So, in short, the solution is: check if all your project references are there.
As mentioned, DCOMP is part of the VC++ redistributables (implementing the OpenMP runtime) and is the only truly missing component. All the rest are false reports.
Specifically API-MS-WIN-XXXX.DLL are API-sets - essentially, an extra level of call indirection introduced gradually since Windows 7. Dependency Walker development seemingly halted long before that, and it can't handle API sets properly.
So there is nothing to worry about there. You're not missing anything more.
A better alternative to find the truly needed DLL files that are missing (if that is indeed the problem) is to run Process Monitor and step backwards from the failure, searching for sequences of failed probes for a specific DLL file in all the system path.
I also ran into this problem, but the solution that seems to be a common thread here, and I saw elsewhere on the web, is "[re]install the redistributable package". However, for me that does not work, as the problem arose when running the installer for our product (which installs the redistributable package) to test our shiny new Visual Studio 2015 builds.
The issue came up because the DLL files listed are not located in the Visual Studio install path (for example, C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist) and thus had not been added to the install. These api-ms-win-* dlls get installed to a Windows 10 SDK install path as part of the Visual Studio 2015 install (e.g. C:\Program Files (x86)\Windows Kits\10\Redist).
Installing on Windows 10 worked fine, but installing on Windows 7 required adding these DLL files to our product install. For more information, see Update for Universal C Runtime in Windows which describes the addition of these dependencies caused by Visual Studio 2015 and provides downloads for various Windows platforms; also see Introducing the Universal CRT which describes the redesign of the CRT libraries. Of particular interest is item 6 under the section titled Distributing Software that uses the Universal CRT:
Updated September 11, 2015: App-local deployment of the Universal CRT is supported. To obtain the binaries for app-local deployment, install the Windows Software Development Kit (SDK) for Windows 10. The binaries will be installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt. You will need to copy all of the DLLs with your app (note that the set of DLL files are necessary is different on different versions of Windows, so you must include all of the DLL files in order for your program to run on all supported versions of Windows).
This contribution does not really answer the initial question, but taking into account the hit-rate of this thread I assume that there are quite a few people dealing with the problem that API-MS-WIN-CORE- libraries cannot be found.
I was able to solve a problem where my application refused to start with the error message that API-MS-WIN-CORE-WINRT-STRING-L1-1-0.DLL is not found by simply updating Visual Studio.
I don't think that my build environment (Windows 7 Pro SP1, Visual Studio Ultimate 2012) was messed up completely, it worked fine for most of my projects. But under some very specific circumstances I got the error message (see below).
After updating Visual Studio 11 from the initial CD-Version (I forgot to look up the version number) to version 11.0.61030.00 Update 4 also the broken project was running again.
This solved the issue for me:
Uninstall the Visual Studio 2010 redistributable package if you have it installed already, and then install Microsoft Windows 7 SDK.
I solved the problem. When I registered the OCX files, I ran it with the Command Window that had been executed as an administrator.
For anybody who came here, but with a Photoshop problem: my solution was to uninstall the MS VC++ redistributable first x86 and 64 both. Then install one appropriate to the Windows version and architecture (86 or 64).
Installation of SQL Server Management Studio 2014 on a freshly installed Windows 7 resolved this problem at our client after a two-day ridiculous battle.
I came here with this problem occurring, after trying a fresh Windows 7 OEM install, upgrading to Windows 10.
After some searching of Microsoft forums and such I found the following solution which worked for me:
Replace C:\Windows10Upgrade\wimgapi.dll with the one from C:\Windows\System32\wimgapi.dll
I suggest also checking how much memory is currently being used.
It turns out that the inability to find these DLL files was the first symptom exhibited when trying to run a program (either run or debug) in Visual Studio.
After over a half hour with much head scratching, searching the web, running Process Monitor, and Task Manager, and depends, a completely different program that had been running since the beginning of time reported that "memory is low; try stopping some programs" or some such. After killing Firefox, Thunderbird, Process Monitor, and depends, everything worked again.
I had the same problem. After spending hours searching on the web, I found a solution for me.
I copied the file combase.dll file (C:\Windows\System32) to the release folder, and it resolved the problem.
Just to confirm answers here, my resolution was to copy the DLL that was not loading AND the ocx file that accompanied it to the system32 folder, that resolved my issue.
How can I deploy my Win32 application as an EXE application so that others (who don't have VC++ installed) can use it?
I am using VC++ 2010 on Windows 7.
If you switch to "Release" mode when you compile your finished program (rather than "Debug", which you use for debugging it during development), you should get an executable that will run on a computer without Visual Studio installed.
However, that executable will still require the appropriate version of the C runtime library to be installed. For example, if you developed it in Visual C++ 2010, you will need version 10 of the CRT installed. This is a freely redistributable library, downloadable here.
So, you have several options for deployment:
Manual Deployment
Give people the bare executable file, and include the installer for the redistributable in another folder on the installation media. If they copy the executable to disk and cannot run it because they get an error message, they should install the CRT libraries from the included redistributable installer. Then the executable will run just fine.
This works great if you have relatively a computer-savvy audience, or you're deploying to a fixed range of machines (like across a school or corporation). But it doesn't work so well for general deployment to customers.
In fact, you don't even need the installer. You can just place the CRT DLLs in the same folder as your executable and it will run just fine. This is how I test apps I'm developing on clean VMs. It works like a charm. There's no need to run the CRT installer at all. You'll find these required libraries as part of your Visual Studio installation:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\x86
Automated Deployment
Create a setup program that automatically installs your application along with any dependencies it requires, including the CRT redistributable. This is what you see most commercial applications doing. I recommend it for anything but the most trivial of apps.
Full versions of Visual Studio 2010 (i.e., not Express versions) can create a Setup Project that you can customize as needed to work as an installer for your application. But this is no longer the recommended way to create an installer, and this functionality has been removed from the latest version of Visual Studio, 2012.
So I recommend using something else, even if you have an older version of VS where the Setup Project is available. No point in wasting time creating something you'll just have to update later. My personal favorite choices for creating setup programs are WiX and Inno Setup. Both are free, and extensive documentation is available online.
Creating simple setups that don't have to do very much is really quite straightforward—this is likely the case for you, as all you need to do is install the CRT redistributable if it is not already there. I'd be willing to bet money you can find a walkthrough or example online for how to do this in either WiX or Inno Setup.
If you need to do more complicated stuff, both of these setup packages support it. They are extensively customizable and very powerful, it just takes more work to get it all going.
Static Linking
If you absolutely need to be able to distribute a bare executable that is guaranteed to simply work when double-clicked, you will need to switch your project to statically link in the required runtime libraries. This means that all of the CRT code is actually embedded by the linker directly into your executable, and means that you don't have to redistribute the CRT libraries separately.
The disadvantage of this approach is that the only way to benefit from improvements, bug fixes, and security patches released for the CRT is to recompile and redistribute your application. If you dynamically link (the default), your app will automatically benefit from enhancements to the installed version of the CRT libraries. Microsoft strongly recommends against static linking.
To switch between these modes in Visual Studio, follow these steps:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Release" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to "Multi-threaded (/MT)".
A further description on what these cryptic compiler switches mean and which ones you should use when is given in my answer here.
Final Note: The "Debug" versions of the CRT libraries are not redistributable, but that doesn't matter because you should always distribute the "Release" build of your app anyway, never the "Debug" build.
In general, the odds are pretty good your EXE file will run on any version of Windows you built it on or higher.
All bets off, for example, if you built using Visual Studio 2012 Professional on Windows 7, and you try to run it on Windows 95. But otherwise, you're probably safe :)
The best way to test if you have any dependencies is to install and run on a "clean machine".
The best way to get (and reuse) a "clean machine" is with a VM.
I recommend VMWare. But Virtual Box and Windows Virtual PC are also viable choices.
As far as an installer, I'd strongly encourage you to look at InnoSetup
I hope that helps!
Make sure you build in release mode. As Floris Velleman said, you're using unneeded libraries for standalone executable.
For more information, you can check Compiler Options (MSDN).
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.
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?
I'm attempting to find the minimum installation requirements for getting WP7 projects compiling on a Windows 2008 R2 build server. I'll be looking into automated testing using the emulator at a later point, but right now I'm stuck on the build side.
I realise this approach won't be supported and I'm willing to trash the VM at a later date if an update proves to be incompatible (assuming I get it to work at all)
I'm also aware of the workaround for installing the entire SDK on Windows 2008 R2, but I'm trying to avoid installation of Visual Studio (it's now become a curiosity more than anything else)
As it stands, I've installed the following from the SDK ISO:
WCU\Silverlight4\silverlight_sdk.msi
WCU\WindowsPhone\WindowsPhoneExtensions.msi
WCU\WindowsPhone\VS_SDEProLightup-enu.msi
At this point, it is able to locate all the required MSBuild target files and even compiles the project. The problem appears at the end of the process during the XapPackager target, when it errors with:
Xap packaging failed. Unable to load DLL 'zlib114.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
Using Process Monitor, I can see that MSBuild finds the dll in the WP7 MSBuild targets directory that installs with the SDK with the only error being "FILE LOCKED WITH ONLY READERS" error to a CreateFileMapping+SyncTypeCreateSection, which it then falls back to a SyncTypeOther, which succeeds. Despite this, MSBuild still continue to look for the dll is all the other standard locations (Framework directory, SysWOW64, etc).
Any thoughts to why it might be failing?
If you're using TFS, Justin Angel has a great post on TFS2010 WP7 Continuous Integration. Given that TFS is just wrapping around MSBuild, you may find this a particularly useful resource. When it comes to doing the unit test integration, Deyan Ginev from Telerik has a series of posts that covers this.
FYI, I ended up fixing the zlib problem by using the dll from the Silverlight SDK, rather than the WP SDK.