SSOSettingsFileReader.dll removed from GAC

Topics: Bindings File, Settings Management and SSO
Dec 18, 2014 at 2:10 PM
Hi

We've noticed an issue during deployments where the SSOSettingsFileReader.dll is removed from the GAC during a full redeploy (Undeploy, Uninstall, Install, Deploy). As this dll is shared by all the BizTalk applications it really should be left alone.

In testing I can't see the BTDF removing from the GAC during an Undeploy and it's still there after an Uninstall. Can you confirm that there isn't a scenario where BTDF will remove SSOSettingsFIleReader.dll from the GAC?
Coordinator
Dec 18, 2014 at 3:25 PM
The Deployment Framework never removes SSOSettingsFileReader.dll from a machine. It gets deployed with every app deployment, but never undeployed.

Thanks,
Tom
Dec 18, 2014 at 3:26 PM
I suspect the issue stems from the fact that BTDF is GAC'ing SSOSettingsFileReader from the application directory. So whatever the last app to be deployed is where the DLL will be GAC'ed from. During an uninstall the DLL is deleted but the GAC'ed version remains. It also means that it shifts around a lot between applications.

The error we got was the "assembly's manifest did not match" rather than it could not find it. As it's a shared resource could the BTDF check to see if it's in the GAC already rather than just force install it? Or GAC from the BTDF directory rather than the each applications deploytools dir?
Coordinator
Dec 18, 2014 at 3:48 PM
If it's in the GAC, it's available. It doesn't matter if it exists 0-n other places on the machine. Have you recently changed or upgraded your version of BizTalk? There are different versions of SSOSettingsFileReader.dll for BizTalk < 2013, BizTalk 2013 and BizTalk 2013 R2.

Tom
Dec 18, 2014 at 4:21 PM
Edited Dec 18, 2014 at 4:29 PM
Normally I would agree. However we haven’t changed anything with the platform or build servers. The only change was that we were installing a new version and the error occurred within an unrelated application. It has happened before during an deployment but we dismissed it as an unrelated glitch as like you said the GAC’d instance is still there. The frequency of this error is now at a point where we will have to stop BizTalk for the entire deployment cycle, which is problematic.

Perhaps something happens if the DLL is referenced at the exact same time a new version of the app GAC’s it.
Coordinator
Dec 18, 2014 at 4:42 PM
Have you binary-compared SSOSettingsFileReader.dll across all of your app install folders? It almost sounds like you have two different versions floating around. With the exception of an AppDomain restart, a .NET process never unloads a DLL once loaded. I've found many mentions online of DLL's in the GAC being locked by a process. That makes it hard to see how an application that is already running would suddenly fail with a DLL load error. Have you ever tried using Process Explorer to see if anything holds a reference to/lock on the GAC'd SSOSettingsFileReader.dll?

Tom
Dec 18, 2014 at 4:50 PM

All our MSI’s are built by the same build server which is where I assume the package gets all the deploy tools. The host instances are restarted during the undeploy so it would have to reload the DLL’s. The error occurred after the undeploy and sometime during the install\deploy of the new version.

We can do a compare of all the SSOSettingsFileReaders.

Coordinator
Dec 18, 2014 at 5:08 PM
If you put this into a .btdfproj, it will eliminate deployment of SSOSettingsFileReader.dll (and Log4Net if you're using it):
  <Target Name="DeploySharedAssemblies" />
Maybe that will help narrow it down.

Thanks,
Tom
Dec 18, 2014 at 5:12 PM
Thanks, will give it a try.

I don't think it's using a different version. The error only occurs during deployments and seems to resolve itself once the LAST SERVER is deployed i.e. host instances restarted. If another app was referencing a different version I don't see how that would resolve it, I'd expect it to keep failing.