I have a basic MSI project in installsheild 2012. I want to be able to install a patch (major upgrade) which backs up the current configuration files when it is installed in way so that when I remove the patch that the old configuration files are re-instated. At the moment when I update these files are deleted.
I am self taught so I may not be following the best practises
I have looked everywhere but I cannot find an example, I might not be looking for the correct words that relate to this process
Thanks in advance
This can be handled manually by copying the installed file to location, and once you do the upgrade copy back the file to the INSTALLDIR. I got to know from the below link, hope that helps you.
http://community.flexerasoftware.com/archive/index.php?t-108435.html
-Anand
Related
Not too long ago I got a new job working on a tool that the company created to make people's lives easier when working on AWR.
I have successfully done multiple fixes and improvements which I was able to distribute via HotFix installers (simply overwrite the files that are already there).
My latest change/addition to the tool requires I create a complete installer for the tool. This particular tool always installs 2 versions, the current/new and the previous/old, to give a smoother transition to users. I have never done an installer before so I am learning as I go.
I was able to create an installer using the previous installshield project by simply updating/adding/removing files and folders. This works great when there is no version of the tool installed on the computer and there are no files/folders of any version of it on the installation locations.
I looked online and found that to make an installer that will install over a previous version I would need to do a major upgrade with installshield, which I did do after reading that. Now the installer successfully installs over the old version, it successfully places the new files and folders on their locations but always leaves one particular empty folder behind, the one for the 1.1.1 version.
That didn't seem like a problem until I realized that the .exe failed to modify the .ini file that it needs to modify to let AWR know where to look for the scripts. I looked through the .exe code and after running some tests, running it alone, I realized the .exe is not the problem, it does the job correctly. After doing many tests I found that as long as those empty folders exist the .ini files cannot be modified. I have no clue why since the .ini file is pretty much a .txt file and it makes no sense for there to be some sort of dependency on the 1.1.1 folder.
So my problem is one of two, either I have to figure out a way to make sure that the upgrade deletes those 1.1.1 folders or find a way to modify the .ini files with those folders still there. I have looked online and every solution requires me/the user to manually do something and I am being asked to make the installer simply work when used. They are asking me to make it so the installer takes care of everything and the user should not do anything except run the installer.
Since the installer works correctly as long as those folders are not there I figured making sure the installer removes them is the best way but I am stuck and I do not know how to proceed.
Thank you for any advice and help you can provide with this issue.
Solution:
Deleted all files I needed to make sure were updated from the components list and re-added them to the installshield project.
Since doing that everything was updated correctly and the folders were removed since the .exe was the correct one.
Ive made a terrible mistake and decided to make the publish folder for a VS Solution the folder of the source files.
Selecting the delete previous files prior I have removed majority of the source I was working on.
It was a small project to do a database integrity cleanse after there was a major bug found through my companies software so there is no Source Control or anything set up and had been a couple days work.
Wondering if IIS express stores a cache of these files anywhere in case I am able to restore the binaries and some other files from a previous build straight back into my source.
Banging my head.
Any help would be much appreciated!
Thanks,
I have a question concerning software updates. Currently I install new releases into a different folder each time. The user is then required to re-enter configuration parameters. This of course is not too optimal. The software is Windows forms and I use the settings. Settings file.
So the question is what happens if I install a newer version into the same folder as a previous install? Will files just get replaced? What about if I have added settings in the new version? Will they be merged?
Anything to watch out for?
Thanks
When the MSIs are related, typically you can only have one instance of it installed at a time. If that's the case, first the earlier version may be uninstalled, so the question is whether the files that store the settings are removed by uninstalling your MSI.
If the MSIs are not related, you can get into a world of pain by overlapping their installations (probably breaking component rules by having two different components describe the same file in the same location, but with a different component code), yet the core question comes down to the same thing: will the updated installation lay down the file that stores the settings.
These are likely the same question, as the easiest way to remove or install a file is by including it in the MSI directly. (There are other ways, but I'm assuming you're not using those yet.) If the file is not part of the installation, nothing will happen to it, and the answer to your question comes down to what your application does when it runs with a settings file created in a different version. If the file is part of the installation, and component rules are not being broken, it will either be uninstalled then freshly installed (wiping any configuration), or per File Versioning Rules and Default File Versioning, the file will either be left untouched or completely replaced with the new version. Windows Installer doesn't know how to merge your settings file.
Thanks for taking the time to answer my question.
So bottom line I should just avoid these issues and install in another folder. I should also make a copy of the settings and put them in my own file which can be used to update my new installation. That would be the safest route I guess.
Thanks
we use SVN in a team work. in the solution there's a project for building MSI file called Setup. the project is indeed a vdproj file.
i've changed Setup.vdproj and found that someone else also changed it and committed the changes before me. so i've to Update, but the SVN itself can't merge them via Update properly (i think so, failure will happen, no?) and i myself can't merge it when it's shown in text mode. there're lots of numbers (GUIDs) there. so i need a visual way to merge my changes with others.
how can i do that?
what's ur idea?
thx
I would at least use the following properties:
svn:eol-style=native
svn:mime-type="application/json; charset=utf-8"
You might also want to require locking:
svn:needs-lock="*"
I'm having issues with my Magento store and I'm feeling like I may need to re-install the website. The first thing I'd like to attempt is simply re-installing the core data that comes from the installation zip file. The files are exactly as they were when I first uploaded them to install (in other words, config files are configured properly). Is this safe to do or have these core files been modified by the installation in such a way that re-uploading and replacing the current core files will break it?
Keep in mind that some developers do modify the core files (inappropriately). Not sure if anyone other than yourself has made changes, but it would be smart to do a diff on the core files against a clean copy to see what differences there are.
If you are re-installing the same version of Magento, then no problem. You can re-upload the core data files until and unless there is no changes done in core files before.
If the Magento version if different then you shouldn't.