I created a setup file which is working awesome.
Now whenever I rebuild an application without changing anything but Package Code is changed and then while I am going to install this version then a dialog will come "Upgrade Dialog" which ask me for upgrade an application.
Now in this situation I want to display an additional dialog created by me.
I am using the Insatllshield 2012 BASIC MSI project type.
I solved this problem.
There are two properties exist in Installshield named "IS_MINOR_UPGRADE" and "IS_MAJOR_UPGRADE".
When there is a minor upgrade at that time IS_MINOR_UPGRADE will set to 1. And same for Major upgrade.
So using these properties, I can recognize the Upgrade mode.
Any time you change the package code but not the product code you are talking about a Minor Upgrade or possibly a Small Update if you don't change the ProductVersion. Either way, the only way to create a custom message like you ask is to write your own setup.exe / update.exe bootstrapper to detect the update scenario and display your confirmation UI.
There's nothing built into MSI or IS that allows you to easily change this.
Related
I would like to check programmatically if a new Windows "feature update" - that is a new major version like 1904, 20H2 - is available. It seems WUAPI doesn't return these updates, but I might be making a mistake.
I think it is possible to install these unattendedly by downloading the Windows 10 Update Assistant and calling it with some poorly documented flags, or by unpacking an .iso and calling setup.exe. But what I'd really like to have is the interface that the Windows settings app uses. I'd like to basically click on "Search for Updates" programmatically, see if a feature update is offered, and possibly install that.
It is not an solution to just unconditionally run setup.exe (I already know how to do that). Neither is "switching to WSUS", because the computer in question may or may not be managed by WSUS. I'd like to show the update if and when it is offered, no matter wheter it comes from Microsoft's servers or WSUS. Is there any way to do that (short up screen-scraping the settings app? :-D).
Have you seen Boxstarter.org ?
Automation of windows installs.
But there is also an Install-WindowsUpdate function.
Finds, downloads and installs all Windows Updates. By default, only critical updates will be searched. However the command takes a -Criteria argument allowing one to pass a custom Windows Update query.
Help Install-WindowsUpdate -Full
See https://boxstarter.org/WinConfig
This should give you any hidden updates:
Install-WindowsUpdate -criteria "IsHidden=1 and IsInstalled=0 and Type='Software' and BrowseOnly=1"
output:
++ Boxstarter starting Checking for updates...
Restarting windows update service
++ Boxstarter finished Checking for updates... 00:00:29.5201057
There is no update applicable to this machine
I am using InstallShield X - professional Edition, version 10.0
I have created .exe file through installshield Basic MSI project and installsed it. During installation it extract the .msi file at location: C:\Windows\Downloaded Installations{FF12DD....}*.msi
After that I have created another product with updated version and install it over the older product. The latest ptoduct got installed successfully. After updating when I am trying to uninstall it, The updated product is using the older build .msi file. What I want here is it should use the latest build .msi file. Because I have made some changes in installScript of latest product which should get execute during un-installation.
In the updated product I am just updating product version number and not Product code. I don't want to modify the product code.
Thanks,
Sameer K
You need to read up on major upgrades and perhaps on some of the basics of Windows Installer. Essentially I think you should try to implement a major upgrade, it does involve changing the product code.
Don't be afraid to change the product code. It is the upgrade code that identify related versions of a product. The product code changes between versions. Essentially you author the upgrade table to detect other versions of your product, you update the version number of the MSI(first three digits count), and the package code should always change for every rebuild of the MSI. Finally you must keep the upgrade code the same across releases to make major updates easy to implement.
Installshield shields a lot of the complexity of this if you author the information found in the Upgrades view. Read the information provided here and you should be able to proceed.
Some further information on these important codes in an MSI. You must understand this even if you use Installshield's simplified GUI:
In every single rebuild of the MSI you MUST change the package code. This code should never have been exposed in the whole MSI design - it is used to uniquely identify a file. If you keep this guid the same across multiple files each file will be treated as the same file by definition - even if they are different files. This may cause the most mysterious problems you ever come across with MSI. Using the same package code several times is wrong in every case - unless you want to do hacking :-).
Package code: identifies unique MSI file
Product code: identifies product version
Upgrade code: identifies product family
I see it all of the time when installing updates to retail applications, but after searching for two days, I have not found a way to do it. I am trying to create a package with InstallShield LE in VS 2012. One of my customer requests is to warn the user when the program being updated is running, and allow them to close the app (or possibly have the install try to close it). Is there any way to do this (the simpler the better)? Thanks in advance for your help!
This should just happen. However you may need to make sure that you didn't remove the file and re-add it to your installation; instead make sure you update it at the source location and rebuild. (This helps ensure that the underlying component settings remain the same, which may be relevant to Windows Installer's Files-In-Use detection.)
I am working SDL TRIDION 2011 SP1 version. Suddenly I am unable to see the Trdion site in Internet Information Services(IIS) Manager. Please tell me the procedure how to get it back again.
Remove Tridion Completely (uninstall), then run the installer again.
You won't loose any data (it's all in the database), and you're likely to get your server up and running way faster than trying to fix by hand.
As #bart suggested, your best option to get the web application back (assuming it really has gone), is to run the repair option with the installer. There are a lot of folder specific settings which would be very hard to recreate manually.
The following issue just crept up on me. The steps mentioned below had worked just fine until about 2 days ago.
When I deploy a update to a solution (of web parts) to a SharePoint 2010 server I don't see the update. The solution does get installed, but from what I can tell the installed web parts are over a month old (nothing new is installed).
I do the following steps through PowerShell:
retract the solution from the web app
remove the solution
add the solution
install the solution to the web app
I have tried restarting the Web App, restarting IIS and also restarting the server. Nothing seems to work.
I notice that after I remove the solution it does get removed from the GAC. After I add/install it the solution does reappears in the GAC.
Am I missing something? Am I overlooking a step that I should be doing? Something to try?
I never deactivated/reactivated the Feature.
After following the same steps I mentioned in my question I just deactivated, then reactivated, the Feature and everything started to working fine.
This is an easy thing to I can start to implement with my solution updates. However, why did I never have to do this step before?
In general, you should check your ULS log to see which version of your solution is running. If you see the old one, then you can be sure that your activated site feature is still bound to the old version. In this case you have to Inactivate the site feature indeed to loose that tie and then Activate to bind to the new one (it appears Activate always ties the site feature to the newest version of the solution).
Maybe you had not to do this earlier, because you did not change the version number of your solution, appearing as the same version in GAC on the server. In this case you had your site feature already pointing to the correct version of your solution, therefore didn't have to reset the feature.
You have probably checked, but just in case. Make sure that the powershell script is not adding a month old package.
Is the problem in the web part code or the configuration? The configuration usually unghosts itself sooner or later and refuses to update from the solution - you can update the file in the gallery manually if anything has changed there. For most updates there won't be any changes because existing web parts won't get updates applied anyway - they will use new code but old configuration.
If the problem is the code itself, does the assembly appear to the system to be unchanged? All the hardcoded full name references in SharePoint config files mean that usually you are deploying a new assembly but with the same version numbers. This can mean that the system doesn't bother making the update. I have found it very useful to update AssemblyFileVersion (which does not affect binding) on every build and have a page in _layouts that displays the file versions of all the loaded assemblies so I know exactly what is running.