VS8 2005 Projects only work on my PC

VS8 2005 Projects only work on my PC

• Svennis

  It is easier but for long term servicing it is harder. For example if you install a microsoft patche for any reason (say security), the patch will try to update the SxS version and hence you won't get such benefits unless you re-copy the new dlls once more.
  
  Just my 2 cents...
  
  Thanks,
    Ayman Shoukry
    VC++ Team
  
  

• smanche

  Ted,

  I think you are right that WinXP will look in WinSxS before the local directory. This solves servicing on WinXP but not on Win2K. I guess this is why Microsoft recommends applocal on WinXP and System32 on Win2K.

  I have yet to find out how to accomplish this though. How do you create an installation program with these properties:

  · We have two directories with binaries: dir A and dir B.

  · On WinXP we want to install CRT/ATL/MFC in both A and B

  · On Windows 2000 we want to install CRT/ATL/MFC in System32

  For WinXP we can write our own merge modules based on the binaries in the Redist directory. This means that we will have to have two sets of merge modules (one for the directory A and one for B), but we can live with this. It will make the installation a bit bigger, but that is OK.

  But how do we install in System32 in Win2K We cannot use the merge module from MS since it will install in WinSxS in WinXP. But can we write our own merge module for Win2K If you look at the merge module from Microsoft it does install in System32 on Windows 2000, but it also does a lot of other stuff such as writing settings to the registry. I guess these settings are used when/if the user upgrades to WinXP.

  If I install the files in System32 on Win2K using my own merge module:

  · What will happen if the user upgrades to WinXP

  · How will reference counting be handled for the shared files in System32 For Windows Installer this is normally handled on a component level, but if I write my own merge module, it will be a different component than other programs use.

  
  

• user33

  You are missing the SxS installtions in the other machine. I would recommend taking a look at this link that explains the concept of SxS and fusion in general: http://msdn2.microsoft.com/en-us/library/ms235624.aspx
  
  Take a look at those previous posts that deal with the similar issues:
  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=123250&SiteID=1
  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=54317&SiteID=1
  
  Thanks,
    Ayman Shoukry
    VC++ Team

  
  
  

• Alex Dresko

  In your c:\FilePath folder copy these two folders from: \Program Files\Microsoft Visual Studio 8\VC\redist\x86 :
  
  Microsoft.VC80.CRT
  Microsoft.VC80.MFC
  
  so for example you would have files in:
  C:\FilePath\Microsoft.VC80.CRT
  and
  C:\FilePath\Microsoft.VC80.MFC
  
  where C:\FilePath is your program executable folder.
  
  Similary for debug builds copy these two folders from D:\Program Files\Microsoft Visual Studio 8\VC\redist\Debug_NonRedist\x86 :
  
  Microsoft.VC80.DebugCRT
  Microsoft.VC80.DebugMFC
  
  WinSxs is not necessary.  Applocal is easier.
  
  

• Tobi123

  Well, there is another problem here. We have several locations where we install files. This means that we must put the "applocal" files in all directories. The drawback is, of course, that it takes up extra space on the disk, but also in the memory since these DLLs are loaded several times in the same process. We would not have this problem is they were shared.

  An "applocal" msm might be nice in some cases, but an msm cannot be included several times in the same installation and would thus not be useful for our purposes.

  What I would really like is to be able to install things side-by-side in an installation in "per user" mode. I cannot see why they prevent this. The WinSxS folder is used for Win32 assemblies pretty much the same way as the GAC (Global Assembly Cache) for .NET assemblies. There are no problems installing things in the GAC in "per user" mode.

  
  

• JaySuarez1959

  You're correct, it is just a wrapped MSI, and that it's not ideal for an MSI to be launched from another MSI file.

  And you're sure there's no way to conditionally include a pre-built merge module That's unfortunate.

  So the best thing Microsoft could do is release the source code (project files) for the merge modules, so then we could add a condition in there that would cause it to not be installed under Windows XP and higher.

  
  

