SDK 4.0.0 FindFullyInstantiatedType public->internal

Questions regarding the use of the .NET SDK 2.0 for Server or Client development or integration into customer products ...

Moderator: uasdknet

Post Reply
MichaelP
Jr. Member
Jr. Member
Posts: 2
Joined: 04 Oct 2023, 16:34

SDK 4.0.0 FindFullyInstantiatedType public->internal

Post by MichaelP »

Hello Support Team,

In UnifiedAutomation.UaServer, Version=3.3.1.0 there was this public class FullyInstantiatedType.
With this there was as well this method in UnifiedAutomation.UaServer.TypeManager:
public FullyInstantiatedType FindFullyInstantiatedType(NodeId typeId)

With version 4.0.0 of the .Net SDK the class FullyInstantiatedType became 'internal'.
The method UnifiedAutomation.UaServer.TypeManager.FindFullyInstantiatedType is now 'internal' as well:
internal FullyInstantiatedType FindFullyInstantiatedType(NodeId typeId)

Was this change done by intention respectively is there a replacement for FindFullyInstantiatedType?

Thanks for a reply
Michael

User avatar
Support Team
Hero Member
Hero Member
Posts: 3079
Joined: 18 Mar 2011, 15:09

Re: SDK 4.0.0 FindFullyInstantiatedType public->internal

Post by Support Team »

Hi,

The FullyInstantiatedType related code is used in the CreateObject/CreateVariable code.
In version 3.4 we added the OverrideSubtypes feature, which required a major rewrite of the FullyInstantiatedType and TypeManager code. It was not possible to do this without a breaking change. We decided to make the FullyInstantiatedType internal, because we have not seen any use case to utilize it besides in CreateObject. Since it is now internal, we do not preseve API compatibility. In fact, there will be "breaking" changes to it in version 4.1. That said our intention is that it must say internal and should not be used public.

For what you are using the FullyInstantiatedType? Maybe, we find another solution for your use case.
Best regards
Unified Automation Support Team

MichaelP
Jr. Member
Jr. Member
Posts: 2
Joined: 04 Oct 2023, 16:34

Re: SDK 4.0.0 FindFullyInstantiatedType public->internal

Post by MichaelP »

Thanks for the reply.
We used it for example to create all the optional variables of a FxAssetType. Therefore we were looking for a fully instantiated type of an FxAsset. Then we copied from this instance the variable settings for ‘TypeDefinitionId’, ‘BrowseName’, ‘DataType’, ‘ModellingRule’ etc. to build a ‘UnifiedAutomation.UaServer.CreateVariableSettings’ instance to finally call the ‘CreateVariable’ method of the node manager.
Best Regards
Michael

User avatar
Support Team
Hero Member
Hero Member
Posts: 3079
Joined: 18 Mar 2011, 15:09

Re: SDK 4.0.0 FindFullyInstantiatedType public->internal

Post by Support Team »

Hi,

ok, understood your use case, if you know the optional variables that you want to use, there is a more comfortable way of doing so:

Optional variables or objects can be instantiate via the OptionalBrowsePaths and SubtypeOverrides properties of the CreateInstanceSettings. With the latter, you can even use a subtype of the defined ObjectType or VariableType. For example if the ObjectType of a device has a alarm child node of the type LimitAlarmType, you can narrow the node type to the ExclusiveLimitAlarmType. In both cases, the BrowsePath is specified in a (somewhat quirky) syntax. The BrowseNames are separated by a slash. If the qualified name is not from NS0 the namespace index (separated by a colon) is prefixed. Note, we discourage to use string literals for the BrowsePaths.

The correct way to build those strings is to use `AbsoluteName.ToString(QualifiedName[] browseNames)`, with a list of qualified names. Often you do not deal with qualified names, because you do not know the actual namespace index. So you have to create first an AbsoluteName and than convert it to a qualified name with `AbsoluteName.ToQualifiedName()`. We are aware that this syntax is suboptimal. There are plans for 4.1 to improve this.
Best regards
Unified Automation Support Team

Post Reply