Dynamo: [Bug][DesignScript] Namespace issues causing Input Port Generation

[Amoursol]

If this issue is with Dynamo for Revit, please post your issue on the Dynamo for Revit Issues page.

If this issue is not a bug report or improvement request, please check the Dynamo forum, and start a thread there to discuss your issue.

Dynamo version

1) Dynamo Studio 1.3.0.881 & Dynamo Core 1.3.3.4111
2) Dynamo Revit 2.0.0.4655 & Dynamo Core 2.0.0.4665

Operating system

Windows 10

What did you do?

I have namespace conflicts with some of my custom packages, so I'm trying to hardcode in the default Dynamo namespaces. This is causing input ports to be generated in lieu or correctly calling the right function.

What did you expect to see?

I expected the hard-coded namespace to correctly call the relevant library - in this case Geometry.

What did you see instead?

Input ports being auto-generated as the Code Block is not recognising the namespace.

Dynamo Revit v2.0

Dynamo Studio v1.3

[mjkkirschner]

@aparajit-pratap FYI

[jnealb]

@mjkkirschner @aparajit-pratap @Racel @Amoursol Is this already filed in JIRA?

[mjkkirschner]

don't think so.

[jnealb]

@aparajit-pratap ?

[dimven]

Previously reported in #7697 and #8084

Whenever classes share a name, there's a namespace conflict and you need to provide the full path to clarify which class must be used. However that namespace lookup doesn't seem to be implemented for imperative code...

[aparajit-pratap]

@jnealb @mjkkirschner this is leagacy - hasn't been fixed yet: https://jira.autodesk.com/browse/DYN-704

[jnealb]

Thanks @aparajit-pratap

[mjkkirschner]

@aparajit-pratap @Racel is a workaround for this documented? I think it should be if one exists... something like defining your function outside the imperative block. like

coolFunc = Autodesk.Point.ByCoordinates;

[Imperative]
{
yada yada
newPoint = coolFunc(0,0,0);
}

[Racel]

@mjkkirschner no this is not documented. Should we put this in the release notes?

[mjkkirschner]

please put this in the release notes or design script updates doc/ with a workaround if it proves to work... @Amoursol can you try the suggested work around?

[Amoursol]

I've tested the workaround and it functions correctly @mjkkirschner! Thanks for that :)

[Racel]

Thanks @Amoursol and @mjkkirschner Added to the release notes and language changes docs as known issues.

[mjkkirschner]

@Racel @aparajit-pratap @smangarole @jnealb - There are a bunch of bugs like this that users run into all the time - finding them and communicating the workarounds to users is tough when they are closed - why are they closed when they are still issues? Can we add a new label like tracked or something more explicit and stop closing issues that are not actually fixed?

[andydandy74]

That would be much appreciated!

[aparajit-pratap]

@mjkkirschner I would like to see them open myself but I think the general protocol followed by QA so far has been to close them after filing them internally. I leave it up to the team to decide which is better.

[jnealb]

@Racel @mjkkirschner @aparajit-pratap @smangarole @Dewb @andydandy74 Yes that protocol was adhered to leading up to the 2.0 release. Nothing wrong with revisiting it now.

Also, please see JIRA task QNTM-4354 for a suggested follow-up to these issues.

[mjkkirschner]

so I'm going to open this then. 😄

[mjkkirschner]

@Racel @johnpierson - should we add a tracked label for these issues which we want to mark as tracked in jira?

[Racel]

@johnpierson Thanks for adding the Tracked label!

[mjkkirschner]

I think this should be fixed now - yay!