Corehost Licensing & QueuedWorker.Run vs. QueuedTask.Run

[Justin_ODell]

We're trying to write unit tests for an ArcGIS Pro Add-In.

1) Is there a way to get an ArcGIS Pro license for accessing ArcGIS.Core.Hosting.Host without installing Pro on our build server?

For example, by copying the infomation that points Pro to the concurrent license server or single use license?

2) When our code must be run in a separate thread, there are two methods for doing it: QueuedWorker.Run (for freestanding CoreHost applications) and QueuedTask.Run (for ArcGIS Pro Add-Ins).  When running unit tests against that code, how do we tell it which one to use?  We'd like to use the same code in both the unit test and the Add-In.

I've seen this comment, which helps, but doesn’t quite answer the question above: https://community.esri.com/thread/164535#comment-546949

Thanks much!

[CharlesMacleod]

1) The main issue is that you cannot run a CoreHost exe without installing Pro. You can, however, configure a license for Pro via the installer command line so you never have to actually "run" Pro. Refer to ArcGIS Pro installation command line parameters

2) You could probably get away with using QueuedWorker.Run in your unit test harness for utility methods and the like that use only Geodatabase (and Geometry) code. For example, you have a helper library that you include in add-ins and a CoreHost app and you want to test that. However, you cannot use QueuedWorker in an Add-in nor QueuedTask in CoreHost. To the outside world they seem to perform a v. similar purpose but internally what they have to accomplish is completely different. [note: ArcGIS.Desktop.Framework.dll is not supported for use in CoreHost so QueuedTask's use in CoreHost is actually moot].