- UNIFYBroker Forum
-
Ideas
A couple of installation nice to haves
After my recent experience with upgrading Identity Broker there are a couple of nice-to-haves in the installer that would make things easier. In both cases either a warning or a log would be helpful. Admittedly, both problems could be solved by stringent documentation however the scattered nature of documentation on sharepoint and having to find one line mentions in a host of project documentation is a challenge for professional services I believe so some checks and balances in the installer itself would alleviate the problem.
1. A notification that there are non-standard assembly redirects in the unify.service.connect.exe.config and which ones are non standard. (The only way to know now is through trial-and-error or rely on documentation.)
2. A notification of all .dlls that are found that are patches from previous installs. (the only way to find now is to uninstall rendering in place upgrade risky or relying on documentation.) This one is relevant to both UNIFYBroker and UNIFYNow.
Answer
Hi Dan,
The ideal scenario is that solution documentation is up-to-date and available, so any extra changes (binding redirects or patches) are outlined, and their usage documented.
In the scenario where this is not the case, there are a few ways that you can manually validate.
For idea 1 (binding assembly redirects), you can compare a fresh .exe.config for the same version, and see if there are any changes. This would give you some clues as to whether any redirects are required.
For idea 2 (patches), you can view a base UNIFY install directory to determine what normally ships in the directory. This will give you an insight into any service patches that have been added. Web patches are reliant on documentation, as the service isn't aware what has shipped with the core service vs what is a patch.
It would require a significant amount of work to make the installer contextually aware of any non-standard binding redirects or patches, especially between version updates. It is recommended that the documentation is up to date and stored correctly to ensure upgrades can go smoothly.
Part of the problem is not having access to a fresh .exe.config and UNIFY install directory.
Customer support service by UserEcho
Hi Dan,
The ideal scenario is that solution documentation is up-to-date and available, so any extra changes (binding redirects or patches) are outlined, and their usage documented.
In the scenario where this is not the case, there are a few ways that you can manually validate.
For idea 1 (binding assembly redirects), you can compare a fresh .exe.config for the same version, and see if there are any changes. This would give you some clues as to whether any redirects are required.
For idea 2 (patches), you can view a base UNIFY install directory to determine what normally ships in the directory. This will give you an insight into any service patches that have been added. Web patches are reliant on documentation, as the service isn't aware what has shipped with the core service vs what is a patch.
It would require a significant amount of work to make the installer contextually aware of any non-standard binding redirects or patches, especially between version updates. It is recommended that the documentation is up to date and stored correctly to ensure upgrades can go smoothly.