• the_bee_keeper

  We would love to install the shared modules (crt, atl, mfc) and also some of our own modules "side-by-side". This works fine and has a lot of benefits. But there is a major drawback that makes it almost impossible for us to use: the installation programs cannot be run in "Per User" mode.

  See

  http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=552c704c-75ba-4cb1-8bf3-0c1d6d50d5a2

  
  

• sonny jim

  Launching a Windows Installer installation from another Windows Installer installation does not work well. From what I understand, the vcredist_x86.exe is a Windows Installer program.

  
  

• NZSnowman

  But applocal DLLs (using manifest) can be serviced by Microsoft too.  At least that's the impression I got from Martyn.  Maybe I misunderstood.  
  

• unixfox

  If you truly want servicing in Windows 2000, then I think it is best to use the vcredist_x86.exe provided by Microsoft.  This is basically the merge modules wrapped up into an EXE (no Windows Installer 3 included though).    So only run the vcredist_x86.exe on machines that you are NOT installing applocal (i.e. not on XP and 2003 Server).  On XP and 2003 Server, just install applocal and don't run the vcredist_x86.exe.   

  I think this solves all your problems for all platforms, and any upgrading issues (as I mentioned before, the Windows 2000 to Windows XP OS upgrade is handled already since the vcredist also installs to WinSxS on Windows 2000 even though it doesn't exist, so incase the user upgrades the OS, it is waiting there to be used). 

  I don't know about the reference counting though.  Try some tests to see. 

  
  

• Tùng

  One approach to getting around the "per-user" limitation and still install to WinSxS is to not use the MSM files directly in your setup project, but instead create a satellite MSI file that is only responsible for installing the shared modules.  This way you can have a so-called "prerequisites" phase of your setup that installs libraries in per machine mode, and then your main setup will install in per-user mode. 

  The Bootstrapper SDK built into Visual Studio will allow you to set up a nice prerequisites screen easily.  More info on the Bootstrapper SDK is here (Chris Smith is the expert in this area):

  http://blogs.msdn.com/chrsmith/articles/category/10628.aspx

  Or you can use a "roll-your-own" solution, such as this:

  http://www.codeproject.com/useritems/vcredists_x86.asp

  
  

• Russell Mason

  Interesting, thanks for the info.  I too am interested in making sure my app works well with Group Policies.

  I think they should have released an "applocal" msm.  That would have been pretty useful.  This msm would handle applocal for all platforms.   Maybe this is something people would be interested in.

  
  

• vondueck

  Ayman Shoukry wrote:

  Applocal is easier but for long term servicing it is harder. For example if you install a microsoft patch for any reason (say security), the patch will try to update the SxS version and hence you won't get such benefits unless you re-copy the new dlls once more.

  I just noticed this reply and I wanted to correct it - actually since then we have learned that WinSxS installs always take precedence over applocal DLLs. So if a user starts off with just applocal DLLs and no WinSxS DLLs, and then later on, Microsoft installs WinSxS versions of those DLLs, then the WinSxS DLLs will be used instead. Please correct me if I'm wrong.

  
  

• linch12

  The primary reason we have to support "Per User" installations is for installations made by using "Group Policies" in Active Directory. They want to published installations and this requires "Per User" installations. This means that the MSI is not launched by a bootstrapper that we can control, but the MSI is installed by the Group Policy engine.

  Some customers have really huge networks with hundreds of user, but only some of them are interested in installing our applications. They do not want to push the installation on each and every computer. Another drawback with installing applications "Per machine" using Group Policies is that it requires a reboot for the application to be installed. When an application is just published, the user can just go to the Add/Remove Programs applet and install the program and start to use it immediately.

  I find it strange that MS makes it so complicated to write installations that work well with Group Policies since this is a thing they advocate.

  
  
• VS8 2005 Projects only work on my PC