$Adam

I've run into the problem of the missing DLL. So I'm building my external with Visual Studio 2010, which links the file automatically with msvcp100.dll. However, as I've seen, the Max installer installs the msvcp7* versions of Visual C. So what is the recommended/preferred way to overcome this problem?

2) Link against the old files using current VS? (I'm not sure how this should be done, anyway...)

3) Include the missing Microsoft DLLs in my release?

I've run into the problem of the missing DLL. So I'm building my external with Visual Studio 2010, which links the file automatically with msvcp100.dll. However, as I've seen, the Max installer installs the msvcp7* versions of Visual C. So what is the recommended/preferred way to overcome this problem?
1) Downgrade to an older version of VS?
2) Link against the old files using current VS? (I'm not sure how this should be done, anyway...)
3) Include the missing Microsoft DLLs in my release?
4) Some other solution I'm not aware of?

vs-version-problems-when-releasing-objects-for-windows-using-visual-studio

In Jamoma we use static linking for MS C runtime rather than dynamic linking. It makes the compiled binaries much larger, but also alleviates these runtime linking issues.

In Jamoma we use static linking for MS C runtime rather than dynamic linking.  It makes the compiled binaries much larger, but also alleviates these runtime linking issues.

thanks. In the meantime I've found this interesting paragraph in the docs:

Another thing to note is that Max has a private build of the Microsoft C Runtime Library. By linking with this version of the C runtime library you won't have to worry about deployment issues due to dependencies your external may have on Microsoft's C Runtime. When you include "ext.h" from the max API it will include ext_prefix.h which for the release build will automatically cause your project to use the max C runtime library. If you prefer to use the Microsoft C Runtime you can do that by defining the C preprocessor macro MAXAPI_USE_MSCRT before including ext.h.

The interesting thing is that, although I'm not defining the 

 macro, I'm still getting the dependence on the MSVC DLLs. Does anyone know how to make sure that the object would link with the Cycling '74 version of the CRT?

The interesting thing is that, although I'm not defining the MAXAPI_USE_MSCRT macro, I'm still getting the dependence on the MSVC DLLs. Does anyone know how to make sure that the object would link with the Cycling '74 version of the CRT?

So the weirdness is that my old objects, compiled with MSVC2008, don't have the dependencies on the MS DLLs. The problem must have arisen when I migrated my externals to MSVC2010, although I made no explicit change to any of the files. Now I can see that both the Cycling'74 version and the MS version of the CRT are linked to the built objects, which is somehow weird. But I don't know how to tell MSVC not to link against its own CRT. I've been playing around with some linker settings and googleing around, but I've found nothing.

Could please somebody tell me how this problem was solved in MSVC 2008? Maybe that could give a hint...

For those interested on this topic, I got the explanation, which is at

http://msdn.microsoft.com/en-us/library/abx4dbyh.aspx

It turns out that if one uses the Standard C++ Library as well, then MSVC will link against MSVCP*.DLL, too. Since there's no replacement for this file by Cycling '74, both the Cycling '74 CRT (for the CRT) and the MSVCP (for the C++RT) would be linked.

The weirdness is that I've never had any linkage problems while I was using MSVC 2008, although the codebase was more or less the same (my guess is that most of the people using my externals probably had the 2008 versions of MS DLLs already installed on their computers).

Thanks for the info and for being persistent.

We actually have our own build of the C++ runtime as well. If you look in the c74support/max-includes/ folder of the SDK you will find both maxcrt.lib and maxcrt_p.lib.

I expect the problem you are seeing is one of two things:

1. Either you are making a debug build (which would use the MS runtime libs), or

2. Microsoft changed the headers for VS2010 to use different macros to control the inclusion of the CRT.

Please confirm you are making and testing with a Release build. If that is not the problem then we can investigate further if some changes might be necessary for VS2010 compatibility however it might be a while before we can get around to that.

Thanks for the info and for being persistent.  

We actually have our own build of the C++ runtime as well.  If you look in the c74support/max-includes/ folder of the SDK you will find both maxcrt.lib and maxcrt_p.lib.  

I expect the problem you are seeing is one of two things:
1.  Either you are making a debug build (which would use the MS runtime libs), or
2.  Microsoft changed the headers for VS2010 to use different macros to control the inclusion of the CRT. 

Please confirm you are making and testing with a Release build.  If that is not the problem then we can investigate further if some changes might be necessary for VS2010 compatibility however it might be a while before we can get around to that. 

thanks for the feedback. Actually I've completely removed the Debug build options from my solutions since I'm developing on the Mac and I'm only using MSVC to do the windows builds of my already-tested externals. So yes, I'm in Release mode. I'll double check again my property pages, however.

I've also noticed that I didn't have this problem when I was using VS2008, the error affects only those externals that were compiled after I migrated my projects to VS2010 and use the STL. I'm using the Express edition btw, I don't know if that makes a difference (IMHO it shouldn't, but with MS you never know).

VS version problems when releasing objects for Windows using Visual Studio