Generated code should not have explicit namespace prefixes

[mpostol]

        protected override NodeId GetDefaultTypeDefinitionId(NamespaceTable namespaceUris)
        {
            return Opc.Ua.NodeId.Create(Boiler.ObjectTypes.GenericSensorType, Boiler.Namespaces.Boiler, namespaceUris);
        }

In this code NodeId and the Opc.Ua.NodeId are the seme type.

It makes the real problem if the code is not to be used in the Opc.Ua environment where the referenced classes are replaced by different once.

[opcfoundation-org]

Noted. But it will likely take a lot of time it do.

[ChristofferGersen]

These explicit namespace prefixes also prevent you from using the name Opc in you own namespace. For example, when you generate your model to a MyApp.Opc.Model namespace, then you get the following compilation error:

error CS0234: The type or namespace name 'Ua' does not exist in the namespace 'MyApp.Opc' (are you missing an assembly reference?)

This is because C# matches the Opc part of Opc.Ua.NodeId to MyApp.Opc (when done from within the MyApp.Opc.Model namespace). And there is no Ua declaration in that namespace.

When the explicit namespace prefixes are removed, then using such a namespace would become possible. Another possible fix for this problem would be to add a global:: prefix, so for example global::Opc.Ua.NodeId, to prevent Opc from matching with MyApp.Opc. But that would make the prefix even more explicit.

[mpostol]

@ChristofferGersen; the global::Opc.Ua.NodeId doesn't fix if you are going to use your definition of the NodeId - it is my case.

The generated code is dedicated to being used by UA-.NETStandard, but I am trying to reuse this code by PubSub where I have my stack independent implementation:

Reactive Networking of Semantic-Data Library

I am also considering to move common UA definitions to separate project and publish it as NuGet under the MIT license. I believe the common definitions could be extracted from official UANodeSet base model definition without breaking the mentioned UA-.NETStandard double license rules. In this case, your proposal works, but I am not allowed (it is not a good practice) to use Opc.Ua namespace. Using in my autogenerated common definitions the UAOOI.Opc.Ua namespace should work and the compiler code may be untouched, but the problem @ChristofferGersen mentioned persists.

[mpostol]

Is there any chance to push forward this issue? This issue was created a few years ago. Because the contributing policy is not defined for this repository my concern is if OPC Foundation needs any community feedback? In any case, if there is something wrong with it there is an option: ** won't fix and close the issue**.

It is a blocker for mpostol/ASMD#198

[opcfoundation-org]

The trouble is changing these kinds of things has the potential to break a lot of code that would extensive testing by users of the auto-generated code.

There is also the issue where the prefixes are actually required when there is a naming conflict with other assemblies.
Sometimes these name conflicts appear only when the .NET framework version is upgraded.

So despite being it reasonable request, it is unlikely to get done.

[mpostol]

I agree that the impact scope is hard to predict. Usually, it could be solved by postponing the namespace selection up to the running of the tool. For example, a new parameter (like in xsd.exe) or an additional configuration entry may be added.

Anyway, keep it open if you don't mind. It was reported a few years ago, so it should not be a problem. According to my roadmap, I plan to work on it on my fork as a contribution to further development of the MIT licensed open source Address Space Prototyping Tool (asp.exe).

I hope that everyone is aware that licensing policy and hardcoding approach, by design, makes this tool tightly coupled with the OPC Unified Architecture .NET Standard. This approach is against reusability and separation of concerns best practice rules and limits adaptability of the standard.

It is a really great effort. I appreciate. My concern is if limiting the scope of usage is not partially wasting this effort.

[mpostol]

According to the repository rules all feedback is applied to a private repository, hence I am no longer a willing helper to contribute to further development of the code. I am transferring this issue to my public fork mpostol#10 where the modification will be applied directly and available for the public immediately. Further questions and proposals - you may have - should be provided using the discussion panel of the fork or by adding comments to the mentioned issue. Let's work out it with you and for you.

Cloe it with wontfix reason.