Deployment of an application on a machine other than the one used for development

[OP1]

I am running into deployment issues with one of my console applications.

I use a 64-bit XP SP2 machine, MS VS2005, IVF 10.1. My customers have32-bit XP SP2 machines. I build 32-bit applications of course.

My customers cannot run this application (they get the "This application has failed to start because the application configuration is incorrect. Reinstalling application may fix this problem." message).

My customers also do not have administrator rights on their machine, and therefore cannot use the VC++ 2005 redistributable package.

My initial thought was to distribute manually the DLLs I have and have the users place them in the same directory as the application. This however still doesn't work. There is actually something bizzare here. When I open the manifest file for my application, I notice that the version number for Microsoft.VC80.CRT and Microsoft.VC80.DebugCRT is 8.0.50608.0. However, I cannot find anywhere on my machine a set of DLLs with that version number; the versions I have are more recent (8.0.50727.42). Maybe that's why it doesn't work when I provide these more recent DLLs to my customers.
But then, how comes it works on my machine??

Right now I am stuck with this issue, and would really appreciate any insight on this!

Thanks in advance,

Olivier

[DavidWhite]

Olivier,

Can you try rebuilding the DLL's with the Multithreaded (/static) option? This should include all the rquired routines into the DLL so that you only need to distribute the DLL.

David

[OP1]

David,

My application is an executable, not a DLL. It needs specific DLLs (all provided to the user), plus of course the CRT libraries, which I believe are the source of the problem (but I could be wrong, evidently).
My application (and it's associated specific DLLs, created in the same VS solution) are all built with the Debug Multithreaded DLL option; this is a requirement of one of the application specific DLLs.

I have tried many things; including copying the entire content of my winsxs folder in the application directory of my user's machine; to no avail... I am not too familiar with manifests and policies; maybe the solution is there.

Olivier

[Steven_L_Intel1]

The solution is to install the appropriate Visual C++ Redistributable package on the target system. This is needed along with the Intel Fortran DLLs. The error you're getting is due to a mismatch of version of the MSVC DLLs. This is the one you need.

[OP1]

Thanks Steve for your answer - but this will not work since the customers need to have administrative rights to install this package... How can I manually extract the content of this package and send it to my customers?

Plus, I am afraid that a policy file is needed on top of the DLLs, since the application manifest does not refer to the right versions (on my machine). How can I do this?

Olivier

[IanH]

Instructions for doing what is known as an app-local distribution of the VC++ runtime can be found here. You'll need to do the equivalent for the fortran run-time DLL's. This is a really good way of ending up with lots of DLLs of slightly different version scattered all over the place - which can result in a crisis of chaos and confusion down the track.

Some other thoughts, of which you are probably already aware:

• You are not allowed to distribute the debug run-time libraries. Unless your customers are developers with the same version of Intel Fortran and VS installed, I'm not sure if there's any useful point in distributing versions compiled against debug libraries. If the application specific DLL wants the debug runtime then it is broken - if that's in your control you can easily fix it, if its provided by a third party then you should get rather cranky with them - the debug run-time is always going to be slower than the release run-time and precludes you getting all the benefits that using a whiz-bang optimising compiler might afford. Note that linking against the release run-time does not preclude you including lots of debugging compiler options in your DLL's and EXE's - you can still disable optimisation, use the /check:all type runtime diagnostics, get tracebacks in the event of error, have debugging symbols available, etc - it's just that it becomes hard to see what is going on inside a run-time library call and those calls are less likely to detect that you've done something silly.

• If you control the application specific DLL, then consider whether it really needs to be a DLL. DLL's are useful when you need to share code between lots of applications or where there some sort of third party add-on/component/extension thing happening that requires run-time linking. If the code doesn't need to be in a DLL, then it can simplify things - the sandgroper's suggestion of static linking becomes the obvious solution. You can still consider static linking with DLL's, but then you need to be very mindful about having multiple instances of the run-time libraries active at once - particularly with respect to things like memory allocation and maybe IO. Note that static linking of the omp libraries is handled separately to the C and fortran runtime libraries.

Good luck,

IanH

[OP1]

Thanks IanH,

Yes, I am afraid that the fact that one of the DLLs I have to use (and have no control of) requires to link against the Debug Multithread DLL is going to turn into a nightmare for redistribution. Argh. Our project has come to a halt because of this thing...

Olivier

[Steven_L_Intel1]

Anything linked to the Debug Multithreaded DLLs is not redistributable - or rather, you aren't allowed to redistribute the Microsoft Debug DLLs. If you have no control over that DLL, then you are indeed in trouble.