I have created a windows application and a folder with the release executable and appropriate Dlls.
First problem is that I want to package it all into one setup.exe For this task I plan on using windows default iexpress application....(is there better software available for this...must be free though, since this is only for a university assignment)
Second problem is I want to structure the installation so that the actual program along with included libraries are saved in their disk drive, i.e program files(x86) for w7. And at the same time make a desktop shortcut so its easier to run and access for the user.
The issues arising with my second problem is:
Am I wrong to assume that a user will have a 'program file' folder ??
I am thinking of making a vbscript to handle the creating shortcut, but does a vb.exe also need library files to be included ??
Assignment due in 2 days so I would really be grateful if I could get this off my chest
Thx :)
You may be interested in following SW:
Advanced installer
NSIS
WIX
I would recommend first option, it's free for your purpose, you don't need to buy professional license and you can make MSI package in 5 minutes.
No, Program Files folder is common to the valid Windows installation. But you shall not assume that it's always C:\Program Files. You must use corresponding environment string to get program files folder:
%ProgramFiles% - to store 32 bit programs on 32 bit OS and 64 bit programs on 64 bit OS.
%ProgramFiles(x86)% - to store 32 bit programs on 64 bit OS.
VBScript has nothing to do with Visual Basic (VB.exe) itself. It's running by Windows Script Host and does not require any additional libraries. Windows Scripting Host is included by default into any modern Windows OS.
You just create script source file with extension .vbs and run it as any usual executable. Example of creating shortcut could be found here.
You have an environment variable ProgramFiles with in it the path to this folder.
Doesn't include the software you used to build the exe and dll files an installer/packager ?
Otherwise I would search a free packaging program, it should be the easiest way, making the shortcut could also be done by this package. On the other hand if you want to use vbscript you could do it all from there too but your script would have to be executed by the user with administrative rights, not for the everyday user...
free packaging: Some googling gave me http://www.windowsnetworking.com/articles_tutorials/msi-packaging-tools.html, check it out
Related
Today I build my application and packaged the installer with QtIF. It worked nice on my computer but complained about missing msvcp140_1.dll in another computer.
Then I run find . -iname "msvcp140_1.dll" and found more than five different ones on my computer, I checked the md5sum.
Then I spend the time to try all of them on the other computer and all seem to work fine. No more complains about missing DLL.
How should I choose between the DLLs? Just pick any seems too easy.
Is there someway to inspect the DLLs, to check for a version?
I believe that DLL was a dependency from another binary included in my application, was not that the QtIF failed to include it.
Call the MS Redist Installer from your Installer. This can be done quietly, so that the end user does not notice it.
Find the vcredist_x64.exe file (or vcredist_x32 for 32 Bit applications), add it to your installer,
let it extract to the "TEMP" folder
and then call vcredist_x64.exe /quiet at the end of your install.
This has several advantages:
You will definitely copy all required files to the users computer.
Should new versions of the runtime library be released by Microsoft and should they already be on your users computer, your code will use the newer versions, which may include bugfixes.
Windows Update may also update the libraries.
That said, it is possible to copy the DLLs themselves, but you should make sure
a) you choose the right ones
b) they come from a trustworthy place, i.e. your VS installation folder
c) reside in the same directory as the executable - otherwise you will run into trouble with manifests.
The reason you might want to include the DLLs directly is if you want to reduce the overall size of your installer.
We did this a couple of years with our products, but finally gave in and simply used the vcredist_x64.exe, even if that increased the installer binary another couple of MB in size. But in the long run that's the easiest way.
I think (not sure), msvcp140_1.dll is an additional DLL for the VS 2019 runtime. VS 2017 runtime does not need this, but the new one does.
The non-redistributable method is to ship the DLL's that come with your compiler, i.e. the compiler that built your executable. After all, the DLL will be loaded into the same process as your EXE. It's only logical that these should match.
You'll find those DLL's in \Program Files*\Microsoft Visual Studio *\VC\Redist
I'm having a difficult problem to solve. I'm having two Qt-based applications, first one is in the main folder and the second one is located in it's subdirectory (yes, I'm forced to have it this way). The issue I'm facing is that I have to deliver 5 exact the same DLL's files for each application. I wouldn't have problem with that, if they wouldn't weight so much (10 DLL files = 60~ MB). Which is, definately too much.
On my debug build I am able to set the PATH variable within Visual Studio settings, and I will be not able to do so on production machines.
Is there any way I could set one of those application to rely on DLL files located in subdirectory?
I don't know what kind of an installer you're using, but the dlls should be stored only once in the archive, and the files should be hard linked on installation. So it's a non-issue unless your installer is broken or the install script is.
I have finished with my "Study Timer" project which I had developed in c++ using SDL and an eclipse IDE but I am new to Eclipse and I would like to know about a way to get Eclipse to produce a new package out of my project which i can directly supply to the end user (similar to how a .swf file is created after publishing a Flash project) that does not contain the various files and folders required only for compilation!.
Specifically:
I have many files and folders in my project that are necessary for development but not for execution!
For example, my project contains: src/ , headers/ , images/ , fonts/ ,Debug/ (contains the actual exe file) , other dll files required to compile and run...
But for execution, I only need the Debug/ , images/ , and Fonts/ !
Is there a way by which Eclipse can automatically generate a clean finished project that can be supplied to the end user?
Is is possible to produce a new executable file that is not dependant on the images and fonts folder but rather have them embedded to produce a larger .exe file (similar to a .swf that contains all the dependant media)?
For a C++ project in order to deploy it to end-users, you just need the executable(s) applications plus any system-specific dependencies (you can inspect them with Dependency Walker and find the installer for the redistributables or package them along with your app). Notice that C++ executables are NOT portable across platforms, so if you compile an exe file for Windows, it will NOT run on Linux or Mac.
Then you might need an installer to deploy everything and install it (if install is needed at all) into another user's system:
A free and easy to use one: http://www.jrsoftware.org/isinfo.php
A professional and opensource not-so-easy-to-use one: http://nsis.sourceforge.net/Main_Page
A commercial professional one: http://www.installshield.com/
Not sure: if you're asking for "what should I give the users from my Eclipse C++ project?" then you should give them a Release version of your application. Release means "optimized and without debugging aid", it will almost surely be faster and smaller than your Debug-folder executable. Then package it as I described above.
In Eclipse you can switch to "Release" (assuming a standard C/C++ Eclipse IDE) from
Build Configurations->Set Active->Release
As already stated, a Release version doesn't contain debugging code (useless for an end-user and even potentially dangerous if you have code that you would like users not to know anything about), it is optimized (debugging code is easier to read even in assembly mode and easier to analyze for bug trackings) and thus the executable is often way smaller in size.
After question update: for your executable to use embedded resources (i.e. reference things inside its own binary executable rather than relying on outsie files) you need a resource file to include and link into your executable. This depends on the compiler as well (Eclipse is an IDE, something that helps you writing code but it's not the program that really creates your exe file.. something that lies under the hood of Eclipse and to which Eclipse "communicate" what to generate).
i am using c++ in eclipse, a project which contains many header files , cpp files...etc when finally done, how does it actually get implemented in the real world once it is done? Does an .exe file get created ? Or how can users install the program on their computers?
Can you share your experience with me ?
Also can you tell me what IDE you use for C++ development ?
I tried to look through some documentation but could not find anything.
When you compile the code, it will output an executable file (.exe) that can then be run from a command line, double-clicked, or put into an installer. The executable files name will be .exe and placed in the output directory as specified in your project settings.
As mentioned, this can be bundled in an installer but that is very likely overkill and way beyond what you want. So long as you have used standard C/C++ libraries that come installed on a user's system, they can just invoke the program from a command line or simply double-click the executable. If your program doesn't have any interface and simply prints messages, then they person will want to run it from the command line. Finally, if you have used other libraries that you need to include with your program, then an installer may be what you need in order to make sure the end user has everything they need to run your program.
As far as IDE's go, I've used both Eclipse and Visual Studio. Visual Studio is better tailored to C/C++ development (this is assuming you are programming on a Windows machine) but has the downside of costing money if you don't get it through your employer or school. If you can get access to it through either of those channels, I would choose it over Eclipse. Eclipse will do what you want and is free, but Visual Studio might be a bit better. Also, if you are going to spend money anyway, I suggest looking a SlickEdit. I use this at work and really like it for C/C++ development.
I've got an SDK I'm working on and the previous developer just dropped the DLLs in System32 (Apparently a serious offense: see here)
So assuming I move them out into \Program Files\\SDK (or whatever), how do I make sure that all the apps that needs those DLLs can access them? And to clarify, all apps that access these are doing early (static) binding to the DLLs at compile time so I can't pass the full path to them or anything. They need to be able to find it just given the DLL filename only.
Along the same lines, what about including a particular version of MSVCR80.dll? They all depend on this but I need to make sure they get a specific version (the one I include).
Any ideas?
An SDK is by definition a development kit. It's not a deployment patch...
What this means is that the applications that depend on those assemblies should ship with them and install them into their local \program files.. directories.
The reason for this is let's say you decide to do a breaking change by eliminating an entry point for example. By installing your "SDK", it has the potential to stop older programs from functioning.
You could take a play from the Java handbook and update the PATH environment variable. Whenever a program makes a call to an external assembly it searches along that environment variable until it finds it.
Of course, this could still result in the problem showing up. So your best bet is to just install the SDK into Program Files and let the developers of the products that depend on your toolkit decide whether they want to update their versions or not.
UPDATE
As I'm thinking about this, one last possibility is to GAC your assemblies. In the event you do so, bear in mind that they should be strongly named and properly versioned so as not to step on each other. I don't recommend this route because it hides the actual locations of the assemblies and makes uninstalling a little more difficult then simply hitting delete on your directory.
I can't tell you about your own DLLs, but you should never redistribute Microsoft DLLs alone.
You always have to use Microsoft Redistributable Package.
For example, if your application depends on dll from Dev Studio 2005 SP1, you should redistribute your application with Microsoft Visual Studio 2005 SP1 redistributable. The same applies to 2008. MS provide MSI based installer and Merge Module to include in your own product installer.
You are asking about "DLL Hell", something I had thought every Windows developer was familiar with. The order of search for DLLs is:
the directory the exex that calls them was loaded from
the current directory
various Windows directories (as discussed in your previous question)
directories in the PATH variable
As the Windows directories should be ruled out, that leaves you with three options.
You can put your install path in the search path, which will allow the applications to find them.
Alternatively, you can deploy the DLL's into the same directory as the application that depends on them.
I believe the first is better from an SDK perspective - it'll make development easier. But I think the second is better for when the application gets deployed to end-users, unless you expect there may be many consumers on a single system so the disk and memory footprint of having copies of the DLL are prohibitive.
If you can't install the dlls into the same directory as the exe using them you could append your directory to the PATH environment variable.
You don't say which version of Windows you're using, as the details are slightly different from what I remember.
You could also put your version of MSVCR80.dll in the same folder. However, you'd have to ensure that your folder was before the system one on the path otherwise the linker would pick up the "standard" one first. However, if you adopted the "local" dlls approach then you wouldn't have this problem as Windows searches the local directory first and so will pick up your version of MSVCR80.dll.
Is your version the latest or a previous version? You might be better off getting your app to work with that version or later and then allow the users to update their machines as required. This also illustrates why you should never mess with the dlls in \Windows or \Windows\system32 as, as others have pointed out, you could break other applications by changing the version of this dll.