MilitaryToolsForArcGISPro Projects fails to build on PackageAddIn Step at Pro 2.3

[csmoore]

It looks like Pro 2.3 final SDK added a requirement for 'defaultNamespace' to be defined/set/non-null in the DAML file.

This now causing an error when we try to build on Pro 2.3 during the PackageAddIn Task (last build step that creates the zip/addin from the release folder):

>C:\Program Files\ArcGIS\Pro\bin\Esri.ProApp.SDK.Desktop.targets(343,5): error : ArcGIS element 'defaultNamespace' attribute not found

Unfortunately, because we are consuming addins from other dlls/namespaces, I don't think we can't just set this namespace in the daml without causing problems so we will need to look further into this for a solution to have the same dockpanel classes in 2 different addins (standalone addins and toolbar addin).

Update/Wrokaround: A temporarily work around for this problem is to copy the Pro 2.2 version of Esri.ProApp.SDK.Desktop.targets into the Pro 2.3 bin folder (note: back up the original first).

[csmoore]

I was able to temporarily work around this problem by copying the Pro 2.2 version of Esri.ProApp.SDK.Desktop.targets into my 2.3 Pro bin folder.

But we will likely have to contact the Pro SDK team to let them know about our unique setup. Not all of the dlls we include in our addin have the same root namespace so this change at 2.3 to require this broke building this toolbar on 2.3. FYI @kgonzago @lfunkhouser

[chris-fox]

@csmoore, got forwarded this issue and have some familiarity on the topic so wanted to pass along. The defaultNamespace is only used if you don't fully qualify your class name with the namespace in any references in the daml. Looking at your daml file it looks like you are providing the namespace with any class reference. This makes sense because without it and without specifying a defaultNamespace previously the add-in wouldn't have been able to resolve the reference.

You should be fine to add the defaultNamespace. The typically pattern is to set the defaultNamespace to the defaultNamespace of your insert module assembly.

[csmoore]

@chris-fox - just trying to understand the recommended solution:

1. Go ahead and set the default namespace
2. Just fully qualify anything used that is outside of this namespace

It seems like everything in the daml is already fully qualified: ex but when we tried setting the defaultNamespace to anything other than "" - Pro could no longer find the classes (nothing happens when you click the buttons) so it seems like classes outside of this default namespace don't seem to be able to be found.

[chris-fox]

@csmoore, yes that is my understanding of how it should work. But I am seeing the same issue as you, if you hover over the disabled command after you click it, it will tell you it was unable to find the type and you can see Pro is adding the defaultNamespace as a prefix to the fully qualified path which is why it breaks.

If you take a look at the Pro install and look at the Layout daml (\bin\Extensions\Layout\ArcGISLayout.daml) you can see they are using a default namespace, but also referencing classes in the mapping assembly. Everything looks the same as you, so not sure why it is behaving different, maybe something subtle we are missing. I know with Pro everything in the extensions folder is basically an add-in, daml file + 1 or more assemblies, so we are using the same framework. Would recommend e-mailing Charles Macleod and Chris Zent on the Pro SDK team to take a closer look.

[csmoore]

@chris-fox - thanks very much for taking such a close look are our issue and pointing us at an example to compare

[csmoore]

@lfunkhouser - can you pass this issue on to Charlie M and Chris Z, details of the issue and investigation are above, but in summary the issue is:

1. We have a toolbar addin that uses buttons/classes from other dlls/namespaces
2. Building this worked prior to Pro 2.3 (actually until a few weeks prior to 2.3 release)
3. But at 2.3 the SDK made a change that required the defaultNamespace attribute to be set in the DAML
4. Once we set this property, Pro can no longer find any of the classes outside of this namespace, because it seems to prepend the defaultNamespace namespace to these already fully-qualified class names (screenshot below).
5. We compared what we are doing in the DAML to another file that uses classes external to the defaultNamespace - Extensions\Layout\ArcGISLayout.daml - and can't see any obvious differences so are not sure why this is happening if we are both using the same SDK build tasks

In this example, the defaultNamespace value (ProAppModuleMilitaryTools) should not be added to this class name ( defined here )

[csmoore]

This is still an issue at 2.4 - but we have a workaround (use previous SDK build file) and won't become a major issue until 2.3 becomes our base build - we should contact SDK team on this early in 2.5 dev