I am looking for a program that can take the program I made in Visual C++ 2008 and distribute it in a mature installer for Windows. I want an application that is FREE (or trial).
The setup and deployment folder is not there when a select File-->Add-->New Project
You can try NSIS (Nullsoft Scriptable Install System), which is free, but can be confusing because it's lots of scripts. That said, it can do anything you might want to do.
Install Creator from ClickTeam is very simple to use and is my preferred application but it does cost money.
WiX has a fairly steep learning curve, but it gives you full access to all features of Windows Installer, with no limitations. It's originally an Microsoft project, and is what Microsoft uses internally for many of its products. It's free and open source under the Common Public License (which permits its use in closed-source products without requiring you to license your own code under it).
For a setup .exe I like Inno Setup, which will let you do desktop icons, amongst other things. Basically you create an Inno Setup installer file which you can pass into the setup compiler which means you can also build it from the command-line. They provide both a GUI and a command-line compiler. The bundled documentation is also very complete.
For MSI you can try the Windows Installer XML (WiX) toolset., which is similar to Inno Setup in that you can compile from the command-line, but a certain amount of Windows Installer / MSI knowledge is expected.
Use setup project in Visual Studio
Check the following programs:
Inno Setup
NSIS
Don't forget to include Microsoft Visual C++ Redistributable Package
Take a look at InstallJammer. Free, open source and easy enough to make a simple installer in minutes while also supporting complex, scripted installers if you find you need them.
Related
I would like to be able to compile C and C++ code under the Windows environment without using an IDE, just by using the Windows Command prompt (cmd.exe).
I come from Linux, where you are be able to install the gcc package with just a command in the terminal:
$ sudo apt install gcc
I wonder if there is a C/C++ compiler collection in a package inside the Windows install folders, just like the ones in Linux, I just need to install.
What also gives me a reason to ask this question is:
Since the kernel of Windows and the Windows API are written in C, and many of the high-level applications of the actual Windows 10 release are written in C++, it would be reasonable to also directly provide a suitable compiler suite. This is my thought modell, does not need to match reality.
Thanks for your help.
Since the kernel of Windows and the Windows API are written in C
Microsoft doesn't ship a compiler, or the required Windows SDK headers/libs (also includes a bunch of other useful development tools) for Windows in the installation.
Microsoft Visual C++ (part of Visual Studio) would be the equivalent "built in" choice although I am not sure if Microsoft ever specify exactly which version they use for a given Windows build and it is common to have lots of software built with different compilers/versions (including the various non-Microsoft ones).
As well as the full Visual Studio package with the IDE and other tools. Microsoft provide some components separately, such as the Build Tools for Visual Studio 2019.
I am sure this is for many reasons like most users not being interested in compiling their own software, and Microsoft still sells Visual Studio separately to larger organisations (historically to most serious users, but "Community" edition is now pretty nonrestrictive for individuals and small business).
Strangely enough it doesn't come with a C compiler, we need to install one, Mingw-w64 is allways my choice, you will need to add the path in environment variables (step 12), if you want to use it anywhere. You can then use the gcc command where it's more convenient like in Linux, don't forget to open a new cmd after the changes for them to take effect.
Unfortunately, Windows doesn't have the command line tools for installing/removing stuff and the great repository infrastructure we know and love from Linux.
You will need two things:
The command-line build tools. These can be found on the Visual Studio Downloads page under Tools for Visual Studio -> Build Tools for Visual Studio. This will include the compiler (cl.exe) and linker (link.exe) for the MSVC build toolchain.
The Windows SDK. The latest version of the SDK can currently be found here. This page has a tendency to move around, but googling for Windows SDK usually gives you the right page immediately. The SDK contains all the headers and libraries required to build Windows applications and make use of the Windows native API. The Windows SDK contains a lot of stuff which you may or may not need. You will almost certainly want to install the Windows SDK for Desktop C++ x86 Apps and Windows SDK for Desktop C++ amd64 Apps components. Most of the other stuff should be optional, but some of it is nonetheless highly useful.
You may want to download additional packages such as the Windows Debugger (which is an entirely different application than the Visual Studio debugger) or the Driver SDK, depending on what kind of things you want to develop.
Note that even if you don't intend to use the IDE in the end, installing the full Community Edition of Visual Studio is a far more convenient way to get a working build environment, so unless you have a really good reason not to, just go with the full package and choose to never open the IDE.
The built in compilers available on Windows 10 are for VisualBasic, C#, JScript.
To improve speed & performance of apps, "ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly".
For low level programmers, ilasm.exe (IL Assembler) ships with Windows, which also facilitates "tool and compiler" development; so you could even create your own language or build a better compiler for a current one, or "debug your code at low level and understand how .NET deals with your high level code", or "write your own compiler for a new .NET language."
For web programmers, AspNetCompiler precompiles server-side ASP.NET web-applications, therefore helps application performance because end users do not encounter a delay on the first request to the application.
All Compilers & assemblers come as builtin with Windows without IDE and can be run from "the Windows Command prompt (cmd.exe)", so no extra downloads necessary; located in folder: C:\Windows\Microsoft.NET\Framework\vx.x.xxxxx\ .
Note: C# is based on JScript.
Compilers:
vbc.exe
csc.exe
jsc.exe
ilasm.exe
ngen.exe
aspnet_compiler.exe
Addendum:
If you still are looking for a C compiler to handle some C source codes you already have spent your life on, then (without downloading) you can make/write a C compiler, in a high level language, then optimize it with a low level language.
This guide will "introduce you to the high-level architecture, theory, and .NET Framework APIs that are required to build your own .NET compiler" in C#.
You can to use gcc for windows. For e.g. mingw, tdm-gcc, mingw-68, Cygwin etc. Each of them allows you to work on c/c++. But if you are not sure about the installation process, and don't want to do all the work by yourself, the easiest solution is to download something like dev-c++ or code-blocks.
cygwin: https://cygwin.com/
mingw-64: http://mingw-w64.org/doku.php
Downloadable file can be found here (for mingw, dev-c++): https://sourceforge.net/
You can also install Microsoft compiler. I usually do it by installing the whole visual studio.
I have a project that requires writing a code for small executable file. I used visual C++ express 2010 IDE to create this file. After I finished writing the code, I tried to copy it to a couple of different PCs. It gives me an error message every time I clicking on this file to execute it. The message states that I have to install (.NET framework). I watched a couple videos on YouTube explaining how overcome this problem by changing the runtime library from multi-threaded Debug DLL (/MDd) to multi-threaded Debug (/Mtd). However; the IDE can’t debug the C++ code because when I create my project by using CLR template!
Is there any way to solve this problem? Can I create a similar program that not requires any further downloading once I using on different PC?
Is learning a different language like JAVA or C# will help creating small programs (like my program) that run on most Window platform machine?
Just use Qt - it runs on Windows, Linux, MacOS, support for Android and iOS is scheduled for this year, plus it supports embedded platforms and some of the more obscure mobile platforms. Also, support for Windows RT was just kickstarted. A complete library with tons of functionality, good documentation and lots of educational resources. It provides tons of tools, from implicitly shared containers through threading, signals and slots, 2D and 3D graphics, widgets, multimedia, sensors... and whatnot...
You can even develop commercial applications under the LGPL license.
Also comes with a pretty good IDE - Qt Creator.
You can develop standard C++ applications or use QML, which is a JavaScript like language for markup and scripting, which is used to build applications from C++ implemented components. You can also extend QML. It is much faster to develop with QML and you still get the advantages of platform native binary under the hood.
Note that you will still need to either ship a few DLLs with your application. Unless of course you use a static build, which requires you to either have your application open source, or purchase a commercial license... which doesn't come cheap...
But still, a few MB of DLLs are far better than the entire .NET framework. A static build will produce executables about 8-9 MB with no external dependencies.
Stick with the C++ standard, avoid Microsoft extensions (managed code), and call only POSIX functions of your OS, then you should be able to write portable programs.
You seem to have created a Managed C++ Project. Instead create an empty Win32 C++ project and then add in your .cpp/.h files. This will limit you to the default libraries available on all PCs with the C++ runtime. If you want to remove that dependency too then statically compile in the runtime using the /MT option. Details # http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx
As you move ahead you would need to be conscious of what libraries you take dependencies on and what versions of the OS are those libraries available on or if you need to package them with your bits.
Both Java and C# will help making portable programs. Usually, people will have to install runtime environments for executables written in these two languages, however. These days, C++ is more portable than ever. You can easily run C++ executables in your browser:
https://github.com/kripken/emscripten
http://code.google.com/p/nativeclient/
This makes many of the reasons why Java and C# came about irrelevant.
Open standards like OpenGL also make portable GUI programming easier than ever. Try Qt, if you want to write a simple GUI in C++.
Note: It is possible to run C++ program in any computer without installing anything if you haven't use .NET framework. In your case, there can be two reasons to trigger error in target computer.
New computer doesn't have required run-time assembles.
New computer doesn't have required .NET framework installed.
..........................................
So what to do:
Before start your program you have to design weather are you going to use .NET framework support or not. If you use .NET framework when you develop your program, then you much install same or higher .NET framework in target computer.
If you no need to use .NET component then your target computer should only containing run-time assemblies.
How to get rid of .net framework
right click on the project in solution -> properties -> General -> Common language run time support -> select "No common language run time support".
..........................................
Then what you need is only relevant run-time assemblies be in target computer.
How can run-time assemblies be in new computer:
There are two ways:
Install suitable C++ disputable environment in target computer(if you use VS2008 SP1, C++ RD package should be this. Please consider the solution build architecture also (32 bit/64 bit) before download ).
Deploy run-time assemblies with your solution package. (I like this because user no need to install any third party components)
..........................................
How Deploy assemblies with my project:
for this your all DLL, LIB, EXE should use same run time version.(if not, you face troubling to redirect assemblies by 'manifest' files ).
How to check the run-time version.
open DLL,EXE by visual studio (open->file) -> expand RT_MANIFEST-> double click the file under it ->then assembly dependency details will open. -> copy the data in right column and paste to note pad.
You will see this kind of line there. and ther is the version run-time assemblies your specific DLL or EXE use.
assemblyIdentity type="win32" name="Microsoft.VC90.CRT" version="9.0.21022.8" processorArchitecture="x86".....
After identifying the version of run-time assemblies follow this tutorial and try to run in fresh installed computer.
At last: If you think this bla.. bla.. is so complex and your program is very simple, then you can consider about "run time assemblies statically linking" (try Google). But personally I don't like this method.
good luck!
In particular we are developing for Intermec CK30/CK31 running Windows CE. We have an existing C++ project that also targets newer devices (running Windows Mobile 5/6).
The guy who has left this with us, just used to use both environments to develop the one set of source. But I would rather ditch one and develop for all in one environment.
You should be able to use VS2008 for all your development. You'll need to install the platform SDKs for the Intermec and WM versions (WM 4.2 and 5.0 standard should be there by default). VS2010 doesn't yet support Windows Mobile/CE development.
If you are using different environments with different versions of visual studio, you might want to have a look at the cmake builder.
It is a meta-build program, in that it creates a requested build environment (eg. VS2005 or VS2008) for you. You maintain one set of source code and then choose what IDE/compiler to use to build/modify you code. And each developer can choose a different IDE/compiler.
This would be a good compromise, as you are separating your code from your compiler/IDE, and cmake makes it no effort to drop/revive a target compiler/IDE should you wish to later.
My company is thinking of dumping InstallShield and move to something else, mainly because of the poor experience it had with it, mostly on Linux.
Our product is a C++ application (binaries, shared libraries) targeted at Windows and Linux (Red Hat).
The installer itself isn't required to do anything special, just dump some binaries and shared libraries and sometime execute an external process. Things like version upgrading through the installer isn't necessary, this is handled after the installer finishes.
I thought of suggesting using NSIS on Windows and RPM on Linux.
What are the recommended installer systems to use when deploying to Windows/Linux? Something that is cross platform to prevent maintaining two installers is a definite plus.
For Windows I would definitively use NSIS. It's very lightweight, easy to code and very simple to understand. Using msis would just be a killer - it generates guid for every file so you can get upgrades for free and stuff but truth being said, you never end up using any of these.
Regarding Linux I would go for RPM and Deb. They're probably the two biggest packaging system so you'll be targeting most of the Linux users. I've never tried RPM but creating a Deb package is fairly straightforward.
See also:
What to use for creating a quick and light setup file?
Packaging to use to deploy cross-platform?
And even:
Creating installers for complex cross-platform programs
There's a tool called BitRock Installer which can create installers for Windows, Linux and OS X.
However, I think that if you target RedHat it would be better to provide native packages for that platform (that is .rpm).
For C++ projects, I'd go with cmake/cpack, if you are also willing to change your build system. Great support, strongly cross-platform. cpack has various generators, NSIS is one..
Take a look at InstallJammer. It will handle both platforms from the same build project, and you can have the installer register the package with the RPM database as well if that's your requirement.
You may want to consider our tool BitRock InstallBuilder , it can generate installers for Windows and Linux from a single project file and also RPMs. Is your application based on Qt? Our clients include the makers of Qt, Nokia (previously Trolltech) and they use it to package their Qt Creator product. We encourage to give InstallBuilder a try and contact our support with any questions or suggestions you may have.
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.