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
SDK 4.0.0 FindFullyInstantiatedType public->internal
Moderator: uasdknet
-
- Jr. Member
- Posts: 2
- Joined: 04 Oct 2023, 16:34
- Support Team
- Hero Member
- Posts: 3079
- Joined: 18 Mar 2011, 15:09
Re: SDK 4.0.0 FindFullyInstantiatedType public->internal
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.
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
Unified Automation Support Team
-
- Jr. Member
- Posts: 2
- Joined: 04 Oct 2023, 16:34
Re: SDK 4.0.0 FindFullyInstantiatedType public->internal
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
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
- Support Team
- Hero Member
- Posts: 3079
- Joined: 18 Mar 2011, 15:09
Re: SDK 4.0.0 FindFullyInstantiatedType public->internal
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.
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
Unified Automation Support Team