I'm trying to deploy a C++ app for use on multiple systems. I've already gotten everything to work in the release configuration. Now since i don't have any experience with deploys at all, i'd like to ask - what's the simplest way to deploy it from Visual Studio 2015 community, so that it could be installed as a portable app on flash drives and similar?
I've checked out google, but with no luck so far all of the solutions i checked require some sort of additional software that is only available for the pro version of VS.
The simplest possible answer would be: compile without dependency on VC++ runtime libraries (select this in the project properties -> C++ -> code generation) and choose the oldest Windows version it should run on (in project properties -> general). Maybe even select Windows XP compatibility.
This should be enough, unless your program depends on other libraries or optional Windows features that may be not present.
And test a lot :)
-- dd
You should be able to go to your project's Properties (right click on your project) then under C/C++ and Code Generation switch your Runtime Library from Multi-threaded DLL (/MD) to Multi-threaded (/MT).
This way your dependencies to the runtime library will be statically linked and not require you to have any of them installed at the target system.
My source is a C++ MFC project targetting x64. To build the binaries for this project, I added a setup project to my solution choosing the active configuration (x64 and Release). However, I keep getting the following errors :
ERROR: Module 'Microsoft_VC100_MFC_x64.msm' targeting 'x64' cannot be added to a package targeting 'x86'
ERROR: Module 'Microsoft_VC100_CRT_x64.msm' targeting 'x64' cannot be added to a package targeting 'x86'
To me, this indicates that my setup project is targetting x86 whereas my source is written for x64 configuration. So, I tried to explore ways to specify the configuration for the setup project to x64. However, when I go to Build/Configuration Manager, the dialog box only allows me to specify a configuration for the source projects and not for the setup project. So, I see no way to make my setup project also x64.
P.S. Under Active Solution Platform, my platform is X64.
If you select the setup project in solution explorer and then click F4 you'll see a place to set the setup projects architecture, a properties window. That's also where you set manufacturer, productname etc.
I have recently wanted to build a dll plugin for a program. Problem is, the program is 32bit, but by default my Visual Studio 2012's C++ compiler creates 64bit binaries, and I don't know how to change it - I've found the Configuration Manager and tried to create a new platform but there's only x64 as an option.
Am I trying to set the target architecture in the wrong place or what? Is there an update or something I can download so that I can create my dll? Is there a compiler switch that I can set somewhere?
Hope this screen helps:
To build for 32 bit architecture, you have to open project properties window, and then Linker options.
Set the value of Target Machine option to MachineX86.
Check the Build Configuration (Build -> Configuration Manager), and ensure that your DLL project for 32-bit is selected.
Check the linker settings, and ensure correct path is given.
After build, check that .DLL is produced at correct path, and is 32-bit (should be!).
You can use Dependency Walker to check if DLL is 32-bit or 64-bit.
You also didn't mention if /clr option is used with this DLL or not. With /CLR, managed binary is produced. Though this option wouldn't alter bit-ness of the binary, you can just check if this is the case.
I would like to start making my application's 64bit, however, I am not sure on the changes I should make on my sln and vsproj files. What changes should I make to my sln and vsproj to make them 64bit?
On the same note, are there changes to the default sln or project file that are good for game development? I am using Visual Studio 2010.
From the VS menu select Build|Configuration Manager.
On the Configuration Manager dialog, open the Platform drop down and select <New...>.
On the New Project Platform dialog select x64 as your platform and click Ok.
To add to what was said before, make sure you understand why you need 64-bit support. In most cases you won't need access to larger memory allocations. Also, be aware that there will be x86/x64 P/Invoke compatibility problems (if you plan on using third-party unmanaged assemblies - in case you are working with managed C++).
For more information, read what Scott Hanselman has to say about this. Also, just as a sidenote, I would recommend reading this blog post that explains some of the migration ideas.
you need to add x64 solution platform:
Build -> Configuration Manager -> Active Solution Platform -> New -> New platform = x64
if you don't see "x64" make sure you installed it in Visual Studio installer
then just select "x64" as active solution platform and build
My C(++) program, written and compiled using Visual C(++)/Visual Studio, runs fine on my own machine, but refuses to run on another machine. The error message I get is "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem."
If you write a C++ program, it links dynamically to the C Runtime Library, or CRT for short. This library contains your printf, your malloc, your strtok, etcetera. The library is contained in the file called MSVCR80.DLL. This file is not by default installed on a Windows system, hence the application cannot run.
The solution? Either install the DLL on the target machine through VCREDIST.EXE (the Visual C++ Redistributable Package), or link to the CRT statically (plug the actual code for the used functions straight into your EXE).
Distributing and installing VCREDIST along with a simple application is a pain in the arse, so I went for the second option: static linking. It's really easy: go to your project's properties, unfold C/C++, click Code Generation, and set the Runtime Library to one of the non-DLL options. That's all there is to it.
The problem here is a missing DLL dependency, such as the CRT (C Runtime Library). A good tool for diagnosing this sort of problem is Dependency Walker (depends.exe), which you can find here:
http://www.dependencywalker.com/
You would run this program on the computer that generates the error message you posted, and use it to open the exe that's generating this error. Dependency Walker will quickly and graphically indicate any DLLs that are required but not available on the machine.
Chances are high that you miss the runtime libraries of Visual Studio (CRT amongst others), you can either get rid of those dependencies (link statically) or install the VC redist packages on the target computer.
Depending on the Visual C++ version you use, you have to install different packages :
Visual C++ 2005
Visual C++ 2005 SP1
Visual C++ 2008
Warning : those packages only contain release versions of the libraries, if you want to be able to distribute debug builds of your application you'll have to take care of the required DLL yourself.
It is much the simplest to link to the runtime statically.
c++ -> Code Generation -> Runtime Library and select "multi-threaded /MT"
However, this does make your executable a couple hundred KByte larger. This might be a problem if you are installing a large number of small programs, since each will be burdened by its very own copy of the runtime. The answer is to create an installer.
New project -> "setup and deployment" -> "setup project"
Load the output from your application projects ( defined using the DLL version of the runtime ) into the installer project and build it. The dependency on the runtime DLL will be noticed, included in the installer package, and neatly and unobtrusively installed in the correct place on the target machine.
The correct VC Redist package for you is part of your Visual Studio installation. For VC 8, you can find it here:
\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86
POSSIBLE SOLUTION........
EDIT: (removed most of my post)
Long story short, I was having similar problems, getting the "Application Configuration Incorrect" messages, etc etc.
Depends.exe was only finding ieshims.dll and wer.dll as possible issues, but this is not the problem.
I ended up using the Multithreaded (/mt) compile option.
What HAS worked though, as a workable solution, is making an installer with InstallShield.
I've selected several merge modules in installshield builder and this seems to have fixed my problem. The modules selected were:
VC++ 9.0 CRT, VC++ 9.0 DEBUG CRT, and the CRT WinSXS MSM merge module.
I'm pretty sure its the WinSXS merge module that has fixed it.
DEBUG CRT: I noticed somewhere that (no matter how hard I tried, and obviously failed thus far), my Release version still depended on the DEBUG CRT. If this is still the case, the InstallShield merge module has now placed the DEBUG CRT folder in my WinSXS folder :) Being somewhat of a novice with VC++ I assume that this would normally be used to distribute debug versions of your programs to other people. To test if this is what fixed my problem I removed the DEBUG CRT folder from the WinSXS folder and the application still worked. (Unless something is still running in the background etc etc - I'm not that into it)
Anyway, this has got things working for me on an XP SP3 fully updated machine, and also on a VMWare XP SP3 machine with the bare bones (.net 3.5 and VC++ 2008 RTM basically) - and also on a mate's XP machine where it previously wasn't working.
So give these things a try, you might have some luck.
First thing you must use
#define _BIND_TO_CURRENT_VCLIBS_VERSION 1
or add _BIND_TO_CURRENT_VCLIBS_VERSION=1 to the preprocessor directives.
The problem is related to binding and the manifest types, you can find more http://www.nuonsoft.com/blog/2008/10/29/binding-to-the-most-recent-visual-studio-libraries/
By doing this your application will run with a larger range of runtime libraries versions.
Often times this error is the result of attempting to run the debug version of an application that uses .NET. Since the .NET redistributable package doesn't include the debug versions of the dlls that are installed with Visual Studio, your application will often get this error when running it on any other machine that doesn't have Visual Studio installed. If you haven't already, try building a release version of your application and see if that works.
Note also - that if you change to static runtime, you will have to do the same for MFC if your app uses MFC. Those settings are in properties->Configuration/General
I ran into this problem and was able to fix it very simply.
Visual studio gives you the option (on by default) to build a manifest for each build.
The manifest was put in the release folder, but it was a different release folder than the exe.
Even when using the setup utilities it was not packaged.
You should look for a file names something like myprogram.exe.indermediate.manifest
If this is in the same folder as the exe (and you have all the dlls) it should run