How do I distribute Visual Studio 2005 apps?

How do I distribute Visual Studio 2005 apps?

• Steve-x

  Thanks very much for your explanation! This makes a lot more sense now. I guess I'll probably just do the applocal install, though it still seems strange to me. I guess my problem is that for the last several years, I've just been used to developing for MFC 4 with Visual Studio 6 in times when everybody already has mfc40.dll. If I was going to do WinSxS though, would I have to distribute vcredist_x86.exe with my app, or the MSI it produces, or do something else
  
  On the merge modules again: I am definitely using Visual C++ 2005 Professional, not Express (I wouldn't be able to use MFC otherwise ;-). However, after installing 2005 Pro, I did install Visual C++ 2005 Express (In one of my applications, I'm supporting plugins written in Visual C++ Express, so my user base doesn't have to spend a lot of money on professional developer tools). Is it possible that installing Visual C++ Express erased the merge modules for MFC and ATL...
  
  

• DerekM

  Hm. I guess that will work (probably); I hadn't really thought about doing that.
  
  It still seems like there's something I'm not understanding about this process. Is it impossible to distribute an application that dynamically links with MFC unless you include mfc80.dll (That is, won't a fair number of users have mfc80.dll already Isn't Windows Installer was capable of downloading some dependencies as necessary ) What exactly does the error message "This application has failed to start because the application configuration is incorrect" mean
  
  Also, even when I added the merge module for VC80_CRT, it bloated the installer by a couple of megabytes. Is all of this really necessary to distribute a single tiny program There were never any hassles like this when I was using VS6. :-P
  
  For example, suppose I want to distribute my application without an installer (which is really preferable in my situation). Can I just include the DLLs (mfc80.dll, msvcr80.dll, gdiplus.dll) with the application
  
  Sorry to ask so many questions; it just seems that the process for getting even a simple program to work on somebody else's computer has become much more complicated. Either that or I am woefully ignorant. :-P
  
  

• Anonymousandmad

  goatboy, I like it, a very interesting topic of discussion, how to run an app directly off a CD without any installer.  And also have it work on all platforms.  If you think about it, it was possible in every version up until now.   This is probably one thing that Microsoft would answer, build it statically. 

  You could do choice 1(a), i.e. add it to "App Paths".  This will work on all platforms. 

  However, in your case, since you want it to run off CD without installer, you will have to copy to the program folder, i.e. have a separate folder for your non XP install, e.g. in the CD you would have:

  D:\XP

  this has program and has the DLLs in subfolders (Microsoft.*)

  D:\OTHERS

  this has a copy of the program and the DLLs in the program folder (same as EXE)

  and then in the root have a launcher that launches your app based on what platform its on. 

  To avoid the above, you could also try copy runtime DLLs to BOTH the program folder and subfolders, and see how it performs in XP.  I have to get to my clean machine to see if this actually works on XP without errors. 

  P.S. I edited this particular post several times as my thinking about the topic evolved, so apologies if you had read an earlier iteration of it.

  
  

• rjhdakota

  Then you can just link statically to the MFC dlls if you don't want to distribute such dynamically needed dlls.

  Thanks,

  Ayman Shoukry

  VC++ Team

  
  
  

• Cornishboy

  Looks like a SxS issue here. See http://msdn2.microsoft.com/en-us/library/ms235285.aspx
  
  

• forkart

  if you want to distribute your app without an installer, i.e. no worry about WinSxS, then you should use applocal install. Please see these threads for info on how to do this:

  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=156718&SiteID=1

  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=123303&SiteID=1

  As for your other question about merge modules, all merge modules are found here:

  \program files\common files\merge Modules

  
  

• difg

  Search in the SxS directory for the files mfc80.dll to locate their location on your machine.

  Thanks,

  Ayman Shoukry

  VC++ Team

  
  
  

• Michael Iacoviello

  There are really three choices in installing apps:

  1) link statically, the downside being if there's a security update that Microsoft releases, your app will never get it.  The upside being no hassle installs.

  2) Install shared libraries to WinSxS using the vcredist EXE file or the merge modules.  The downside being you can't to "per user installs" since the redist merge modules require ALLUSERS set to 1.  Also you require Windows Installer 3.x to be installed on the machine for ther redist/merge modules to run.  The upside being you only have one copy of it on your machine, and you get any security updates that Microsoft releases.

  3) Install "applocal".  This is a Microsoft term for installing the shared DLLs to the program folder (in subfolders Microsoft.VC80.* etc).  The big advantage here is that you get the best of both worlds.  If some other app or Microsoft (due to security update) eventually installs them to WinSxS, then your app will start using those DLLs.  But until that time, your app uses your own applocal copy.     The disadvantage here is also due to its advantage, i.e. you have a form of DLL hell here.  You are trusting that another app or Microsoft, when installing the libs to WinSxS, will be installing "good" versions of them. 

  For your merge modules, what version are you using   Visual C++ Express That's why you don't have anything else.  All other versions will have MFC and ATL merge modules as well.  But to me, it's less hassle to use the vcredist_x86.exe file included with Visual Studio (this is an EXE that installs an MSI that installs CRT, MFC, ATL release versions to WinSxS)

  As for WinSxs, the main problem it's trying to solve is allowing the user to have multiple versions of the same DLL in parallel, but still allowing it to be shared.  In the old days everything went to system32, so you could only have one "comctl32.dll" for example.  But if Microsoft wanted to release a new version but not break existing apps, it would be impossible.  So they introduced the concept of the WinSxS folder where everything has a "strong name", i.e. a GUID that identifies the DLL.  Your application's manifest states which version it should use based on the GUID of the DLL's folder in WinSxS.     There is still a risk of DLL hell here, but much less so, as once your app states that it will use a certain version from WinSxS it will keep using that, unless Microsoft uses the policy system to redirect your DLL calls to a new version.  True, a rogue app could abuses the policy system, but much less likely than just overwriting a whole DLL like in the old days of system32. 

  
  

