Migration issue: Namespace collisions

[andydandy74]

@aparajit-pratap - (if I understood you correctly) at the end of the discussion regarding #3208 you were saying that namespace collisions would no longer occur in existing custom nodes that use code blocks, i.e. they would automatically default to Dynamo's built-in namespaces. I recently tried running some of the Color nodes in package Clockwork and it looks as though namespace collisions are not resolved automatically (any more?).
I am not sure which package is interfering but I now have to call Color.ByARGB() as DSCore.Color.ByARGB() ...
0.8.1 RC 2

[aparajit-pratap]

@andydandy74 thanks for pointing this out. Will take a look and reply to you shortly.

[aparajit-pratap]

@andydandy74 I'm unable to reproduce this bug with the Clockwork package installed. Could you describe the steps to reproduce in more detail? Also which are the packages you have installed on your system. Perhaps it is some other package that is conflicting that I should try out. Thanks.

[andydandy74]

Clockwork doesn't contain any DLLs so it shouldn't be reproducible with just Clockwork installed. To reproduce try running any of Clockwork's Color nodes, they should all return null. When you open them, they look like this:

Here's my list of currently installed packages:

The same thing is happening with points again, as well, btw - which is to be expected since I have Rhynamo installed.

[aparajit-pratap]

Okay, I know why this is happening. The Clockwork package was created using code block nodes prior to the introduction of the namespace resolution work.

In the absence of any conflicting DLL's if in the current version of Dynamo (or other post 0.8.0 version), you recreate any one of the Clockwork custom nodes, say Color.Red and open the saved DYF file in a text editor, it will look like this:

<Workspace Version="0.8.2.1871" X="0" Y="0" zoom="1" Name="NewClockwork" ID="5ebb1950-59d8-4753-8150-fac97f8a9255" Description="" Category="Analyze">
  <NamespaceResolutionMap>
    <ClassMap partialName="Color" resolvedName="DSCore.Color" assemblyName="DSCoreNodes.dll" />
  </NamespaceResolutionMap>
  <Elements>
    <Dynamo.Nodes.CodeBlockNodeModel guid="32a616f4-9ab2-425c-a07b-031672a9447c" type="Dynamo.Nodes.CodeBlockNodeModel" nickname="Code Block" x="281" y="239" isVisible="true" isUpstreamVisible="true" lacing="Disabled" CodeText="Color.ByARGB(255, 255, 0, 0);" ShouldFocus="false" />
    <Dynamo.Nodes.Output guid="8660c144-4333-4bf8-8193-7accfdeb67a2" type="Dynamo.Nodes.Output" nickname="Output" x="653.5" y="246.5" isVisible="true" isUpstreamVisible="true" lacing="Disabled">
      <Symbol value="" />
    </Dynamo.Nodes.Output>
  </Elements>
  <Connectors>
    <Dynamo.Models.ConnectorModel start="32a616f4-9ab2-425c-a07b-031672a9447c" start_index="0" end="8660c144-4333-4bf8-8193-7accfdeb67a2" end_index="0" portType="0" />
  </Connectors>
  <Notes />
  <Annotations />
  <Presets />
</Workspace>

Observe the extra NamespaceResolutionMap XML element. This contains the mapping of Color to DSCore.Color internally. So when this DYF is used in Dynamo, it knows how to map existing Color nodes. This is how the namespace resolution works.

In the absence of this mapping information (such as in the older Clockwork DYF files) however, there is no way to resolve the nodes as the system cannot decide which namespace (among a conflicting set) to use for the node.

You may then ask that if someone needs to create a new package of custom nodes using CBN's, will they always have to uninstall all conflicting packages first. The answer is no, because in such a case, the moment you try creating a CBN, the autocomplete will kick in and prompt for all the namespaces having Color class, from which you can pick which version you wish to use in your custom node and this information will then be saved as the NamespaceResolutionMap entry to the DYF files in your package.

In the case of Clockwork package, the only suggestion I can think of right now is to manually update all the DYF's in the package with the following XML:

<NamespaceResolutionMap>
    <ClassMap partialName="Color" resolvedName="DSCore.Color" assemblyName="DSCoreNodes.dll" />
  </NamespaceResolutionMap>

as shown in the sample XML file above, and then to update the package on the package manager.

[andydandy74]

@aparajit-pratap - thanks for looking into it. Since this is - if I understand you correctly - a legacy issue, I will close it.
Just one more question: I have updated the nodes by replacing Color with DSCore.Color. Do you think that's a sustainable solution as well or would it be better to update the node's XML in the way you indicated?

[aparajit-pratap]

Either way should be fine.