Extensions and Patterns Compatibility in GeneXus X Evolution 3

The compatibility level has been updated; all extensions and patterns must be recompiled.

Modules and KBObjects

With the addition of Modules to Knowledge Bases, APIs related to obtaining an instance of a KBObject (or EntityKey) given its name have been substantially changed. For many object types, duplicate names are now allowed, as long as they belong to different Modules; the unique name of a KBObject is now its QualifiedName (of the form <ModuleName>.<ObjectName>).

Because of this architectural difference, we decided to purposely break interfaces that depended on the old assumption (one name maps to a single object), such as Model.Object.Get(Guid type, String name) and related methods. That way, just by recompiling the Extension or Pattern, compiler errors will signal any points where the logic may need to be changed.

How to update code to support Modules

To get a single object, KBModel.Objects.Get(type, name) no longer exists. It has been superseded by KBModel.Objects.Get(type, qualifiedName), since a QualifiedName is what now identifies an object uniquely. Compiling old code with the Evolution 3 SDK will produce this error:

Argument 2: cannot convert from 'string' to 'Artech.Architecture.Common.Objects.QualifiedName'

There are two options to substitute this API call:

1. Build the object's QualifiedName and use it in the new KBModel.Objects.Get(type, qualifiedName) method. QualifiedName instances can be constructed with a module and object name (or module name and object name). So this alternative can be used whenever you know in which module the object is present. This method, like the old one, returns a KBObject or null for no match.
2. Use the new ResolveName(fromModule, type, name, out resolveResult) method. The fromModule and name parameters are mandatory, while type is optional. This method will attempt to resolve the provided name (which can be the object's name, or a fully or partially qualified name -- for example, for an object name "A.B.C.D", you may provide just "D", or a partial name such as "B.C.D") in the context of the supplied module. The returned ResolveResult object contains the result of the name resolution: either no results, a single match, or a list of the possible matches (meaning that the provided object name is ambiguous in that context). Note that even if you provide a partial name for which there is more than one object in the KB, the resolution may be successful. That's what the supplied fromModule is used for (for example, if two "B" objects exist in the KB, and one of them is in the "M1" module, then calls to "B" from objects inside M1 will be resolved to it -- no ambiguity actually exists). See How are partially qualified object names resolved.

Other Methods

Getting an object with its EntityKey or GUID hasn't changed.

Specific methods for object types that can belong to modules, such as WebPanel.Get(model, name), have changed as well (to receive QualifiedName instead). Some, such as Domains, Attributes, or Themes, cannot be assigned a module, so the old methods (e.g. Attribute.Get(model, name)) are still valid, since their names are still globally unique. For the others, type-specific ResolveName methods (e.g. WebPanel.ResolveName(fromModule, name)) are also available.

KBModel.Objects.GetAll(string name) has been substituted by KBModel.Objects.GetByName(string @namespace, Guid? type, string name). Both namespace and type are optional.

Patterns

Make sure to install the correct GeneXus SDK, and check the following compatibility attributes are set with their Evolution 3 specific version:

If the attributes are not present, or their value doesn't match the expected one, GeneXus won't load them. You can check the status in the Extensions menu.

Make sure your project is linked to the CommonPackageInfo.cs and CommonPatternInfo.cs files in the SDK\SDKBase\Src folder directory, it should looks like this:

To link those files in your project check this article.