• ChrisCC

  Ah, well, I found the DLLs there, but I thought I was looking for merge modules If I just package the DLLs into my installer I'll wind up distributing a 3-megabyte file for an 80-kilobyte application! :-P
  
  

• bugduc

  Just to test the theory, I've put together a Hello World dialog app that is dynamically linked to MFC and CRT. In the program's directory I have placed all of the .dlls from the CRT, and MFC redistributable directories, and added the Microsoft.* directories for the manifest resolutions. Works fine on XP.

  I get a message about the application terminated in an unusual way on Windows Me, with a reference to MSVCR80.dll.

  -Goatboy

  
  

• jrx

  1) for applocal there are several caveats.  Note: applocal only works properly on Windows XP and above (e.g. 2003 server).  On other platforms, you

  (a) either have to have those DLLs in your path (i.e. add Microsoft.VC80.* paths to your system path or "App Paths" registry keys - unworkable in my opinion but here is some pointers http://www.codeguru.com/Cpp/W-P/dll/article.php/c99 )

  (b) copy those DLLs to your program folders (i.e. in the same folder as your executable instead of in Microsoft.* subfolders), or

  (c) copy them to system32 (the DLL hell problem comes into play here)

  So even for applocal, your installer must be smart enough to do the right thing on various platforms (conditional install logic).  There are several complications here.  a) what if you copy those DLLs to your program folder.  And then the user upgrades his OS to Windows XP   What happens now    b) what happens if you copy them to system32 and then the OS is upgraded    Well the vcredist and merge modules handle this on Windows 2000 by installing the DLLs to BOTH system32 and WinSxS, even though a WinSxS concept doesn't exist on Windows 2000.  The reason it does this, is so when the user upgrades his OS to Windows XP, the WinSxS folders are there "waiting" to be taken advantage of. 

  My personal advice is to go with the shared version (WinSxS) via vcredist_x86.exe, as it handles all operating systems properly (except NT 4.0 and Windows 95 which obviously are not supported any more).   As for your question, yes, you have to distribute the vcredist_x86 and then execute it (launch it) from your installer, or use the merge modules in your MSI file. 

  2) Yes, installing Express to the same machine would definitely be a problem.  You'll probably want to start over again (uninstall everything, then reinstall Professional)

  
  

• TheCatty

  Ah, thanks much. With regard to your first posting on the former of those two threads: do you mean I should distribute the entire contents of those two folders with my application This seems like overkill; I thought the whole point of shared libraries was to minimize the binaries that needed to be distributed. If everyone just bundled MFC and the CRT with their apps, what would be the point Obviously I just don't get it. :-P Nonetheless, if it allows other people to run my app, I'll do it.
  
  I guess I'm a little in the dark about what exactly "Side-by-Side" is, and what problem it is supposed to address. I've hunted around MSDN looking for an overview, but I can't seem to find such a document. I'm guessing this is about solving "DLL Hell", but I haven't been able to figure out how exactly it works. Is there a good resource for this out there, and could someone point me to it I'd really like to get up to speed and learn about this.
  
  As for the merge modules: when I look in Program Files\Common Files\Merge Modules, I only see four files; the regular and debug versions of the CRT merge module, and "policy_8_0_*" files corresponding thereto. There's nothing at all for MFC. Perhaps I left something out when I was installing Visual Studio I'll go back and check, I suppose.
  
  

• David Leibowitz

  Thanks for your help; that looks like what I need. I have another question now though.
  
  Following the directions in that article, I am instructed to add merge modules for MFC80 and the CRT to a setup project. The only problem is, I don't seem to have merge modules for MFC80. There are both the standard and debug merge modules for VC80_CRT, but nothing for MFC. These should come with Visual Studio 2005, right I do have the Professional Version of Visual Studio 2005, not the Express.
  
  Is there some place where I can obtain these merge modules
  
  

• Caleb Widmer

  Ted.

  Following the instructions in your posts I have been able to get my simple application to run on XP Pro with the app local setup mentioned.  However the older OS's aren't behaving similarly.  How can we get VS to build in a manner that allows for applocal distribution of the MFC and CRT dll's and is backwards compatable with 98, Me, 2000

  I want my application to have NO installer.  Just run off a CD for all of the various OS's 98 - XP.

  
  
• How do I distribute Visual Studio 2005 apps?