apologies in advance, I am still an Installshield newbie!
I am currently using installsheild 2010 for an isntall packed for my application (ds2). My trouble is I need to remove a previous incarnation of that project which was created with an installshield 2008 as a merge module (ds1), not a installer in its own right.
So the old version (ds1) is currently lacking in upgrade code etc, and only has access to a Product Version and Package code.
The new program has the usuall Upgrade, package, product codes (ds2).
Is there anyway to either associate the old product mergeModule to the new application so it can be uninstalled as a 'previous version'. Or is there another method where i can ask installshield to "remove anything with product code xxxxxxxx"
I hope that's clear enough for a response!
Thanks in advance
UpgradeCode is only needed for FindRelatedProducts to determine the ProductCode. RemoveExistingProducts uses that ProductCode to do the removal.
You can author a Major Upgrde based on a fake UpgradeCode knowing that it won't find anything. Then you can use a Type 51 Set Property custom action to assign the known ProductCode to the ActionProperty used by the Major Upgrade rule. Then RemoveExistingProducts will come by and uninstall that product.
Related
Can you reassign the namespace in a developer org to another package?
I currently have a manage package and in that package I've assigned my namespace. I created a Beta version for now.
Ultimately I want to keep using the namespace but use an up to date code.
Warning. It only works if you have a beta package. If you release the package then you will not be able to
Turns out that you can't find any information online about this but You can!
My beta package needed to be deprecated and I manage to delete the package entirely from the dev org. - Keep in mind that when you delete the package it doesn't remove the objects and components from that org so you will have to go back into the org and manually delete everything. This is probably the only hassle.
I then created a new package. reassigned the namespace to this new package and created a release version from there.
I've read some reviews that some people say you can but you have to uninstall from all your customers. Deprecate every version and it may work but I can't confirm that.
I'm maintainer of azcopy chocolatey package. https://chocolatey.org/packages/azcopy
Microsoft released version 10 of azcopy (from version 8).
The tool is now a single exe (in a zip file).
The old one was a MSI installer.
The command line is completely different between v8 and v10.
I've got two choices :
Create a new azcopy10 package for this package and have both living and at some point deprecate the old one
Simply "upgrade" the azcopy package to v10 as I don't expect MS to upgrade v8 anymore. If people are willing to keep v8 they still can avoid upgrade (I was going this way)
In case I just upgrade the azcopy, how do I manage the upgrade ?
If v8 is installed, do I uninstall it ? Is it allowed to uninstall a package in the chocolateyInstall.ps1 of a new version ?
Do I just manage the actual installation of v10 and let v8 if already install?
So, here are my thoughts on this...
Are these tools intended to be used side by side? You say that there are differences in how the command line functions, so it sounds like maybe that is the case. If you can use them side by side, then that in my opinion would be a case for a new, standalone package, named azcopy10.
That leaves the question on what to do with the existing azcopy package though. Should this be changed to be azcopy8? If so, should the existing azcopy package become a meta package, that points to either azcopy8 or azcopy10? That would certainly fit with how some other packages out there work.
However, this leads us back to the question of what to do if azcopy is already installed...
If they "can" work side by side, then simply blowing away the existing installation probably isn't a good idea, as some people might want to have both installed. As a result, a package parameter might be required to handle the uninstall if someone specifically chooses to uninstall it.
Long story short... There are lots of choices here, and there is unlikely to be one "correct" answer, as you will never please everyone. Likely, this doesn't help you though :(
I am trying to script the uninstallation of some MS Office programs, and I'm wondering if anyone can help me figure out how to find the ProductID code I will need to add to the xml file? I know that for Standard it is "standard" and for ProPlus it is "ProPlusR", but I also need to uninstall Home Business 2013 (might be Small Business 2013?), and I can't figure out what the ProductID needs to be. I have queried an installed version of it with powershell, but the "ProductID" property is always blank, so that doesn't help either.
So far, I have tried the following without success: HomeBus, HomeBusR, SmBus, SmBusR, Business, HomeBusiness, SmallBusiness, HomeBusinessRetail, SmallBusinessRetail.
The answer I would prefer, is how I can find this info myself, as I will likely have additional versions I need to script, but I appreciate whatever help anyone can provide.
Thanks,
Andrew
The uninstall command line of an installed application is recorded in Windows registry under the keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall
The second key exists only on 64-bit Windows and is for 32-bit applications the same key as the first one, see Registry Keys Affected by WOW64.
The applications (products) installed with Microsoft Installer (MSI) are registered with their unique identifiers under registry key :
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products
In creating a package with Data Types and Items, what are the best practices to follow for subsequently upgrading a package in order to retain the data that's created on the site while adding a change to the associated Type?
Should the package name remain the same or should it include version information to retain uniqueness by version? The version number of the package does not seem to enforce any type of upgrade policies.
Currently during development the package is uninstalled then the newer package is subsequently installed however after the package reaches production I believe this type of upgrade workflow will not be sufficient without affecting the associated data.
As long as you increase the package-version but keep its unique GUID and Name, you're able to install the same package again, forcing C1 to overwrite the existing files, configuration etc.
This has a few caveats though, mainly if you need to delete some old files or configuration entries during installation, since that's what you normally do during un-installation. But you can still do it, writing your own installaton-steps code.
It is classes inheriting from some core base package-classes that you can invoke during installation. It can contain logic like checking if certain other packages are installed, do custom special logic, or clean up from earlier upgrades.
But yeah, long story short, as long as the version number increases you can "upgrade" a package, by installing the newer version, while the older one is still installed.
Since I've not done this before I am not sure if the way I am planning to do this is okay or is there a better way. Like using Windows Installer or Install Shield or Windows Installer XML (WiX) toolset. Any help would be great, as I have no clue.
We have a product and we ship new version every few months. So far we've only been rolling out complete versions i.e. Either Version 1.0, or Version 1.5, but no upgrade from 1.0 to 1.2 to 1.3 to .... you get the picture, right! So any customer that get version 1.0 cannot upgrade to version 1.2 or 1.3 or even the latest. They'll have to uninstall old version and install the latest version. This is not right, but thats what we could do until now. But we'd like to change it.
My plan is to have a install file with (Sql Scripts) for each upgrade path. Check the table in database that stores the version info and depending on it run different script to upgrade database.
My concern is that this method may not be scalable, once we have more than 5 or 6 different versions.
If you could point to any articles or books on this topic, that would help a lot too.
Also, could we use Windows Installer or Install Shield for this?
thanks,
_UB
We've been using DBGhost for a year or so now to keep our database under source control along with our codebase, and it makes this kind of thing dead easy. It's not just well thought through, but they've been using it to roll out their own code for years, so it's dead solid.
Your problem is a pretty common one, and I've had to deal with this kind of problem at my last job. There is another tool aside from the RedGate tool that may help you do what you need to do. It's a tool called DB Ghost. They explicitly address the versioning problem, and have a packager as well. I would suggest doing a trial of the DB Ghost product because they have some interesting claims concerning multiple version upgrades. This was taken from their FAQ (http://www.innovartis.co.uk/faqs/faqs.aspx):
Q: Our problem is going to be managing
data structure changes during
upgrades. Our product line is
Shrink-Wrapped, or downloadable from
the website. So when a user downloads
an upgrade, they can be upgrading from
a very recent version, with few
database structure changes, or the
upgrade may be from a very old version
with a multitude of structural
changes. One upgrade needs to manage
it all. The user would be offsite, so
we can't hold their hand. We have
users in Greece, Australia, Malaysia,
Norway, etc. How would DB Ghost, if at
all, handle updates in remote
locations?
A: The DB Ghost Packager Plus product was
design to specifically address this
issue as it can dynamically handle the
required updates to a target database
seamlessly.
I'm just mentioning this because our company is trying to do something similar and I was doing research on this tool.
Thanks,
Eric
Do you insist on doing it yourself, or could you see yourself committing and investing in a tool?
I really like the idea of Red-Gate's SQL Packager, which will "diff" your two database versions, and then create a SQL script, a C# project, or a stand-alone executable to upgrade from version 1 to version 2.
Not 100% how you'd be able to upgrade from 1.0, 1.1, 1.2, 1.3 all to 2.0 - check out their website and see if they offer something for that scenario!
Otherwise, I guess it'll get quite thorny and messy......
Marc
In the Rails world they are using a tool/method called Migrations.
Basically is boils down to creating a small sql script to upgrade and downgrade each little change to the database.
When you are testing the application you migrate your database to the version you want and on deployment the application can check what version it needs and migrate to that version.
There are free migration toolkits for most popular languages, they might be part of some MVC framework though.
A nice side effect of migrations is that you have database source code that is easily stored in you source control repository.