I've been asked to make a simple installer with Installshield 2010 Professional. The combine size of the files to be installed is about 2 megs, but the resulting installer is about 5 megs. I would like to know if there is a way to tweak the installshield project so I can have a smaller installer.
Thanks!
Probably not. Those extra 3mb are InstallShield's code for installing your files.
You could zip the compiled installer into a compressed, self extracting archive, perhaps, if you simply want to reduce the size of the installer on disk. Furthermore, it looks like WinZip itself supports simple file installations if you don't need the advanced logic that InstallShield provides.
Related
Let's say I have 2 features, both use abc.dll, and both reference it from their respective current directories.
So the output will look like this :
Feature1
abc.dll
Feature2
abc.dll
I've created 2 components for this. In reality I have many features and many dll's that are shared, and my installer size is nearly 1GB.
What I am looking for is a smarter way to do this, using IS 2015 professional.
What I've looked at so far:
Merge modules: Not sure if this would work, also it means I need to maintain the merge modules manually should files be upgraded.
DuplicateFile, via direct editor, but this wouldn't work because there is no way to have this bound to a feature, only a component.
A hidden feature which would install the shared files to the target system, then a post script which would copy these files to their respective features, and delete the folder of this feature.
Is there a best practice method to implement what I need?
The most suitable approach in this case is, indeed, merge modules. I am not sure why the concern about maintaining them - you should have an automated build process that creates all merge modules and then builds your main installer with the newly created modules.
However, in my opinion, merge modules are a bit cumbersome to use if you have a lot of custom actions.
An alternative to merge modules - assuming you are using a Windows Installer project - is using small MSI packages which you "chain" to your main installer (you can chain multiple packages with different conditions and supply different properties). Here too, you should have a build process which builds all those small msi packages and then builds the main installer.
If you don't want to have this kind of 'sub-projects', then the option of a hidden feature with a post action is acceptable, I've seen it, and done it, a few times. Note that if you target Windows 7 or later, instead of physically copying the files and deleting them, you can use symbolic links (using the mklink command), which helps reduce the installation's foot print on the target system (and make patching easier - you replace the original file, and all its links are updated automatically).
Our jenkin process builds and produce an MSI. during process when it first builds, it produce msi(say 500kb.msi). this MSI is already digitallysigned. After that it resigns(not sure why) and generate msi(say 496kb.msi). 2nd Msi have difference of 4kb in size. I have extracted both MSIs using the lessmsi tool and compared both extracted contents and realized both are exactly same.
Problem is, when client try to install 496kb.msi it is not producing expected behaviour. Only difference between them I can see is digital signature. And both have been signed with sh1.
Any help with this will also be helpful, however, my question is, what does installer is bundled with apart from files and folders. Before extraction, It had a difference of 4kb and after extraction size for both are exactly same. Where does this 4kb consumed in case of first MSI?
An MSI can be very complex, not just a simple file/folder manager. It can have custom actions (code) that modify your system, or predefined MSI tables that also modify the system.
The easiest way to find the difference is to diff the MSIs with SuperOrca, it is a free tool. It should highlight the different tables.
I'm a little late with this question, but better late than never. I've been using Visual Studio 6.0 since it came out, but recently switched to VS 2013 on a new PC.
I've gotten my projects to build under 2013, but the resulting executables it produces are consistently bigger than VS6.0 produced. I've seen a similar thread on here about that happening in the transition from VS2008 to VS2010, and the comments and suggestions there all seem to attribute the change to changes in MFC libraries that are statically linked in. But my projects are straight C code. No C++, let alone MFC. And the 'Use of MFC' option on my project is set to "Use Standard Windows Libraries" (presumably set by the import tool that generated the 2013-compatible project). The only non-stadard library it uses is wsock32.lib.
The extra size isn't a killer, but it's a significant relative to the size of the whole app. My biggest .exe goes from 980Kb to 1.3Mb - about a 35% increase in size to an app whose small size was a selling point (i.e. install this tiny app and you have access to all of our goodies). That's without debugging info - the increase on the debug version is even more - but I don't really care about that.
Any ideas how to strip out the new cruft - or even to know what it is?
This is a good manual how to make your binaries smaller.
Basic ideas are the following:
Don't forget about Release mode
Declare #define WIN32_LEAN_AND_MEAN
Dynamically link to the C++ runtime
Compile the executable without debugging information
Compile with /O1, an 'optimize for size' flag
Remove iostream and fstream headers, use low level instead if possible
Typically you generate a MAP file on both systems, and figure out the sections that cause the largest contributions.
Anton's answer reminds me: first check if they are both linked the same way (both static or both dynamic, otherwise it is apples and oranges)
Lets say I have a C# DLL that is 100 MB. Now If I wanted to update this DLL as far as I know I would need to get another DLL by downloading it, delete the old DLL and then move this new one in its place to "update" the DLL (Lets assume the assembly's that reference this DLL do not care about the version of the DLL).
Is there a way to create a file with has all the classes and items that have changed (ONLY the stuff that has changed) and recompile the DLL to have these changes, or some how update the DLL with those changes?
The goal is to have a way to update the DLL through small patches without having to re-download the entire DLL.
Thank You
You use the same mechanism version control systems use - SVN for example happily stores only the changes between different binary checkins, and on some dlls that can turn a mb dll into a few k. (obviously your mileage may change)
Generally binary diffs are not nearly as efficient as text, which is why its not often used, but it can work for some - it depends on how the binary is laid out, if the compilation process produces something that is generally the same, rather than completely different.
You'll need some code on the client to pull the changes down, either use the gnu patch tools, or use something like Windows BITS.
I opened hello.cpp. Why isn't there File -> Compile -> hello.cpp? What is an other easy way, if any?
The file must be part of a project before you can compile/build it. Starting with VS 2005 (or maybe 2008), you can use File -> New -> Project From Existing Code to wrap a project around source files.
Or, you could use something like notepad++ and write a script that compiles with the windows 7/Visual studio C++ compile (CL.exe). That could work as well and do what you describe. C++ was meant for medium and large size projects that require performance and space efficiency. If you want to practice you could use the method I described but otherwise I'd recommend using something like Python/Java/PHP/etc to crank out applications that can take the performance hit of an interpreted/JIT compiled language. This will allow you to develop at a rapid pace. I prefer C++ myself but I use the approach very frequently.
The best way its to create an empty project add your hello.cpp then Visual Studio will build your program.