Runtime Deployment (No Side By Side Installation Anymore) by BOFHRAF

Hello George,

Thanks for the explanation. What really bothers me is that the deployment model is changed all the time. As you said both models have their advantages and disadvantages but we (and our end-users) can get used to it, if it is not constantly changed. Even worse, we now have to live with a mix of both models.

In addition, if we deploy the dll applocal, the security patched versions are no longer used, so you opened a security hole here.

Best Regards

Hi BORHRAF,

Thank you for giving more details about the scenario.

Our current solution is that we drop our CRT dlls into system32 so that they are available for all applications if they do not have an applocal copy.

* Isolation Across Major Versions

The names of the CRT dlls change from one major version to another. For example, for VS2005, the CRT dll is called msvcr80.dll. For VS2008, the CRT dll is called msvcr90.dll.

Because of this renaming, the application linkage also changes. So applications built with the VS2005 toolset has the msvcr80.dll embedded in their binary image.

The renaming (by itself; without Win32 SxS) gives us application isolation across major versions of VS. This is the same behavior we had with Win32 SxS. No loss is here.

In dll hell, the dll name did not change between major versions, and hence, this lead to really bad behaviors.

* Isolation Across Minor Versions
When we release an update (QFE) to a version (a security update, or a bug fix), we do not change the dll name. But we distribute a new dll, and place it in the ‘central’ location for use by all applications. Almost, all applications will start using the new dll once its installed.

With Win32 SxS, this happened by installing central policies. The central policies redirected all application requests to the most recent version. So, even though the old versions of the CRT existed on the machine, they were not used by any application. However, when the latest update is removed, the next most recent policy took effect, and the next most recent version of the CRT became ‘active’ again.

With our current deployment to system32, Windows Installer patches the CRT dll in place with the new one; effectively forcing all applications to start using the new dll. When the update is removed, Windows Installer re-copies the older dll on top of the newer one.

In this scenario, there is no loss in functionality as well – our current behavior is similar to what application experience with Win32 SxS.

(Admittedly, there are some tricky things the application user can do to exclude her/his application from the win32 sxs redirection – but almost nobody ever did that. After all, people want to pick the latest dll automatically when a new security update is available. And even if they did exclude their app, they still get the same ability with the current model).

* Automatic Patching for Applocal Deployment
This is a core difference between using Win32 SxS and using the regular load path order. This is a scenario that Win32 SxS enabled, and is no longer provided by system32 deployment. People may differ on whether this is a good thing or a bad thing. If an application places an applocal copy, it probably wants app isolation. Win32 SxS broke that scenario (because of the redirection policies). Another application places an applocal copy because it’s simply easier, but still wants the global updates (your scenario). The system32 broke that scenario.

So, for the above scenarios – both deployment models are close… What made us stop relying on the Win32 SxS technology are two main points:
(1)    high rate of install failures [sometimes due to very strict versioning rules, and other times due to a more restrictive caching system for the dll]
(2)    diagnosing load failures was/is very hard [especially with mixed/managed scenarios]
And to understand and solve those scenarios, it required some investment from the users to learn and understand how things work. Based on the volume of support requests we received, it seemed more efficient for our VC libraries users to not rely on the Win32 SxS technology.

I hope this answers your question. If not, please, let us know..
George Mileka
Visual C++ Libraries

Hello George,

Yes, the scenario is correct. We want to upgrade our main application (.exe) from VS2005 to VS2012. Therefore the .exe needs the new MFC and CRT runtime libraries. Our 3rd party DLLs (e.g. Crystal Reports) are still referencing the MFC and CRT from Visual Studio 2005. Other 3rd party DLLs are referencing even older Dlls like MFC42.dll.

If you ask for version numbers, in case of CRT it's 8.0.50727.4940 for Crystal Reports and the main .exe would use 11.0.51106.1.

I understand, that the SxS technology also have its disadvantages, but it was announced as THE solution against DLL hell, and what I really don't understand is why the approach is constantly changed.

The main advantage of SxS was that a security patched version of the DLL was used even if an older version exists in the local application directory. So the requirements for security and xcopy deployment were met perfectly.

Best Regards

Hi BOFHRAF,

I would like to understand your scenario better. It seems you have an application binary (.exe) that loads a set of (3rd party) dll binaries. Each of the binaries have a dependency on a version of the CRT. More than one version of the CRT is necessary to run the application and the dlls. Does this sound like a reasonable description?

If so, could you please let us know what are the different versions of the CRT those dlls depend on? Are they 8.0/9.0/10.0/etc? Or, are they all 8.0, but different build numbers (8.0.50727.4012 vs 8.0.50727.5166)?

Our use of the Win32 SxS technology had its advantages – but also it had its drawbacks. I can go into more details – but I thought I should understand your scenario better first.

Thanks,
George Mileka

Hello

Could you please explain why you moved away from the SxS model? It really had the big advantage, that a security patched DLL installed in SxS was used if it exists.

So the new (old) model is unsafe, and I was told, security has the highest priority at Microsoft? I do not understand why such a model must be changed all the time. Even worse, because we are also using 3rd party DLLs at the same time, we have to deploy different versions of the redistributables, now even with different models. One Runtime-DLL is taken from the SxS the other from the app-local directory, what a mess.

Please reconsider your design. As usual in the software industry it would be good to make such things configurable and allow your customers to choose the model they prefer.

Thank you

Hello,

Thanks for responding this issue. Visual C++ Runtime deployment has moved away from following a SxS model. The behavior described in your bug is by design. DLLs in the app-local directory get a precedence over those in the System directory. We are closing this bus as "by design"

Thanks you,
Visual C++ Team

Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)