0

I developed previously a C++/CLI dynamic library project using Visual Studio 2010 that I'm using it as an ANE on an Adobe Air application. The previous version of the DLL used to be compatible with Windows 7 and Windows 7 SP1 out of the box (without the installation of any additional stuff). Now, on the new version, when I tested it on three Windows 7 SP1, an error appeared mentioning that the MSVCR100.DLL is not installed on the current computer. I didn't change anything on the project but the main .cpp file, so I don't understand how can this be.

The following namespaces were used (added) in the new version:

  • using namespace System::Diagnostics;
  • using namespace System::Net::Sockets;
  • using namespace System::Threading;

The following classes were used (added) in the new version:

  • NetworkInterface
  • System::Collections::IEnumerator
  • IPInterfaceProperties
  • GatewayIPAddressInformationCollection
  • GatewayIPAddressInformation
  • AddressFamily::InterNetwork
  • UnicastIPAddressInformation
  • ProcessStartInfo
  • Process
  • ThreadCommand
  • Thread
  • ThreadStart

Could one of these classes make my DLL need the MSVCR100.DLL to be installed on the computer? Why did the DLL sudenly started requirering the MSVCR100.DLL? Does someone know?

I've tried changing the Runtime Library from Multi-threaded DLL (/MD) to Multi-threaded (/MT) as many posts comment but when trying to build on Visual Studio the following error appears: '/clr' and '/mtd' command-line options are incompatible. So this option has not been viable.

If anyone can tell me how to solve this problem I would be really gratefull. Of course, the solution can't be to install the C++ 2010 Redistributable. I need it to be a clean solution with no extra requirements for my end user.

Storo
  • 988
  • 1
  • 7
  • 31
  • 1
    You *always* need msvcr100.dll when you deploy a C++/CLI project. It is a file that is often already available, not always. So just make sure you always take care of it so it never goes wrong. You can use the redistributable installer, just easier to copy the file along with your own DLL. – Hans Passant Nov 26 '15 at 01:35
  • Hello @HansPassant, thanks for replying. If that is the case how was it compatible out of the box on the previous version? – Storo Nov 26 '15 at 11:25
  • 1
    As I said, there are a lot of computers that have msvcr100.dll already present in c:\windows\syswow64. Put there by somebody else's friendly installer. You cannot depend on that kind of friendliness. Telling the user to download and install the redist installer, meh, you can ask but you'll typically get a phone call anyway. Make it "clean" by simply deploying the DLL along with the rest of your executable files. Easy peasy, nothing to fret about. – Hans Passant Nov 26 '15 at 11:36
  • @HansPassant My app is completely portable so it does not use an installer, it's just shipped as a zip . Is there a way to deploy the 32bit msvcr100.dll and the 64bit msvcr100.dll inside the same zip file or should I have two different zip files, one for 32 bits and one for 64 bits? – Storo Nov 26 '15 at 11:59
  • It must be the same flavor as your C++/CLI assembly. Which contains unmanaged code so you only consider this if you actually build two different versions of the assembly. A little birdy tells me that you don't do this. If you do then two different .zips is the obvious approach. Just as you'd need two different installers. – Hans Passant Nov 26 '15 at 12:07
  • @HansPassant I just copied the msvcr100.dll and msvcp100.dll from a 64bit computer and a 32bit computer and pasted them in two different zip files. I got them from "Program Files" and "Program Files (x86)". When testing them on the test PCs the app didn't launch and the error "App stopped working" apeared. I though it would solve the problem but clearly it didn't. – Storo Nov 26 '15 at 12:22
  • Lots of reasons for your app to crash, little reason to assume it is because of the DLL. Writing an event handler for the AppDomain.CurrentDomain.UnhandledException event so you can diagnose the crash is never really optional. – Hans Passant Nov 26 '15 at 12:45
  • @HansPassant You were right. This was a related but different issue. I removed the code a particular function and after pasting the MSVCR100.DLL and the MSVCP100.DLL files on the exe's directory, the app worked. Please post your comments as an answer so I can give you the point for solving my problem. Also, since I still have the problem regarding the function I had to erase to make it work -but I still need- I created a new question. If you could take a look at it I'd appreciate it: http://stackoverflow.com/questions/33941270/section-of-the-code-of-our-c-dll-crashes-wen-ran-on-a-windows-7-sp1 – Storo Nov 26 '15 at 14:41

0 Answers0