I have created a project of type InstallScript Project. It is a multi-instance installer and I can install multiple instances of same application.
At the time of uninstalling of any instance, I am preserving some configuration files. I have set the 'Shared=YES', 'Uninstall=NO' and 'Overwrite=Never' properties for components that I need to preserve. This works fine and at the time of uninstall the files that are marked as 'Uninstall=NO' are preserved and not deleted.
The problem happens when I try to install a new instance. The directory to install a new instance is same as the one having preserved configuration files. But the installation Overwrites those configuration files. The property 'Overwrite=Never' does not seems to have any effect. How can I prevent those files from getting overwritten.
Related
I've done a bit of googling and haven't been able to find any documentation on this, but I need to upgrade my Seeddms (Document Management System) server from 5.1.25 to 6.0.19.
I am running a Linux Lamp 4.19.0-19-amd #1 SMP Debian 4.19.232-1 (2022-03-07) with a Seeddms web server on it.
I tried copying the contents of the .gz download file of the latest version over my current /var/www/html/dms/ folder and it didn't work, I did a similar thing to update my dokuwiki site so I thought I'd give it a try here.
I am still new to Linux so any advice would be greatly appreciated!
I was able to find the solution, in the seeddms-quickstart-x.x.x/seeddmsxxx/seeddms-x.x.x/doc/README.Install.md.
Here is what is says on upgrading versions if anyone has trouble with this as well. Make sure your server meets the requirement as well.
UPGRADING FROM A PREVIOUS VERSION OF SEEDDMS
As SeedDMS is a smooth continuation of LetoDMS there is no difference
in updating from LetoDMS or SeedDMS.
You have basically two choices to update SeedDMS:
you install a fresh version of SeedDMS and copy over your data and configuration
you replace the software in your current installation with a new version
The first option is less interuptive but requires to be able to set up a second
temporary SeedDMS installation, which may not be possible, e.g. because of storage
limitations. It can be the only option if you change servers.
The first update procedure is only needed if the version changes on the minor
or major version number. Changes in the subminor version number will never
include database changes and consequently it is sufficient to use the existing
data directory and database with the new version. Choose the second update
option in this case.
In both cases make sure to have a backup of your data directory, configuration
and database.
Fresh installation and take over of data
The first update option is to set up a new instance of SeedDMS and once
that is running take over the data from your current (old) instance.
just do a fresh installation somewhere on your web server and make sure it
works. It is fine to use
SQLite for it, even if your final installation uses MySQL.
replace the data directory in your new installation with the data directory
from your current installation. Depending on the size of that directory (and
whether the new installation is on a new server or the old server) you
may either copy, move or place a symbolic link. The content of the data directory
will not be changed during the update. Its even perfectly save to
browse through your documents and download them after finishing the
update. The data directory will not be modified until you actually modify
documents.
copy over the configuration settings.xml into your new installation. This will
effectively make your new installation use the data from your old installation,
because all paths are still pointing to the old installation.
if you use mysql you could as well make a copy of the database to make sure
your current database remains unchanged.
modify the settings.xml to fit the environment of the new installation.
This will mostly be the
httpRoot, the paths to the installation directory and possibly the database
connection.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
Upgrading your current installation
Instead of setting up a new installation, you may as well replace the php files
in your current installation with new versions from the quickstart archive.
get the SeedDMS quickstart archive seeddms-quickstart-x.y.z.tar.gz and
unpack it somewhere on your disc.
copy the directory seeddms-x.y.z from the unpacked archive into your
current installation and make the link seeddms point to this new directory.
copy the directory pear from the unpacked archive into your current
installation, replacing the existing directory. Make a backup of pear before
the replacement if you want to ensure to be able to go back to your old version.
you may compare your conf/settings.xml file with the shipped version
conf/settings.xml.template for new parameters. If you don't do it, the next
time you save the configuration the default values will be used.
create a file ENABLE_INSTALL_TOOL in the conf directory and point
your browser at http://hostname/seeddms/install
The install tool will detect the version of your current SeedDMS installation
and run the required database updates.
If you update just within the last version number (e.g. from 5.1.6 to 5.1.9),
this step
will not be required because such a subminor version update will never
contain database updates.
I created some custom modules and Visual Studio drops the build files directly into the Kofax Bin directory. It is important to note that I'm using the modules as Winforms applications and Windows services (at the same time). The generated files are
MyModule.exe
MyModule.exe.config
MyModule.InstallLog
MyModule.InstallState
MyModule.pdb
I think that I only need the .exe file here. Of course I also add the .aex file to the directory to install the module. I also created two batch files to register the module on the local machine
RegAscEx.exe MyModule.aex
pause
and to install the module as a Windows service
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\installutil.exe" "%~dp0MyModule.exe"
pause
after running them as administrator I can delete them from the directory of course. I would like to know if it should be always fine to provide the .exe file, .aex file and the two batch files (which will be deleted later) only?
Basically correct. Some thoughts:
Build your application using the Release configuration (vs Debug). See discussion here.
PDB files usually are not needed in production. Still, you may want to generate and keep them if you plan on debugging in production.
The app.config file should be kept. Maybe you want to use application settings later on, and the supportedRuntime element is useful if someone wants to run your CM on a machine without that version of .NET framework being present (Windows will show a nice error message)
Keep the AEX file. This is required if someone wants to register your CM on another machine (e.g. deploying from DEV > TEST > PROD).
Include a single batch file that allows registering your CM on a new machine as well as adding it to Kofax Capture. Here's an example:
rem "C:\Windows\Microsoft.NET\Framework\v4.0.30319\RegAsm.exe" SmartCAP.CM.Sample.dll /codebase /tlb:SmartCAP.CM.Sample.tlb
rem RegAscSc.exe /f Register.inf
Another thing I usually include is the ability to install my CM in a similar fashion to native KC modules, for example: SmartCAP.CM.Sample.exe -install and SmartCAP.CM.Sample.exe -uninstall. Take a look at the AssemblyInstaller class for details.
I have an application, which is getting installed C:\ProgramFiles\RootFolder\InstallDir.
I have another application which is also getting installed in same root folder , eg:
C:\ProgramFiles\RootFolder\InstallDirofAnotherApp.
Here when I am trying to reinstall my application, it is deleting the entire Root Folder, It doesn't mind about the another installation of the other one.
So, it is deleting C:\ProgramFiles\RootFolder
Is there any setting to do like that? This is a legacy project and I am new to this. Unable to fine the cause
Thanks,
Nanda
What type of projects are these applications (basic MSI, or InstallScript)? Check [INSTALLDIR] (General Information -> INSTALLDIR) in both packages; if these properties are different, see if there is any custom action that perhaps delete some files/directories.
i'm new to installshield and am learning how to use it on the fly, I have an installshiled 2011 project that upon a custom installation when i deselect a component from being installed, it is not installing the files, but the folder for those files is created empty, how can i prevent it from being created?!
Thanks in advance.
I solved this by going to Files and Folders under application data,
looks like some one checked the parent node under custom installation, when i checked only the child node it didn't create any unnecessary folders.
I have a project that uses clickonce to generate the setup.exe. During the run time my program create some extra files like "Log" and "Attachments" inside the User Folder. However, those folders are not removed when I perform an uninstall of the clickonce application from the ARP. These remaining files are interfering the next install.
I know that click once does not support for adding custom action to install or uninstall. I am wondering if is there is a way that I can remove those extra file programmingly after performing uninstall?
One way I have tried was to create a cleanup script and added it as a bootstrapper package to pre-requisite of the click once project. That worked in a way that every time before a new product was installed, the previous dirty data had been removed. However, this messed up the upgrade case.
Any ideas on how to remove the extra files that left by clickonce uninstallation?
Thank you
JS
There is no way to do anything when uninstalling a ClickOnce application other than uninstall the ClickOnce application.
Have you considered putting the files in the ApplicationDeployment.CurrentDeployment.DataDirectory ? Then they will be removed when the application is unisntalled.
If the files are part of the project, you can set the type to Data in the Application Files dialog, and it will automatically place them in the data directory when deploying.
This solution works on multiple re-installations (clean), however it doesn't remove the data on last uninstall or until the next installation takes place.
Stil there is no custom action place on uninstall to remove the files beyond clickonce scope.
Leave a file in to ApplicationDeployment.CurrentDeployment.DataDirectory.
On startup, see if the file exists on conditions network deployed, firstrun (which resets on upgarde too).. success case, it is a first installation or upgrade. Failure case, the application is been uninstalled and installing again .. now you have a chance to clean up the application data.
If the data is sensitive, you may want to use other solution to remove files on uninstall ( as of now I don't see that Microsoft is given us an option)