topic How does EG tell which DLL file to load for an add-in? in SAS Enterprise Guide

How does EG tell which DLL file to load for an add-in?

prholland — Thu, 15 Nov 2012 20:35:52 GMT

This may appear to be an odd question, but it comes from experimenting with multiple versions of the effectively the same add-in written in VB.NET. I've tried several different ways to distinguish between versions:

Different file names and task names, but the content in the different DLL files is the same = EG loads the DLL with the "earlier" name, i.e. TaskA.dll, not TaskB.dll!
Different file names, task names and ClassId/GUIDs, but the rest of the content the same = EG loads the DLL with the "earlier" name, i.e. TaskA.dll, not TaskB.dll!
Different file names, task names, ClassId/GUIDs and version numbers, but the rest of the content the same = EG loads the DLL with the "earlier" name, i.e. TaskA.dll, not TaskB.dll!
Different file names, task names, ClassId/GUIDs, version numbers and namespaces, but the rest of the content the same = EG loads the DLL with the "earlier" name, i.e. TaskA.dll, not TaskB.dll!

How do you create similar custom tasks with similar contents that appear as different add-in menu items?

.........Phil

Re: How does EG tell which DLL file to load for an add-in?

ChrisHemedinger — Thu, 15 Nov 2012 20:53:17 GMT

Phil,

It depends on how you've registered the task. If you can, I advise the "drop-in" deployment where you simply put the DLL(s) in one of the designated Custom folders. Example locations for EG 4.3:

%appdata%\SAS\EnterpriseGuide\4.3\Custom

PROGRAMFILES\SASHome\x86\SASEnterpriseGuide\4.3\Custom

If you use the Add-In Manager to register the task, then that entry stays in place until you remove it or otherwise update it, even if you change the file contents (such as ClassID or task name).

The ClassID is THE unique piece that distinguishes one task from another, so if you have any tasks that contain duplicate ClassIDs, all but one will be obscured. Which one that is a bit of a chance -- falling to method of registration or alphabetical ordering of the DLL names.

If you want to see what's going on in the task discovery/loading, turn on the extra logging feature in EG. The log produced is meant for SAS tech support and developers to help diagnose issues, but you should be able to glean some information this way. This SAS note tells you how to enable it and where you can find the log files.

Example excerpt from such a log:

2012-11-01 16:36:33,499 [Main] INFO SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Loading custom task assembly: C:\Users\sascrh\AppData\Roaming\SAS\EnterpriseGuide\4.3\Custom\SAS.Tasks.SGDesigner.dll

2012-11-01 16:36:33,505 [Main] DEBUG SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Loaded assembly C:\Users\sascrh\AppData\Roaming\SAS\EnterpriseGuide\4.3\Custom\SAS.Tasks.SGDesigner.dll

2012-11-01 16:36:33,507 [Main] INFO SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Successfully loaded custom task assembly: SAS.Tasks.SGDesigner, Version=4.3.0.0, Culture=neutral, PublicKeyToken=be58efc3b934219b

2012-11-01 16:36:33,510 [Main] INFO SAS.Shared.AddIns.Management.AddInProxy [(null)] - Creating AddInProxy for SAS.Tasks.SGDesigner.CreateSampleDataTask, C:\Users\sascrh\AppData\Roaming\SAS\EnterpriseGuide\4.3\Custom\SAS.Tasks.SGDesigner.dll

2012-11-01 16:36:33,529 [Main] INFO SAS.Shared.AddIns.Management.AddInProxy [(null)] - Creating AddInProxy for SAS.Tasks.SGDesigner.SGDesignerReplay, C:\Users\sascrh\AppData\Roaming\SAS\EnterpriseGuide\4.3\Custom\SAS.Tasks.SGDesigner.dll

2012-11-01 16:36:33,542 [Main] INFO SAS.Shared.AddIns.Management.AddInProxy [(null)] - Creating AddInProxy for SAS.Tasks.SGDesigner.LaunchSGDesignerTask, C:\Users\sascrh\AppData\Roaming\SAS\EnterpriseGuide\4.3\Custom\SAS.Tasks.SGDesigner.dll

Chris

Re: How does EG tell which DLL file to load for an add-in?

prholland — Thu, 15 Nov 2012 22:02:45 GMT

Chris,

I don't think my add-ins are exposing their PublicKeyToken:

