-
Notifications
You must be signed in to change notification settings - Fork 160
Description
REVISED - 30 May 2025
We currently have a set of constants to represent standard package names but the values themselves are simply objects and all knowledge of the Type to which they should be cast has to reside in the programs using the settings.
In addition, the current version of the console runner contains an out-of-date copy of the framework's FrameworkPackageSettings.cs
file, which should be updated.
Instances of a new class representing an individual setting should have the following characteristics...
- The name of each instance should be the same as our existing constants.
- Type of each setting should be defined so that it's not possible to create a setting value of the wrong type. This probably implies a generic implementation.
- Settings should be able to serialize and deserialize themselves within the context of a TestPackage, as well as individually, for testing purposes. See issue Non-string TestPackage settings values are not deserialized correctly #1677.
- Since a wide range of types are already supported, it may not be possible to limit setting Types to
string
,int
andbool
as was previously discussed - and as currently stated in some documentation! However, we may be able to limit serialization to those types by using XML representation of other types. - Unlike the original approach using
BinarySerializationFormatter
, which we have now abandoned, deserialization will not be able to blindly accept any type but must have knowledge of the type expected as data for each message code. This means that agents must share the same definitions of supported settings that the engine uses.
This description has been expanded from the original one, primarily due to the impact of framework settings. While, engine settings are entirely internal and may be redefined to use a limited set of Types, this is not the case with the framework. In order to support the current framework and remain backwards-compatible with earlier versions, a wide range of Types must be supported. However, we retain the requirement that the agents must know about the expected Types in order to convert them to what the framework requires.