views:

54

answers:

3

We have recently decided to start shipping the versions of some of the DLL files that a product requires with the product itself.

This is to guard against the situation where (for example) the MVC DLL file is updated on the server to which the software is deployed and the product fails to work as it was written against the now previous version of the DLL.

If the MVC DLL file of the specific version is included in the product and "locally" referenced this prevents this problem from happening. (In an ideal world every product which will be installed onto the destination server would be updated to the most recent version but this is not always practical)

My concern and question is whether this is going to give a false sense of security or not actually cope with the problem in the following situation: if Version 1.0 of the MVC DLL file is relying on method X of standard Microsoft DLL library Y and this DLL file Y is updated we will be in the same situation of having a broken product?

A: 

I don't know about MVC specifically, but you have a bigger problem if the conflicting version of a dependency dll is installed to the GAC on your target machine, as it will be used in preference to the local file.

Benjol
A: 

Depending on how big it would make your final product, consider statically linking your program. This will prevent the much dreaded DLL hell since you wont have to give DLLs out.

samoz
+2  A: 

Assuming you meant the MSVC (Microsoft Visual C++) DLLs, the correct solution is to use an application manifest. The MSVC DLLs support Side by Side installation (SxS). This means that a new version of those DLLs does not replace an old version. Your application manifest tells Windows which DLL version(s) you want.

MSalters
Thanks for you comment, it's actually the Microsoft Model View Controller DLL file (System.Web.Mvc.dll) I was using as an example of one of the DLL files rather than the Visual C++ DLLs.
Richard