When we look at other installation options than side-by-side installations, we consider "applocal" installations. Unfortunately we cannot use side-by-side installation since it prevents “Per User” installations in Windows Installer. (See http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=552c704c-75ba-4cb1-8bf3-0c1d6d50d5a2)< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
A drawback with applocal installations is that fixes issued by Microsoft to components such as MFC80u.dll will not automatically applied. On WinXP I suppose MS can do this by using policies. I found a KB article where this is discussed:
http://support.microsoft.com/default.aspx scid=kb;en-us;835322
As one of the points at the end of the KB article, you can read: "If you install your application on a computer that is running Microsoft Windows 2000 or earlier versions of Windows, do not ship the side-by-side assembly in your application folder to those operating systems. Instead, the side-by side assemblies should be used from the system folder."
What does this really mean I suppose the reason for installing in the system folder is that this makes it possible for MS to service those DLLs. Does this mean that MS suggest that you install for instance MFC80u.dll in your application folder for WinXP, but in the System32 folder on Windows 2000 That would make sense.
But how do you do that The merge module provided by MS, Microsoft_VC80_MFC_x86.msm, will install the DLL side-by-side on WinXP and in System32 on Windows 2000. Since we cannot use side-by-side installations, we cannot use this module. Fine. But how do you install MFC80u.dll in the System32 folder If you look at the merge module provided by MS, it will do much more on Windows 2000 than installing the file in the System32 folder. It looks like it will copy the file to both the System32 and WinSxS folder and also write some registry settings (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\Installations\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_x-ww_dbdc31f5\nosxs). What if you want to install it in the System32 folder without using this merge module Can you just install the DLL
How do you install CRT, ATL80.dll, MFC80u.dll applocal?
Seth Wenzel
Well, if I understands things correctly, the KB article explains that even applocal instances of mfc80u.dll can be serviced by MS in WinXP. The side-by-side directory will always have priority over applocal files and if a fixed version of mfc80u.dll is installed centrally as a side-by-side assembly with a policy, this will be used instead of my local version.
Since this cannot be done on Windows 2000, they recommend that these components are installed in the system folder. But I guess there is a reason that the MS merge module does not just copy it to the folder, but installs it in the WinSxS and has some additional registry settings. I also suspect the this has to do with upgrading the OS. I don't want to break that functionality by doing it the wrong way.
Since we started to use Windows Installer several years ago, we have had very few problems with "rogue" applications messing with our applications. Generally, we are quite happy with Windows Installer.
Matt Michuta
Ah, I forgot about that trick! Thank you for pointing that out. That could solve a small part of my problem, but the fundamental problem of creating an installation with local CRT files still remains. Currently we put our hope in the hotfix mentioned by Nikola.
/Thomas
Intruder
netsql
Ideally I would like to make a "shared" installation for both WinXP and Win2K. But for some reason MS prevents this when running "per user". (I can't undestand why though.) If they could fix that, it would be the best option.
It is not possible to install a merge module conditionally. I could modify the module, but I don't think I am allowed to do that. One option I have been thinking about is to use the merge module and then create a Windows Installer Transform to modify the installation in such a way that it will never install the shared files on WinXP/Windows 2003 Server. However, since merge modules are reference counted, this might confuse other installations that use the same module.
See also this discussion: http://forums.microsoft.com/forums/ShowPost.aspx PostID=183578&SiteID=1
Davidarh
WN3335
But then why did you break it again for Vista, VS 2005 Professional with SP1 and SP1 Update
I'm getting errors 59, 32, and 33 on VS 2005 builds that have been working for months until I installed SP1 Update. So far, none of the suggested solutions work.
Gary G. Little
KillerBoy
Last time I was in Redmond I talked to one of the authors of those MSM merge modules and he told me that the reason they install to the WinSxS folder on Windows 2000 is solely for the case where you upgrade your operating system. So, for example, you upgrade from Windows 2000 to Windows XP and now there are WinSxS folders still there waiting to be used. Now this does not explain how upgrading the OS will get rid of the ones that are still sitting in system32.
As for how to install to system32 (or system on Windows 9x) just copy those files there. I think there may also be some self-registration to be done for MFC80U.DLL if you use MFC based COM stuff.
But for true applocal, instead of copying to system32 or system, I would just copy those to your application folder. If you're not going to have servicing in Windows XP then why bother allowing servicing in Windows 2000
The main reason fro not installing to system32 in Windows 2000 is I don't like being vulnerable to some rogue app that is going to uninstall those files out from under you since these files are not under system file protection (unlike mfc42.dll which is under system file protection in Windows 2000). Microsoft's solution for this is to use MSI self-healing repair functionality. So someone deletes your DLLs in system32, your MSI is supposed to sense this and then replace them. But I don't know how well this works in practice.
Any thoughts
Alan Smith MVP
As for servicing the applocal DLLs in Windows XP, I've been wondering about that as well. As you say, I guess what they mean by servicing is not that it will replace what's in your applocal folder but instead the one in WinSxS will always take precedence over yours if it exists.
So, what is your goal - do you want servicing in Windows 2000 as well If not then copying to the application folder is an option here. If so, are you saying that a per-user install via group policy in Windows 2000 can install to the system32 folder (and also register COM objects to local machine, for example).
If yes, is there any way you can use the merge module for Windows 2000 only i.e. does the error message about ALLUSERS come up on Windows 2000 as it does on Windows XP. Otherwise, you can roll your own by just installing those files to the system32 folder. I don't know if you want to bother with installing to WinSxS on Windows 2000 (for upgrading purposes). I haven't decided whether I'll do that.