Known Issue: Replacing libraries when opening a ServiceDesk project will overwrite existing libraries with older or incorrect versions
Last Updated October 25, 2010
After opening a ServiceDesk project package in Workflow Designer on the ServiceDesk Server, Incident creation is slow, sending emails do not work or other functionality that was working no longer is. Or, other critical issues occur.
Additionally you may find errors similar to the one below in the SD.DataServices logs or in the logicbase.serverextensions.exe logs that mention SD.Components.NotificationServer7Reports.GetAllLocationsComponent.
Error,Wednesday, March 03, 2010 1:37:17 PM,User Search failed with the following: Could not read in object System.Exception: Could not read in object---> LogicBase.Framework.ObjectDeserializationError: could not deserialize: System.Collections.ArrayList ---> System.Exception: could not find type SD.Components.NotificationServer7Reports.GetAllLocationsComponent at LogicBase.Framework.ArrayListTypeConverter.GetObject(ObjectStorageContainer storageContainer, ObjectStorageObjectData values, Type valueType, ObjectStorageErrorHandler errorHandler) at LogicBase.Framework.ObjectReadStream.ReadRelationshipConverter(ObjectStorageValue objValue, Type type, ObjectStorageRelationshipTypeConverter converter)
This type of issue will occur if you select to replace the server version of libraries with ones from ServiceDesk projects. This option is presented when you open a ServiceDesk project .package file in Workflow Designer, as shown on the screen shot below.
Sometimes these boxes are automatically checked, other times they are not. Checking either box will replace the listed libraries in the Program Files (x86)\Altiris\Workflow Designer\Shared\customlib folder that are installed with with the package for the project which may not be the same versions versions. The effect of doing so will be immediate.
Any ServiceDesk project that uses the SD.Components.dll library, and this includes almost all of them, will start using the version of the library you chose to replace the original version with, be it a custom, older, or newer library file. This is an issue as the library code is different and not all the same classes are present.
The first step towards resolution is to never check any box in the Custom Library Conflict dialog windows when given the option. If checkboxes are already checked, uncheck them.
The second is to identify the libraries that have been replaced and if possible get the proper versions of these libraries back into the customlib folder. If identifying the replaced libraries is not possible then a reinstall of ServiceDesk using the Upgrade option has been shown to work.
This issue can occur if any DLLs are replaced, not just the SD.Components.DLL and the SD.DataTypesCore.dll. Issues and results can be very unpredictable. It's possible to have many mis-matched DLLs from older or newer versions, or customized versions. Ultimately, a clean new install of ServiceDesk may need to be performed to help guarantee a working environment for the DLLs.