I am trying out Microsoft Active Directory Federation Services (ADFS), chasing the dream of single sign-on between on-premise Active Directory and the cloud.
Oddly, although ADFS has been around for a while, it feels more bleeding edge than it should. ADFS is critical to Microsoft’s cloud platform play, and it needs to build this stuff right into Windows Server and .NET rather than making it a downloadable add-on.
The big problem with installers, whether on Windows or elsewhere, is dependencies and versions. You get some variant of DLL Hell, when A requires the latest version of B, and C requires an old version of B, and you need both A and C installed. The issue on Windows has reduced over the years, partly because of more side-by-side installations where multiple versions co-exist, and partly because Microsoft has invested huge effort into its installers.
There are still issues though, and I ran into a few of them when trying ADFS. I have Visual Studio 2010 installed on Windows 7 64-bit, and it is up-to-date with Service Pack 1, released in April. However, after installing the Windows Identity Foundation (WIF) runtime and SDK, I got this error when attempting to start Visual Studio:
Only some of the Microsoft Visual Studio 2010 products on this computer have been upgraded to Service Pack 1. None will work correctly until all have been upgraded.
I’m guessing that the WIF components have not been updated to take account of SP1 and broke something. Never mind, I found my Visual Studio SP1 .ISO (I avoid the web installs where possible), ran setup, and choose to reapply the service pack. It trundled along until it decided that it needed to run or query the Silverlight 4 SDK setup:
A dialog asked for silverlight_sdk.msi. I wasted some time over this. Why is the installer looking for silverlight_sdk.msi in a location that does not exist? I’d guess because the Silverlight SDK installer is wrapped as an executable that unpacked the MSI there, ran it and then deleted it. Indeed, I discovered that both the Silverlight 4 SDK and the Silverlight 4 Tools for Visual Studio are .EXE files that wrap zip archives. You can rename them with a .zip or .7z extension and extract them with the open source 7 Zip, but not for some reason with the ZIP extractor built into Windows. Then you can get hold of silverlight_sdk.msi.
I did this, but then discovered that silverlight_sdk.msi is also on the Visual Studio SP1 ISO. All I needed to do was to point the installer there, though it is odd that it cannot find the file of its own accord.
It also seems to me that this scenario should not occur. If the MSI for installation A might be needed later by installation B, it should not be put into a temporary location and then deleted.
The SPI repair continued, and I got a reprise of the same issue but with the Visual C++ runtimes. The following dialog appeared twice for x86, and twice for x64:
These files are also on the SP1 .ISO, so I pointed the installer there once again and setup continued.
Unfortunately something else was wrong. After a lengthy install, the SP1 installer started rollback without so much as a warning dialog, and then exited declaring that a fatal error had occurred. I looked at the logs
I rebooted, tried again, same result.
I was about to trawl the forums, but thought I should try running Visual Studio 2010 again, just in case. Everything was fine.
Logic tells me that the SP1 “rollback” was not quite a rollback, since it fixed the problem. Then again, bear in mind that it was rolling back the reapplication of the service pack which is different from the usual rollback scenario.
Visual Studio, .NET, myriad SDKs that each get updated at different times, developers who download and install these in an unpredictable order … it is not surprising that it goes wrong sometimes; in fact it is surprising that it does not go wrong more often. So I guess I should not beat up Microsoft too much about this. Even so this was an unwelcome reminder of a problem I have not seen much in the last few years, other then with beta installs which play by different rules.