I'm trying to build a Visual Studio Installer Setup Project that deploys multiple C# projects and some other files. Included in these other files, there are Access Database with forms that needs updates.
To illustrate the problem, I simplified it :
1- Create a new Access Database file, add a simple form to it with a button and a label and save it.
2- Add the file to the setup project;
3- Set DetectNewerInstalledVersion and RemovePreviousVersion to true
4- Build the project.
5- Run the setup executable.
To that point, everything has worked fine
6- Reopen the Access Database file, add a button or a label to the form, save it.
7- Change the Version number of the Setup project, and at the same time the ProductCode as suggested by VS2015.
8- Rebuild the setup project.
9- Reinstall the software.
Expected: the Access data should have been updated with the new button/label.
What is happening: The file hasn't been updated.
Why is that ? I've seen people talking about the Assembly version number of projects included in a setup project, but that's not my case since I'm not deploying the ouput of a project. I'm simply deploying a file that should have been removed during the uninstall process.
If I do the exact same steps as described before but with a text file in which I add text, it works fine, but for some reason in does not work with an Access Database.
What's wrong ?
If you install a data file, and then run a program that updates it you've added user data to that file, or database. The file overwrite rules don't allow a modified data file to be replaced in the kind of update that VS setups do:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370531(v=vs.85).aspx
Basically it would be a bad idea to ship a product that installs a database that the user updates with potentially large amounts of data, only to have the new version of the product delete the entire database. It's not clear to me how your app deals with updates (do you want that added button/label just to be completely lost, or do you save them in some way?) so recommending a solution is difficult, but maybe you need an uninstall custom action to delete the database, or on an upgrade you add the updates to the existing DB instead of removing it and starting again.
I found a solution. The file wasn't updating because the modified date had changed.
From MSFT site:
Nonversioned Files are User Data—If the Modified date is later than
the Create date for the file on the computer, do not install the file
because user customizations would be deleted. If the Modified and
Create dates are the same, install the file. If the Create date is
later than the Modified date, the file is considered unmodified,
install the file.
Since I had two Access databases (front-end with the forms, backend with the data tables) and needed only one to be updated (the frontend where the forms are), here's the workaround:
1) Change REINSTALLMODE property to amus instead of the default omus. It will force the reinstallation of all files. To do that, I used a PostBuildEvent as explained here.
2) Set the backend file property Permanent to true
3) Add a Launch Condition: Search Target Machineto check if the backend file exists on the computer. Name it something like BACKENDEXISTS
4) Add a Condition value to the backend file in the File System view to install the file only if it hasn't been found by the Launch Condition. In this case, it will be not BACKENDEXISTS. If this is a first install, it will install the file because it hasn't been found. If this is an update, it will find the file because of the Permanent property and will not replace it.
Related
We are working on Joomla3.9 project, have different environments and are using git as vcs. So every developer works on is own branch. It would be nice to have a database compare function like in TYPO3 or Contao (see the database differences after updating the project and apply the database changes just by one click). Or like the laravel migration system.
Any developer should easily update his own lokal database after database changes where made due an extension update via backend or by another developer. And of course the staging or live system must be updated easily too. We don't want to execute sql-scripts with the changes in phpMyAdmin.
We have tried https://dbv.vizuina.com/ . This is not the 100% solution. Like there is no cli support to start the migration process by an update script on the server.
Does anyone have a solution or knows an extension that can solve this problem? Or can this be handled with core Joomla functions (maybe with a little adjustment)?
So far, I've seen three possibilities to execute modifications to one ore many extension tables
1: Use the extension - revision control in the schema table. So add a new sql-file with an increased version number compared to the version number in the schema-table for this extension. Increase also the version in the manifest.xml and zip the extension again.
Reinstall the extension via extension->manage->install. So the new sql-file with the increased version number will be executed.
2: like the point above, but install the extension via joomla update mechanism (update server).
3.: create a new sql-file in sql/folder of the extension. No version name is needed for the new file, just update.sql oder another filename. Execute this script in script.php in update()-method, after the extension is installed (in this case it's an update) again.
The third possibility might be interesting. It should be possible to trigger the update()-method with a cli command / function, so that the method can be triggered via a script on the server.
But how can I get the info, which update-scripts have already been executed? Let's say I have 3 update files in sql-folder. update-1.sql, update-2.sql and update-3.sql.
update-1.sql has already been executed. So I don't want to execute this sql-file again - only the other two.
The schema-table is only used with the first two options. Do I have the info somewhere or must I manage the infos which update-scripts have been executed myself?
The answer related to versioning database for extensions depends on whether these extensions are tightly coupled to the application or need to be reusable to other applications also.
The latter case normally means that each extension accesses its own custom tables, in which case you should keep separate versioning for the database than for the extensions.
App version history can be kept in a db_version table. Then an insert statement is added at the end of each update script (adding an incremental version number). e.g.
insert into db_version(version,author,description) values(003,'Verna.Collins', 'removing obsolete column');
Provided that you need to apply data migration on extensions also, you need to maintain a db_version_extensions table which keeps version history for each of the extensions separately. e.g.
'001' 'extension1','Mandy.Aguilar','initial version'
'002' 'extension1','Mandy.Aguilar','adding extra column'
'001' 'extension2','Edna.Potter','initial version'
'002' 'extension2','Elvira.Townsend','dropping unused table'
..etc
Each extension zip should keep initial creation script and all sql-update files(which should normally not interfere with the rest of the app tables).
After pull it will be relatively easy to execute all the scripts with filename version greater than the last version number written in the database. This should be done for the app and for each extension separately.
Now if the extensions are tightly coupled to the app, it means that they might be using/updating tables of the app. For extensions of this type, you can add the updates as part of the application updates. These extensions could even be developed at the same repo, and be kept as directories instead of zip files.
Not sure if joomla supports any tools for automating the process of performing incremental db updates, but a nice tool is flyway, with ports for command-line, maven and graddle. See: how does flyway work
I'm installing a TYPO3 installation from a website that already uses TYPO3.
These are the steps I already have done:
I installed a blank TYPO3 installation.
I copied the contentapi and contentelements from the existing server to the typo3conf/ext folder on my server
I imported the data from the mysql TYPO3 server of the existing database
When I log in to the TYPO3 webpage, I have no templates configured and have a few issues. I tried to fix them by searching on internet but didn't find something clear.
On the pages tab I only can see this:
in the log files:
The error is sending me to this page:
https://wiki.typo3.org/Exception/CMS/1294587217
I already did that, but didn't help, or I did it wrong
On my templates tab there are "no templates":
If someone can guide me to a next step, that would be very helpful.. thanks!
root template:
plugin.tx_ahcontentapi.settings.auth.user = bm
plugin.tx_ahcontentapi.settings.auth.password = sdfsdfdsf
plugin.tx_ahcontentapi.settings.url = https://sdfsdfdfs.com
plugin.tx_ahcontentapi.settings.https = 1
tree-view:
Web server root folder:
(laravel application is the green selected folder, with views,language files,..)
did you have all Extensions installed?
typeNum=0 not configured means you do not have created a PAGE Object within your TypoScript.
If you copy Data to a new TYPO3 installation, you need to install all Extension that are used in the source-installation. When the extensions are installed, they have to appear in the Template Module.
The INVALID VALUE gridelements_pi1 is the same - it seems you didn't have installed Gridelements to the new TYPO3 Installation.
Install all dependencies and everything should work like expected.
EDIT:
Going a bit deeper - when installed all Extensions, then click on your rootpage (the globe) and then open the templates module. When there is still the No Templates, you need to create one... message, then create a new template for a new page.
After you created it, you can open the tab Includes and select your templates there.
An TYPO3 installation consists of multiple parts:
the TYPO3 source (this can be updated individually)
/typo3_src (normaly a symlink to the TYPO3 sources)
the database (some tables could be truncated (caches))
extensions (all active extensions are needed)
/typo3conf/ext/*
language files
`/typo3conf/l10n'
original data files (in case you want to have images or other data, e.g. pdf)
/fileadmin/ or any other folders you may use with a file-storage record
processed files (images mostly are used resized, which are precaculated and stored for faster access)
/typo3temp/assets, /typo3temp/DATA, /uploads, /fileadmin/__processed__, ...
cached data (some codes are concatenated, so only one file needs to be included instead of a lot of small files)
/typo3temp/var, /typo3temp/CACHE
Not all parts are necessary for a copy of the installation, but it will help if you can copy all parts.
All caches can be rebuild and so there might be some differences like another domain it is highly recommended to delete caches.
Most processed data can be rebuild (as long as the original files are still present). But sometimes it is not recognized that a file needs to be processed again.
In your case I assume you missed to copy the extensions, especially the site extension so that you also miss the definition of your page object.
I have a Visual Studio 2010 Setup Project and I am trying to create an Upgrade to a new version of my software.
The upgrade process is running. I properly updated the Version Number, which caused an update of the Product Code. RemovePreviousVersions is also True.
My problem is that when I upgrade my software, there is one file that may have changed on the local filesystem, in the course of running the software. I'm finding that, because the file changed, the installer refuses to overwrite it.
I want my installer to force this file to be overwritten with the new version.
Is there something I can do -- within Visual Studio, with Orca, or otherwise -- to force a file to be overwritten even if it has changed?
UPDATE: In Orca, I noticed that the "File" table includes a "FileSize" column. I believe this might be the reason the file is being ignored. If the size of the file has changed, it doesn't match. Is there any way to override this?
You can't safely change the Windows Installer replace rules, but you are getting into this situation because the upgrade mechanism first installs the upgrade on top of the older product (invoking file replacement rules) then uninstalls the old product, ref counting down and removing the product. It's the "on top" that is the issue. If you move RemoveExistingProducts in the InstallExecuteSequence from just before InstallFinalize to just after InstallInitialize you will get a complete uninstall of the older product then the install of the new upgrade. That may not work if you are expecting to keep data files around.
Otherwise you could use the RemoveFile table with Orca. You'd add an entry targeting the Component name corresponding to the file (look in the File table, and there may already be some entries in the RemoveFile table as examples). You'd set the value to be Remove on Install. The RemoveFiles action occurs before the new files are installed, so it should work.
We ship a config file as a part of our installation that we create via install4j. Suppose the user is doing an upgrade installation when we ship a new version of the product. Is there any way to determine if the user has manually modified the file after last installation ??
We need to detect if the user has modified this file, and then merge the changes that the user has done with the new changes that we are introducing by the update.
Any pointers / ideas would be greatly appreciated.
TIA
As of 5.1.11, install4j does not support this kind of content-based modification detection. Modification detection only takes file modification times into account.
Windows installer compares a file's create and modify dates. If they are different the file has changed.
I believe you can solve this in a better way by writing the config file using the main application executable using "internal defaults" in your application instead of a base config file delivered via your setup. You can then re-apply all internal defaults to the existing file, add any new updates whilst keeping user changes where possible (sometimes you want to override what has been changed?).
The more intelligent an application is in its configuration and maintenance of settings, the less deployment problems you will see.
I have created a Setup and deployment project using the Visual studio and install the setup.
After i install the setup it copies a few files(XML) which on using of the application are configured programmatically .
Now , If the user is reinstalling this setup again i need to ask the user whether these configured files need to be overwritten or be retained ??
Any idea as to how this can be accomplished ?
Thanks & Regards,
Fran
Look into file versioning rules for Windows Installer.
In short, assuming that these XML files you refer to are unversioned text files, MSI will compare the Created and Modified dates and will not replace the updated XML files which you say are updated programmatically (post-install-time).
I would suggest several other variables you need to consider to make sure things are working as you expect: major vs. minor upgrade, and the REINSTALLMODE property.
I find that the best way to approach this kind of scenario is to implement the "preserve changes" logic in your application as opposed to via the setup. This avoids complicating your setup and yields greater control of the config process since all logic is embedded in your main EXE file. This means you can step through the process and debug it the normal "development way".
To achieve this you can install your "base config" files to a read-only location such as
%ProgramFiles%\MyCompany\MyApp\MyConfig*.*
Then your application can detect on launch whether existing config files exist in the user profile (or in a writable shared location), and ask the user whether the new config files should overwrite the existing config or not. You can also easily implement backup functionality for the old config.
In order to ask the question only once per user after deployment, the normal apporach is to flag HKLM with the latest installed version of the application and then write a corresponding flag in HKCU when the copy operation has completed or the user dismissed it:
HKLM\Software\MyCompany\MyApp\Version = 2.0.0
HKCU\Software\MyCompany\MyApp\Version = 1.0.0
In the above scenario version 2.0.0 of the application has been installed, but the per user config copy has not run for the user in question yet. Once it has run the HKCU version will be set to 2.0.0 and the operation is not run again until HKLM is incremented.