I have a swing application running perfectly fine on Linux. The application depends on third party libraries. Now I want to create an installation package of this application, for windows. I am using Launch4j and NSIS for this.
The third party libraries are in a folder(106MB size). When I am trying to create a package by running makensis command,it never completes (I have to abort it explicitly).
To resolve this, I thought of using ZipDll plugin of NSIS. But when I try to zip this third party library folder, I get warning name not matched for all the contents of the folder and this also goes on(infinite loop), never completes (again I have to forcefully abort it).
.tar.gz works fine but then ZipDll plugin is not able to extract from .tar.gz.
What should I look for in this case?
Does NSIS restrict on the size of folders?
Why does zipping goes into infinite loop with that warning (I looked into many similar posts related to this warning, but nothing could resolve this)?
Is there any NSIS plugin which can extract from .tar.gz folder?
The third party library folder contains many sub-folders each having .sdf.gz files in it.
NSIS is restricted to 2 GB file size - the resulting setup (.exe file) have to be max. 2 GB large.
Your situation is strange, 106 MB is not a problem for NSIS.
Can you paste log from makensis output - what is happening when you have to abort setup creating?
Thank you for the help. The problem was with the directory structure. It had few soft links which linked to other computer and was trying to package everything there(infinite loop).
I got it fixed. The problem was not with NSIS
Related
we actually build an InstallShield project for our application with the functionality to include files dynamic into a component. All files will be taken which are in a specific place.
Because of problems, which are not part of this question, we want to change this to components where we add files explicit to custom separated components.
The question is, is there a best practice for this? We have the small fear that we easily can forget to add files to the component we new created. These can be dll files, .config files, pdfs or just xml.
(We build the installer every night using TFS.)
We found a solution for the problem.
What we wanted to solve:
During the build we want to be informed if files got removed
During the build we want to be informed if new files are missing
we solved this by two more or less easy things.
1. Information if a file is removed
This is easy sone, we have all files added explicitly, each single file is an own component now, if one file is missing the whole project does not build with the exact error message.
2. Information for missing files
For this we wrote a small tool which runs by a prebuild event of the installshield project.
There it opens the *.ism file as an xml file and searches for the "Files" table.
Than it takes all files from the drop folder and looks if all files are in there.
If there are files missing but we don't expect them, like pdb files or test dlls, we have an additional text file we just called "IgnoreList".
The tool skips these files by the check.
Now we are on a very good state to get informed directly on the next morning if the project was able to build or not, and if not what happened, so we can be sure that in the final target application are files are there :-)
I'm pretty new to InstallShield - so bear with me.
I have created a Basic MSI installer that correctly installs our application and, until recently, every time I rebuilt it (with some new files for a new build of our application), it would replace the files with no issues.
However, I rebuilt it this morning with a new version, it flat out refuses to replace any files.
For example, out main exe now has a file version of 8.0.0.15, the one it is replacing is 8.0.0.13; the new modified and created date is 7/11/2013, the one it is replacing is 6/26/2013 for both - it still wont replace the old file with the new one (this is just 1 file in hundreds, but is the main exe and so it definitely gets changed with each release).
I have changed the properties of our own exe's and dll's to 'Always Overwrite' under 'Files and Folders' to no avail (I haven't touched the 3rd party dll's since they never changed).
I have changed the ResintallModeText to 'asum' to no avail - should I try 'asumv'?.
Before I have the application completely uninstall itself prior to reinstall, is there anything else I should be looking at to try and determine what may be preventing the installshield from replacing the files on the target machine?
I have no idea what could have changed to cause it to stop upgrading - we haven't had to make any changed to the installshield for some months since everything was running fine.
If you need logs or anything, let me know (though I can't get it to write out the installshield verbose log on install - but I can provide the Windows installer logs).
Thanks for your help!
Thanks to the comment from #anand which solved my problem as well. In my case, the executable was not updating even when I updated the product version (i.e. 1.0.001 to 1.0.002) and changing the package code for a new build.
The solution for me was to right-click on the executable in Files and Folders (in InstallShield) and select Properties. After checking "Always Overwrite" my executable now gets updated regardless of the product version or package code.
I'm trying to get my website to talk to a friend's program. Think ITunes - one main program with hundreds of thousands of little things installed into it. We don't want to have to create an InstallShield install program for each of those hundreds of thousands of little things.
We have the files grouped into the folder sub-structure.
We have a .REG file for what registry entry needs to be added to see the new folder group.
But is there a way to do a self extracting zip file that reads a registry entry so we know where they installed the original program to be able to dump the new files there as well? I want them to double-click the EXE and click Finish and for everything to work.
(I've been looking into INF and CAB files through IExpress.exe, but haven't found the answer. I remember Package for the Web didn't have an option to read a registry entry, but did let you modify the suggested install path.)
Thanks so much.
Best wishes,
Andrea
But is there a way to do a self extracting zip file that reads a registry entry so we know where they installed the original program to be able to dump the new files there as well? I want them to double-click the EXE and click Finish and for everything to work
Well, yes and no. There are self-extractors that can run a program after extracting all files. DotNetZip, for example, can produce an SFX which can do this.
Just an aside: a normal SFX is just a zip file, with a "stub" executable merged with it. The stub exe can do anything it wants to do, but the most basic thing it does is extract the files in the zip. When you use DotNetZip to produce an SFX, it embeds its particular stub into the zip. That stub knows how to extract files, and also knows how to invoke a program after extracting. You can also produce your own stub that can do other more exotic things.
So you could use an SFX for your purpose. When run, it would extract, then invoke it's extra program. The program could look in the registry, then move or relocate the extracted files to the appropriate place. Then terminate.
For a different twist, the SFX might have just two files: the program-to-run (the one that reads the registry, and another embedded zip. Then when the SFX runs it generates 2 files. Then it invokes the program-to-run, which reads the registry, then unpacks the contained zip and puts the files into the desired place.
Ok, so you could do it.
Should you?
mmm, maybe. This really is an installer, so, you should decide whether you want to use a zip as an installer. Don't forget, if you use an SFX as an installer, there's no good way to uninstall.
Have you tried Inno Setup toolchain? It's a bit better than a bare Self-Extracting ZIP file, it's a setup creation utility. I'm convinced it has got something to put some entry in the Registry, look also at the plugins.
Basically, a self-extracting executable that alters the registry, it's a setup program. So why don't you go for a proper one?
Website: http://www.jrsoftware.org/isinfo.php
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.
I wanted to write an NSIS script, let's call it for now setup.nsi, and check
if several required dll files already exists in $SYSDIR
Let me emphasize on the word "several"
What I understand from nsis IfFileExists documentation is that if I type in:
IfFileExists $SYSDIR\blabla.dll +2 +1
then it checks if blabla.dll is in $SYSDIR .. but what if I want to know if *.dll from where setup.nsi copies the file (i.e. the *.dll's that I am interested in installing in.. and they are a lot of them.. so I can't just go around checking for all the names) exists in $SYSDIR
During uninstallation I want to then be able to delete them from $SYSDIR (using some uninstall.log to see if I really copied them in $SYSDIR.. and again the wildcard question).
Please be patient with me as I am really new to NSIS scripts.
Is it REALLY necessary to write and delete in $SYSDIR ? Unless yours is a system file, there's no reason for it to be in $__SYS__DIR. If you need to use a specific version of a library, consider DLL redirection (put your DLL in your app dir and use the .local feature) - see the MSDN article on DLL redirection and Side-by-side assemblies.
Plus, you are one typo away from wrecking the user's computer ("Deleted: C:\Windows\System32\user32.dll").
As Piskvor mentions, I don't think you should be worrying about deleting system DLLs in the uninstaller. In case you want to overwrite system DLLs with an updated version, you may want to look at the SetOverwrite command. It lets you overwrite files if what you've got is newer.
Windows XP (SP2?) and up has file protection for system32, so you can't overwrite system critical files in there.
Do try to stay away from that.
Also, to check for your file specifically, see if there's a plugin for NSIS that can calculate checksums and compare that on uninstall. That's probably the safest, IF you really need to do it.
I'd suggest install files somewhere else and add that to PATH.