Jump to content
  • Advertisement
Sign in to follow this  
synth_cat

deploying my game from VisualC++2005 Express

This topic is 4234 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello everyone! I am almost at the point where I want to run my game (a Win32 application compiled in Visual C++ Express Edition) on other people's computers for testing purposes. However, I have learned from various sources that this is not as easy as it sounds. By default my apps apparently will not work on computers that don't have Visual C++ 2005 installed on them. In order to work, my app needs to be packaged a certain way. I have done a lot of research on the subject, and have perused lots of articles about merge modules, CRT, manifests, and all sorts of things that I can barely grasp. There seem to be quite a few ways to deploy apps. Frankly, I'm not sure exactly which method to use. First of all, let me explain what I want to do with my game. I want it to be simply an .exe within a folder which the user puts on his/her hard drive somewhere. I don't want there to be an installation process at all (I know from articles I've read that this is an option.) In my reading I have found two methods that seem like they will potentially work for me: 1) Use "static-linking" instead of dynamic linking, as outlined below
Quote:
The simplest possible deployment strategy for a basic Win32 application involves compiling the application as a Win32 application, and moving the .exe application (or library dll) to a web server and providing end users with the download link information, typically via a web-page link as done here. The default C++ compiler option for runtime libraries in Visual Studio 2005 is /MD which causes a dependency at run time on the DLL MSVCR80.dll which will not be installed typically on clients. Statically linking with /MT, which links using the static multithreaded library LIBCMT.lib, while not recommended due to maintenance issues, can make sense in simple cases. The compiled application will obviously be larger than linking to a dll (as discussed below), but has the advantage of being self-contained and allowing installer-free deployment targetting many downlevel systems.
from http://www.jensign.com/primes/index.html 2) Create a special manifest file that you package in the same folder as your app, as outlined below in a quote from a forum:
Quote:
OK, due to popular demand, and my frustration with seeing so many people using Express that simply want to run an app on another machine, without the hassle of learning about merge modules, Windows Installer, etc, etc, etc, here is a way to perform deployment option number 2 above (i.e. installing C Runtime library applocal) for Express. 1) On the machine you have Express installed, create the following folder and subfolders in your \program files\microsoft visual studio 8\VC folder: redist\x86\Microsoft.VC80.CRT 2) Copy msvcr80.dll, msvcp80.dll, msvcm80.dll from \windows\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd into: \program files\microsoft visual studio 8\VC\redist\x86\Microsoft.VC80.CRT 3) in the above Microsoft.VC80.CRT folder, create a new file named: Microsoft.VC80.CRT.manifest 4) Paste the following content into the above manifest file: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <noInheritable/> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50608.0" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" /> <file name="msvcr80.dll"/> <file name="msvcp80.dll"/> <file name="msvcm80.dll"/> </assembly> Now you have a new folder in your Visual C++ Express installation that can be re-used when ever you need it. To deploy these files, simply copy the Microsoft.VC80.CRT folder you just created to your program folder. That's it. So for example, if your application executable resides in C:\Program Files\MyApp, you'll have a folder named: C:\Program Files\MyApp\Microsoft.VC80.CRT that contains the 4 files I mentioned (3 DLLs and one manifest file you created by hand) No installation of anything else is necessary. Just click on your EXE file, and your app will run. No special installation engines are necessary, just make your setup program (installer) create that subfolder Microsoft.VC80.CRT along with what you normally install with your app)
from http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=164465&SiteID=1 So, what I'm wondering is: Which method do I use? Am I supposed to use both? Has anyone out there ever tried either of these? Thanks very much for any help! -synth_cat

Share this post


Link to post
Share on other sites
Advertisement
I know what problem you're having. I had the same problem. The solution's really much easier than you've been lead to believe (indeed, as I had been lead to believe as well).

Right click on your solution, click "Properties." Open "Configuration Properties" on the left (clicking the "+" sign). Open the "C/C++" branch. Click on "Code Generation" from inside that branch.

In the main part of the window, click on the "Runtime Library" option until "Multi-Threaded Debug (/MD)" is selected. (Not "Multithreaded Debug DLL," "Multithreaded", or "Multithreaded DLL").

You may have to do this for all different configuration builds (release, debug, and any others you might have).

That should work out for you.

-Gauvir_Mucca

