Home Dashboard Directory Help
Search

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


Status: 

Closed
 as By Design Help for as By Design


1
0
Sign in
to vote
Type: Bug
ID: 776799
Opened: 1/17/2013 8:14:03 AM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

Starting Visual Studio 2005 the MFC and C-Runtime Dlls were deployed using the side-by-side approach in WinSxS and a manifest. Still it was possible to deploy the required DLLs together with the application to allow X-Copy-Deployment.

This works the following way:

1. if the Visual Studio 2012 Redistributable is not installed, our application uses the local DLLs provided in special assembly folders.

2. but if the Visual Studio 2012 Redistributable is installed, our application uses the system DLLs.

The advantage is, that the possibly security patched versions of the DLLs are used if they are installed on the system (using policies). Only if the redistributable is missing, the local DLLs are used.

After upgrading to Visual Studio 2012 I have now detected, that the deployment has changed. The Dlls are located in the c:\windows\system32 folder and if a local copy exists, the local one is used.

So we are back in the days of DLL hell again!

I do not see, why the deployment strategie has changed (again). Please go back to the Visual Studio 2005 deployment model, because it prevents using outdated DLLs from a local application directory.
Details
Sign in to post a comment.
Posted by Nandagopal s on 7/11/2013 at 6:22 PM
Hi BOFHRAF,

The biggest advantage of SxS was that multiple versions of the a dll could exist and run inside a process without being aware of presence of the other version. E.g. think of a scenario where two different windows hooks from different vendors are being used by a user - one of the s/w is compiled using VS2008 sp0 (no sp) while the other one is compiled using VS2008 sp1. Both the hooks would load into any arbitrary processes without any problem. But in the absence of SxS, assuming there is an export difference in sp0 and sp1, one of the hooks may not - randomly - load into any processes. If sp0 hook is installed first it would bring the crt dll -assuming local copy is used- that has a missing export into the process because of which the second hook would not load as one of it's import reference would fail to resolve.

This is not a made up case but something I have seen practically being solved by VS2008 due to SxS while VS2003 could not handle it.

Thanks
Nanda
Posted by BOFHRAF on 2/20/2013 at 12:53 AM
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
Posted by Microsoft on 2/19/2013 at 12:24 PM
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
Posted by BOFHRAF on 2/11/2013 at 12:23 AM
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
Posted by Microsoft on 2/8/2013 at 6:26 PM
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
Posted by BOFHRAF on 1/28/2013 at 12:28 AM
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
Posted by Microsoft on 1/25/2013 at 2:43 PM
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
Posted by Microsoft on 1/17/2013 at 10:52 PM
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.
Posted by Microsoft on 1/17/2013 at 8:50 AM
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)
Sign in to post a workaround.