Main disadvantage of (really) AppLocal deployment

In my last post I described how to (really) deploy CRT/MFC DLLs into the same directory as the application (xcopy deployment).

“Really” means, that it will never load any DLLs installed in the WinSxS directory. This is archived by removing the “publicKeyToken” from the manifest. If you leave the “publicKeyToken” inside the manifest, then it will force loading of (possibly) installed WinSxS versions (and updates/redirections).

The option of really AppLocal installations are not explaind on any Microsoft side (or at least I could not find it). Only the “normal” (semi) AppLocal installation is (a little bit) explaind, for example here:
Visual C++ Libraries DLL Deployment.

One of the main reasons for this is the new focus from Mircosoft to Security.

The main disadvantage of really AppLocal installations is, that Microsoft is not able to update or patch your installation (or better the CRT/MFC components of your installation). And this sees to be anathema to Microsoft.
The same is also true for static linked applications.

So I fear, that Microsoft will

  • remove or deprecate static linking in the next version of VS
  • remove the possibility to really AppLocal installations in the next OS /MFC/CRT DLLs

Hopefully, this will not come true…

3 thoughts on “Main disadvantage of (really) AppLocal deployment

  1. Michael Mattsson

    >>So I fear, that Microsoft will
    >> remove or deprecate static linking in the next version of VS

    That really doesn’t seem to be likely. Purposefully crippling their compiler and/or runtime libraries simply just isn’t in the cards at Microsoft.

    The reason that you don’t find much info about using MS specific runtime libraries local to the app is that MS wants to discourage the practice for that average programmer…. which is fine and probably a good thing.
    But there have been articles about removing the public key from manifests on MSDN and elsewhere on the internet in the past for those who needed to do so.

  2. codeplay

    When we build a dll which depends on msvcp90.dll, is it possible to build the msvcp90.dll into our dll so that we don’t need to deploy the msvcp90.dll.

    The reason why I need this is because I am writing a firefox extension, if I put the msvcp90.dll along with my dll, it will cause the firefox have a dll loading error because firefox tries to load the msvcp90.dll.

    Pls enlighten me, thanks!

Comments are closed.