* 2012-11-15 21:26:08,669 [Main] INFO
SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Loading custom task assembly: C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_Aaaaa.dll
* 2012-11-15 21:26:08,269 [Main] DEBUG
SAS.EG.MainForm [(null)] - AddInRegistry.ConstructAddInRegistry() - Creating add in task registry.
* 2012-11-15 21:26:08,269 [Main] DEBUG
SAS.EG.MainForm [(null)] - AddInRegistry.ConstructAddInRegistry() - loading add in task.
* 2012-11-15 21:26:08,669 [Main] INFO
SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Loading custom task assembly: C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_Aaaaa.dll
* 2012-11-15 21:26:08,730 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Loaded assembly C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_Aaaaa.dll
* 2012-11-15 21:26:09,046 [Main] INFO
SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Successfully loaded custom task assembly: DataGridViewer_Aaaaa, Version=1.0.0.12111, Culture=neutral, PublicKeyToken=null
* 2012-11-15 21:26:09,062 [Main] INFO
SAS.Shared.AddIns.Management.AddInProxy [(null)] - Creating AddInProxy for DataGridViewer.DataGridViewer, C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_Aaaaa.dll
* 2012-11-15 21:26:09,102 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Asked to resolve location for DataGridViewer_Aaaaa.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null
* 2012-11-15 21:26:09,102 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - DataGridViewer_Aaaaa.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null is not handled in ResolveAssembly
* 2012-11-15 21:26:09,102 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Asked to resolve location for DataGridViewer_Aaaaa.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null
* 2012-11-15 21:26:09,102 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - DataGridViewer_Aaaaa.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null is not handled in ResolveAssembly

* 2012-11-15 21:26:09,166 [Main] INFO
SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Loading custom task assembly: C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_HNL.dll
* 2012-11-15 21:26:09,184 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Loaded assembly C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_HNL.dll
* 2012-11-15 21:26:09,185 [Main] INFO
SAS.Shared.AddIns.Management.AddInRegistry [(null)] - Successfully loaded custom task assembly: DataGridViewer_HNL, Version=1.0.0.12111, Culture=neutral, PublicKeyToken=null
* 2012-11-15 21:26:09,187 [Main] INFO
SAS.Shared.AddIns.Management.AddInProxy [(null)] - Creating AddInProxy for DataGridViewer_HNL.DataGridViewer, C:\Users\Phil\AppData\Roaming\SAS\EnterpriseGuide\5.1\Custom\DataGridViewer_HNL.dll
* 2012-11-15 21:26:09,189 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Asked to resolve location for DataGridViewer_HNL.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null
* 2012-11-15 21:26:09,189 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - DataGridViewer_HNL.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null is not handled in ResolveAssembly
* 2012-11-15 21:26:09,189 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - Asked to resolve location for DataGridViewer_HNL.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null
* 2012-11-15 21:26:09,189 [Main] DEBUG
SAS.EG.Utilities.AppDomainAssemblyResolver [(null)] - DataGridViewer_HNL.resources, Version=1.0.0.12111, Culture=en, PublicKeyToken=null is not handled in ResolveAssembly

I think I need to look at my VB.NET settings.

Thanks..............Phil

Re: How does EG tell which DLL file to load for an add-in?

ChrisHemedinger — Thu, 15 Nov 2012 22:31:14 GMT

Phil,

PublicKey doesn't play into it, I don't think. It's not a requirement for custom tasks. It comes into play only if you sign your task assemblies with a .NET strong name. We do this for our SAS-provided DLLs, but you don't have to.

It looks like, from the log, that your two tasks are loaded and "add-in proxies" are created for:

DataGridViewer.DataGridViewer

and

DataGridViewer_HNL.DataGridViewer

So...that's a good start.

Chris

Re: How does EG tell which DLL file to load for an add-in?

prholland — Fri, 16 Nov 2012 09:11:08 GMT

Chris,

I've finally seen where the problem is, as the ClassId and GUID values are different within each task, but the ClassId values are the same for both tasks:

DataGridViewer_Aaaaa = 2e9b68d0-d343-49de-8d6c-4e00da3e062f (ClassId in DataGridViewer.vb) / 5021c8c6-4f74-423b-9761-91aa4279db92 (GUID in AssembyInfo.vb)
DataGridViewer_HNL = 2e9b68d0-d343-49de-8d6c-4e00da3e062f (ClassId in DataGridViewer.vb) / 89fd058e-38ea-4316-b88e-98369e432d1c (GUID in AssembyInfo.vb)

I thought ClassId changed whenever I updated GUID, but, obviously, it doesn't!

Many thanks............Phil

Re: How does EG tell which DLL file to load for an add-in?

ChrisHemedinger — Fri, 16 Nov 2012 13:45:45 GMT

Phil,

That GUID that you see in the AssemblyInfo file is generated by Visual Studio as a unique ID for your project library, and I think it would be used only if the code library you write ends up exposed as a COM object with a type library. That isn't the scenario for a custom task.

GUIDs (or ClassIDs or UUIDs) are used for lots of different purposes in software development and elsewhere. The only one that matters to the custom task (add-in) API is the one you assign to the ClassId property in your task class.

Chris