Saturday, December 03, 2005 9:42 PMUntil recently I've been using VS.NET 2003, now I have VS8 2005. And none of the project I make work on other computers. They only work on my PC, when i try to run the program on another PC I get this error:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
Why is that? How can I fix it?
Also, when I compile VS.NET projects with VS8 2005 they work fine, but when i make a project with VS8 2005 and build it with VS8 2005 is when it doesn't work.
Sunday, December 04, 2005 12:29 AMModerator
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:
Sunday, December 04, 2005 6:52 PMIn your c:\FilePath folder copy these two folders from: \Program Files\Microsoft Visual Studio 8\VC\redist\x86 :
so for example you would have files in:
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 :
WinSxs is not necessary. Applocal is easier.
Sunday, December 04, 2005 7:14 PMModeratorIt 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...
Sunday, December 04, 2005 10:20 PMBut applocal DLLs (using manifest) can be serviced by Microsoft too. At least that's the impression I got from Martyn. Maybe I misunderstood.
Wednesday, December 28, 2005 10:41 AM
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.
Thursday, December 29, 2005 3:58 PM
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):
Or you can use a "roll-your-own" solution, such as this:
Thursday, December 29, 2005 4:17 PM
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.
Thursday, December 29, 2005 5:08 PM
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.
Thursday, December 29, 2005 5:20 PM
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.
Friday, January 27, 2006 4:09 PM
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.
Monday, January 30, 2006 9:12 AM
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.
Monday, January 30, 2006 5:32 PM
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.
Tuesday, January 31, 2006 8:38 AM
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.
Tuesday, January 31, 2006 3:37 PM
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.
Thursday, February 02, 2006 11:41 AMAs far as I know there is no way to make a merge module conditional. Conditions can be put on components in a merge module, but not without modifying it. It is quite easy to make such modifications, but you are not allowed to modify such components without breaking the license.