EDIT: SORRY! I told you to use the wrong setting. Use "Multi-Threaded Debug" not "Multithreaded DLL"!

Share this post


Link to post
Share on other sites
Thanks for the advice!

However, it seems like setting this option is making my final .exe be of "debug" type, which I've heard is illegal. Is that true?

[link]http://google.com[/link]

Thanks!
-synth_cat

[Edited by - synth_cat on November 23, 2006 7:55:20 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
/MTd is the statically linked debug version ("Multi-Threaded Debug"). You can use /MT for a statically linked release version ("Multi-Threaded").

Also, this page should help you out: http://msdn2.microsoft.com/en-us/library/2kzt1wy3.aspx

Share this post


Link to post
Share on other sites
So if I go into Project Settings and set "Runtime Library" to "Multi-threaded (/MT)", I will sidestep all the issues with linking to dlls and WinSxS and all that other stuff?

If I use this setting, will I be able to take my Release-mode compiled .exe (by itself, with no manifest or redistributable files) and have it work fine on any computer?

If not, what else do I need to do?

Thanks for your help!
-synth_cat

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by synth_cat
So if I go into Project Settings and set "Runtime Library" to "Multi-threaded (/MT)", I will sidestep all the issues with linking to dlls and WinSxS and all that other stuff?

If I use this setting, will I be able to take my Release-mode compiled .exe (by itself, with no manifest or redistributable files) and have it work fine on any computer?

If not, what else do I need to do?

Thanks for your help!
-synth_cat


Using /MT will cause required C run-time libraries (http://msdn2.microsoft.com/en-us/library/abx4dbyh(VS.80).aspx) to be compiled statically into your executable. This means that the end users won't need the VC specific dll files to run your app, but the drawback is that your executable will be quite large.

If you are also using other dll files you will still need to distribute them with your game as they cannot be compiled into the final executable (a dll file is a dynamic link library after all). If you had the source you could build the dlls as .lib files and also statically compile them into your executable which would eliminate the dll dependency altogether. Note that this will increase your executable size even more.

Share this post


Link to post
Share on other sites
Thanks for explaining that!

What if I want to use DirectX (which has already been installed by the user.) Do I need to package some sort of manifest file along with my .exe?

Thanks!
-synth_cat

Share this post


Link to post
Share on other sites
Nope. I've got a game that uses the /MT method and compiled against the DirectX 9.0 SDK and it will run on any machine with DirectX 9.0 (normal user runtime only) or later without any other external libraries. It just ships as a stand alone .exe and my own dependant files (resources, levels etc).

However, thanks very much for posting that blurb from the site about setting up your own redist folder. I've been trying to get an answer on that one for ages.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by synth_cat
Thanks for explaining that!

What if I want to use DirectX (which has already been installed by the user.) Do I need to package some sort of manifest file along with my .exe?

Thanks!
-synth_cat


IF you statically link with the DirectX libraries you will NOT have to supply any additional files.

Statically linking with a library will place the actual code into your executable! Meaning there are no extra dependencies.

Either way the DirectX drivers are mandatory for your users as they will provide the interface to communicate with your user's graphics card.

Here's some more information for you:
http://en.wikipedia.org/wiki/Static_Library
http://en.wikipedia.org/wiki/Dynamic_Library
http://en.wikipedia.org/wiki/Library_(computing)
http://en.wikipedia.org/wiki/Directx#Compatibility

Share this post


Link to post
Share on other sites
Thanks for those last two posts! It is particularly reassuring to hear that it is possible to ship my .exe as a stand-alone.

Quote:

However, thanks very much for posting that blurb from the site about setting up your own redist folder. I've been trying to get an answer on that one for ages.

But I don't understand why anyone would bother going to all this trouble in the first place if it is so simple to deploy your applications by just static-linking.

Quote:

IF you statically link with the DirectX libraries you will NOT have to supply any additional files.

It sounds like a very good idea, but is this the way it is usually done? I thought that with DirectX it is better to just have the user run DXSetup() (or whatever it's called.) Besides, would it be technically legal to select individual .lib DirectX files and static-link to them in your app? I have heard that shipping these .lib files individually with your app is illegal, so I was just curious.

By the way, when I enable static-linking under the "Runtime Library" option, this isn't actually static-linking with DirectX libs, is it?

Thanks!
-synth_cat

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!