I am working with a pure InstallScript installation in InstallShield Pro 2010.
A third-party jar file has been replaced with a newer version in our software. When an upgrade installation is run, the new jar is installed, but the old jar also remains. Bad Things ensue.
How can I get InstallShield to update the contents of a folder, AND delete any other files in that location that are not included in the current version?
I've looked at the Component -> Overwrite options, but this only seems to apply "when the installer encounters an existing file with the same name as the one being installed".
Also, I realize that I could add something to the scripts to remove the offending file, but I need a scalable solution. There will be other files replaced over time, and I'd rather not have to manually add a fix to the installer every time this happens.
Can you just not change the name of the JAR file from build to build?
I'm not aware of InstallScript having a robocopy /mirror style copy. You'd have to script this behavior and I could see it not ending well quickly.
Related
So it appears that when installing a Nuget package that contains additional "non-assembly" files, those files are usually copied to the appropriate locations via a PowerShell script (install.ps1). And this works all well and good, until you check your project into source control; having ignored the packages folder (cause well that's the point right...), and someone else pulls the project. In that case, when that person restores the packages, those "non-assembly" files are not re-installed, despite being copying back down to the packages folder the PowerShell script doesn't run on restore. Forcing that person to determine which packages need to be literally uninstalled and reinstalled to get things working again.
Am I missing something? shouldn't that install script just run every time... I spent several hours today trying to determine why a colleague could not get their project running after pulling it out of source control for the first time.
Is there any work-around or fix for this besides creating yet another script to check for these missing files and:
Update-Package -Id packagename -reinstall
every single offending package, and run that as a pre-build event, just to get things working.
Inno Setup keeps an "Uninstall log" file unins000.dat in the application's install directory. This file contains a list of all the files that are to be uninstalled when the application is removed. When a new version of the app is installed over the old one, Inno Setup just appends any new files to the "Uninstall Log".
An early version of my application removes some user-modified template files when it is uninstalled, because I forgot to include the uninsneveruninstall flag for those files.
In the latest version of the software, the uninsneveruninstall flag is set, and the files don't get removed....... unless the latest version was installed over the broken version. Then, because those files are in the uninstall log without that flag, they get removed upon uninstall!
I can't ask my users to uninstall the old software before upgrading, because then they would lose those files.
Can I force Inno Setup to regenerate the uninstall log from scratch? Or at least remove/overwrite the entries for these files? I want the uninsneveruninstall flag to be retroactive.
You can't change that flag retroactively. Once it's been released, then that's it.
An option though would be, during the setup, to detect the older broken version having been installed (If not by version number, maybe a flag in the registry to say the fix has been applied) and backup the folder in question, perform an uninstall (silently) then restore the folder.
The setup can then carry on as normal.
Using Advanced Installer. When I build and run my install project, after the install there is a folder called MyCompany (equivalent to [Manufacturer]) located within the ApplicationData folder (which resolves to C:\Users\Joey\AppData\Roaming\ on my system).
Within that particular folder is another folder called MyProgram 1.0.0 (equivalent to [ProductName] [ProductVersion].
And within that folder is another folder called install. And within that folder is a file called setup.msi with a size of 1.17MB
I have no understanding of why this file and these folders are being created. Further, after I uninstall my app, they get left behind on the system, which means my app is creating garbage.
Can someone please explain why this is happening? And also...if I can't cause this to not be present in the file system while my app is installed, how can I avoid leaving it behind on the file system after I uninstall?
Thanks.
When you are building an EXE setup file, that is the default extraction folder for the EXE, where you can find all the resources during the installation. You can change it from Media page, "Extraction folder".
It is not deleted after uninstall due a bug in Advanced Installer, you can find more details and a workaround on the forums.
I'd like to remove an entire nuget package, and cleanly install it in my project again.
Sadly, for some reason it skips removing files that have been "modified", and then skips putting them in the project on reinstall, because they already exist.
Is there any flag i can set to unconditionally remove every single trace of a nuget package, alternatively overwrite all existing files?
Thanks.
Unfortunately at the moment, NuGet does not do what you want. During the uninstall process, NuGet will only delete content files if they have not been modified. And as you've noticed, the update process will not update files that were modified either.
The Uninstall-Package command does have a -Force option, but that is to "force" uninstall even if there are other packages that depend on this one.
We can certainly file this as an issue and perhaps incorporate it into a future version.
Another option would be to create a PowerShell script that will enumerate a package's contents, then allow you to delete all the content files. I'll see if there is a simple way to do this.
BTW: Perhaps you can figure out a better way to extend the existing content file other than modifying it directly. Especially since you're losing your changes when the package is updated.
You can now do what you want! (finally)
You need to first update to the latest NuGet (I think this feature was added around April 2013). Do this by going to Tools > Extensions and Updates and click on Updates to update nuget.
Then the -FileConflictAction parameter will allow you to overwrite files.
Install-Package Microsoft.jQuery.Unobtrusive.Validation -Version 2.0.30506.0 -FileConflictAction Overwrite
(PowerShell Command Reference for Install-Package)
The NuGet Version 1.6 HAS a remove package function!
http://docs.nuget.org/docs/release-notes/nuget-1.6
if the update of the extension fails (signatur missmatch), just uninstall and reinstall. this is a known problem.
I think this happened to me a few times. Go to the packages.config file that should be the root directory of your project and remove the insurgent (in your case the line with the package: SignalR). This will tell NuGet that the package was never installed.
Now you will be able to reinstall it through the repository, then uninstall it so everything is back to the way it was before you got into this mess. I am unsure how it is occurring.
I can't find any information on how to install Qt built on Windows.
In wiki article How to set up shadow builds on Mac and Linux there's description of -prefix option in configure script but this option is not available on Windows.
I know I can use Qt right from the build folder but it does not seem the right thing not to perform an install step. One problem with this approach is size; Qt's build folder takes about 4GB space whereas after installing using binary installer Qt takes about 1GB space. I guess the difference is due to temporary files created during building. I hope some install procedure would install (copy) only needed files leaving temporary files in the build folder.
As İsmail said there's no install step for Qt on Windows.
However one can try to approximate it by performing the following operations.
Cleaning
Run make clean in the build folder to remove all temporary files.
Moving
Copy build folder to the place where you want Qt "installed". Let's call it INSTALL_DIR.
Fixing paths hardcoded in the qmake.exe executable
Run qmake -query to see what paths are compiled (hardcoded) into qmake and
a. Fix paths containing the build folder by replacing it with the INSTALL_DIR using qmake -set (1).
or
b. Create a qt.conf file in the bin subfolder of the INSTALL_DIR specifing new Qt paths inside it.
Adding current directory to include path
In Qt's provided binary distributions, the pwd is included in the QMAKE_INCDIR and thus ends up in your projects include path as ".". This does not happen by default in a custom built Qt, so you have to add the following line to mkspecs/YOUR-PLATFORM-HERE/qmake.conf file:
QMAKE_INCDIR += "."
Fixing prl files
When you add a Qt component to a project file (such as CONFIG += uitools), Qt looks in %QTDIR%/lib/QtUiTools.prl to find the library dependencies of that component. These files will have the hard coded path of the directory in which Qt was configured and built. You have to replace that build directory with the one to which you moved Qt for all lib/*.prl files.
Making source available
If you made a shadow build (build made inside folder other than the one containg sources), headers in the include subfolder only forward to the original headers. For example; BUILD_DIR\include\QtCore\qabstractanimation.h looks like this
#include "SRC_DIR/src/corelib/animation/qabstractanimation.h"
If you don't want to depend on the existence of the folder containg sources you have to copy SRC_DIR/src subfolder to your destination folder and fix all headers in the include folder so that they forward to the new location of src subfolder.
The bottom line:
The build process of Qt under Windows makes it really akward to move (install) Qt after building. You should do this only if ... well I can't find any good reason to go through all this trouble.
Remember
The easy way is to place Qt's sources in the folder where you want Qt to stay after building and make a build in this folder. This makes all steps but 1 and 4 above unnecessary.
1)
The variables you set with qmake -set are saved in the registry key
HKEY_CURRENT_USER\Software\Trolltech\QMake\<QMAKE_VERSION>.
Because of this you might have a problem when you would like to have different projects using different versions of Qt which happen to have the same version of qmake. In this case the better solution is to use qt.conf file (actually files as you need one file for each Qt installation) (option 3b).
Many of the information above come from the RelocationTricks wiki page authored by Gabe Rudy. Check out his Qt (Qt4) Opensource Windows Installers of Pre-built Binaries with MSVC 2008 project which gives you easy solution of above problems.
This answer is a replacement for steps 3 and 5 of Piotr's (currently top rated) answer above, but you may still need the other steps in his answer, depending what you're trying to achieve.
This is the operation which the official installer uses to fix the hardcoded paths during the installation: qt.520.win32_msvc2012.addons/meta/installscript.qs
This is how the operation is implemented: qtpatchoperation.cpp
This is the list of files that it fixes: files-to-patch-windows-qt5
And this shows how to invoke an installer operation as a standalone command from the commandline: Operations (Qt Installer Framework Manual)
To summarize: after moving your Qt directory to where you want it, download any one of the official Qt installers and run it with the following commandline arguments:
cd <path>
installer.exe --runoperation QtPatch windows <path> qt5
Replace <path> with the full path of your Qt directory after you moved it (the qtbase directory if you are using Qt 5). Omit the final qt5 argument if you are using Qt 4.
This will fix the hardcoded paths in qmake.exe, .prl files, and others. It gives you the exact same behaviour that the official installers have in that respect.
For the initial move, nmake "INSTALL_ROOT=\somewhere" install works for me. So that's steps 1 and 2 of Piotr's answer covered. And I haven't needed steps 4 or 6, FWIW.
I can configure QT 5 on WINDOWS (Visual Studio build) with the prefix option like:
configure -prefix C:\the\path\I\want ...
then call:
nmake
nmake install
and the latter will install Qt in C:\the\path\I\want.
I did it without problems with Qt 5.2.1 and 5.3.x, so far. So, any earlier problems seem to be fixed by now.
It's very odd people claim that there is no "make install" on Windows.
I have used it many times, and I agree that it's not what it is on other platforms, but it serves its purpose.
How I use Qt's make install on Windows (from cmd):
configure
(n/mingw32-)make
(n/mingw32-)make docs
(n/mingw32-)make install
The make install bit copies all necessary headers to be able to delete your source directory. Delete all objects and unecessary stuff:
del /S /Q *.obj lib\*.dll
rmdir /S /Q docs-build qmake tools src
This allows you to remove the source directory. I don't know what impact this has on debugging Qt source code, but it sure reduces the size of a shadow build. I use it to maintain 32 and 64 bit builds with minimal size.
Qt on Windows is not installable with make install, you will notice that Qt installer for Windows just patches dlls & pdbs for the new install location.
What I would suggest is to do a shadow build in the place you would like to install it. You can manually remove *.obj files to save up space.
Qt's own build instructions show how this is done, by search/replace within each Makefile. Assuming the source was extracted to C:\qt-4.8.3 and build was performed within that directory, then do this:
fart -c -i -r Makefile* $(INSTALL_ROOT)\qt-4.8.3 $(INSTALL_ROOT)\my-install-dir
set INSTALL_ROOT=
mingw32-make install
Then create a config file that tells qmake about its new installation path. Create a textfile C:\my-install-dir\bin\qt.conf:
[Paths]
Prefix=C:/my-install-dir
Translations = translations
Then as a final step (as Randy kindly pointed out) you need to patch qmake.exe, which can be done using a simple utility called QtMove. This same tool also automatically updates all the prl files.
Step 1: Move Qt
Cut and Paste
Current directory - C:\tools\Qt
Destination directory -C:\sim\dep\Qt
Step 2: Get Old Qt Directory
Go to C:\sim\dep\Qt\2010.02.1\Qt
Open .qmake.cache
Find variable QT_SOURCE_TREE
Note the value of QT_SOURCE_TREE
Mine was C:\tools\Qt\2010.02.1\Qt
Step 3: Patch Qt
Go to C:\sim\dep\Qt\2010.02.1\bin
The syntax is qpatch.exe list oldDir newDir
qpatch.exe files-to-patch-windows C:\tools\Qt\2010.02.1\Qt C:\sim\dep\Qt\2010.02.1\Qt
Step 4: Set Environment Variables
set QTDIR=C:\sim\dep\Qt\2010.02.1\Qt
set QMAKESPEC=C:\sim\dep\Qt\2010.02.1\Qt\mkspecs\win32-g++
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\Qt\bin
set PATH=%path%;C:\sim\dep\Qt\2010.02.1\bin
You can do all of this with a batch file. This took me a fair while to work out and it has saved me a lot of time since. It's a script to automatically update a Qt installation to new locations. The batch file is available here.
There is a simple utility QtMove (http://www.runfastsoft.com) can do this easily.
Runs the relocated qmake.exe build your .pro file and everything should be linked with new Qt libs.