mfc100u.dll was not found
I just upgraded from VC6.0 to VC 2010 (and wow). However, I made a simple executable (i.e. in release mode) of a blank dialog based application. I did nothing to the program, but build the .exe. I then ran it on a separate computer and got the error that the "mfc100u.dll was not found." The Great and Might Google says that it means the computer was corrupted. Is this true, or am I not compiling my application correctly? Any one have this problem?
Re: mfc100u.dll was not found
Hmmm. . . It appears that I am still compiling the release version despite setting Solutions configuration to release. Frustrating. Oh well, maybe someone else will have a similar problem.
Re: mfc100u.dll was not found
Ok, this has become quite frustrating. I build in release mode. It appears in the release folder and runs on the computer. I put it on another computer, and it immediately begins complaining about missing dll's. This time:
"MSVCR100.dll was not found."
Various sites on the internet hint that these are debugging dll's and that the "release" isn't really a release. What is going on?
Re: mfc100u.dll was not found
Quote:
Originally Posted by
paradoxresolved
Ok, this has become quite frustrating. I build in release mode. It appears in the release folder and runs on the computer. I put it on another computer, and it immediately begins complaining about missing dll's.
You need to install the Visual C++ redistributable runitme libraries for VS 2010.
Quote:
Various sites on the internet hint that these are debugging dll's and that the "release" isn't really a release. What is going on?
That is not a debug DLL.
Visual Studio 2010 is a relatively new product. I'm sure if that other computer is more than a year old, those runtime files files do not exist on that machine, (unless another application created with VS 2010 installed them).
Regards,
Paul McKenzie
Re: mfc100u.dll was not found
I had feared as much. :( The problem I am then facing is that any time I send a program to a user with an older machine, he/she will be confronted with this problem on their end. That is bad news.
Is it possible to statically link these particular files into my application? I'd like to avoid giving the user a headache.
Re: mfc100u.dll was not found
To statically link your application to CRT and MFC, do the following:
- change Configuration Properties/C/C++/Code Generation from Multi-threaded DLL (/MD) to Multi-threaded (/MT)
- change Configuration Properties/General/Use of MFC from Use MFC in a Shared DLL to Use MFC in a Static Library.
That way you can get rid of dependencies but the resulting binaries will be much bigger.
So, as Paul already adviced, a better solution is Redistributing Visual C++ Files.
Re: mfc100u.dll was not found
Quote:
Originally Posted by
ovidiucucu
To statically link your application to CRT and MFC, do the following:
- change Configuration Properties/C/C++/Code Generation from Multi-threaded DLL (/MD) to Multi-threaded (/MT)
- change Configuration Properties/General/Use of MFC from Use MFC in a Shared DLL to Use MFC in a Static Library.
That way you can get rid of dependencies but the resulting binaries will be much bigger.[/url].
Also, it doesn't help much if your app links to some DLLs (i.e. non-Microsoft DLLs) which expect the VC10 redist package to be installed. Libgtk-win32 is one that caught me out recently and libboost (which the OP mentioned he needed, on another thread). Remember also that if you go down the redist route, you'll need to deploy the VC redist package that came with your compiler. Don't make the mistake that I made of grabbing one from the internet (which looked like the right one) but finding out later that it was an older one which wouldn't work..! :blush:
The manifest / redist strategy works very well once you understand what it's all about but it seems to have been poorly publicised. Microsoft is apparently working on a replacement for all this manifest stuff. I hope it's a bit simpler!! :lol:
[Edit...] Incidentally, according to this MSDN article you can place the relevant DLL's in your exe's folder or a subfolder. That would at least prevent your user from needing to install them.