community
cancel
Showing results for 
Search instead for 
Did you mean: 

Dev Space

Customize & extend the power of Alteryx. SDKs, APIs, custom tools, and more!
#SANTALYTICS

The highly anticipated Alteryx Community tradition is back! We hope you'll join us!

Learn More
We will be upgrading the Gallery to our 2019.4 release this Saturday, December 7th beginning at 9:00am MT. We expect the outage to take last approx. 2.5 hours.
SOLVED

Plugin Tool Deployment

Alteryx Partner

I have developed some Plugin tools using the Alteryx SDK\API.  Two of the tools are based on the C++ SDK and one with the .NET SDK.  The tools are placed in a folder, <Alteryx>/bin/Plugins/Sitewise with a .ini file in <Alteryx>\Settings\AdditionalPlugins pointing to that folder.  This works great on my development Windows 10 computer, but when I provide my colleagues with the contents of the Sitewise folder, AlteryxGui.exe does not seem to be able to detect or load them.

 

I have tried the same thing with the CustomDotNetTools sample that comes with the SDK.  The tools show up fine on my development computer when I run Alteryx  Designer, but not on other machines.  (It does show up on one Windows Server 2012 machine that we have.)  All  of the versions of Alteryx Designer that we are using are the same: 2018.2.5.48994.  My colleagues are using Trial Versions of Alteryx Designer at this point, but that did not prevent them from using the sample Outlook tool that Alteryx support provided.

 

This is what the <Alteryx>\bin\Plugins\Sitewise folder contents looks like if I create just my one .NET based tool:

Volume in drive C has no label.
Volume Serial Number is 68B4-FF5F

Directory of C:\Program Files\AlteryxServer\bin\Plugins\Sitewise

08/10/2018 12:14 PM <DIR> .
08/10/2018 12:14 PM <DIR> ..
01/07/2017 09:11 AM 9,713,360 Aspose.Cells.dll
11/03/2016 04:24 PM 9,233,408 Aspose.Words.dll
02/22/2010 04:33 PM 5,233,512 DocumentFormat.OpenXml.dll
08/10/2018 12:14 PM 0 files.txt
11/03/2016 04:24 PM 61,440 GeoAPI.dll
05/26/2015 01:36 PM 83,168 Microsoft.VisualStudio.Tools.Applications.Runtime.dll
05/26/2015 01:36 PM 202,480 Microsoft.VisualStudio.Tools.Applications.ServerDocument.dll
11/03/2016 04:24 PM 376,832 MySql.Data.dll
11/03/2016 04:24 PM 628,224 NetTopologySuite.dll
11/25/2016 02:35 PM 446,464 Npgsql.dll
11/03/2016 04:24 PM 229,376 PowerCollections.dll
08/10/2018 10:03 AM 47,616 Sitewise.Alteryx.Tools.dll
08/09/2018 09:57 PM 4,619,776 Sitewise.Framework.Base1200.dll
08/09/2018 09:57 PM 1,644,032 Sitewise.Framework.dll
14 File(s) 32,519,688 bytes
2 Dir(s) 647,416,737,792 bytes free

 

Does anyone have experience with Plugin tools not appearing as they should?  Is there more to the deployment process than just copying the plugin DLLs and creating a .ini file in <Alteryx>\Settings\AdditionalPlugins?

 

I imagine AlteryxGui.exe will attempt to look into ALL of the DLLs that are in the folder and see which ones are potential plugin tools.  Could this be a problem with some DLLs?

Highlighted

For the one or two .NET plugins I created, I deployed them differently.  Rather than creating a .INI file I used the deployment process described in the other SDKs.  This deployment process has worked with .NET without issue for me and everyone I have installed them for:

 

  1. Copy the DLL(s) to <Alteryx>\bin\plugins
  2. Create an XML configuration file to describe the plugin.  Mine looks something like this:
<?xml version="1.0"?>
<AlteryxJavaScriptPlugin>
  <EngineSettings EngineDll="MyCustomDll.dll" EngineDllEntryPoint=".Net:MyToolNamespace.MyToolClass" SDKVersion="10.1" />
  <GuiSettings Html="MyTool.html" Icon="MyToolIcon.png" Help="" SDKVersion="10.1">
    <InputConnections>
      // Your input connections here
    </InputConnections>
    <OutputConnections>
      // Your output connections here
    </OutputConnections>
  </GuiSettings>
  <Properties>
    <MetaInfo>
      <Name>My .NET Tool</Name>
      <Description>Does cool .NET stuff.</Description>
      <CategoryName>Laboratory</CategoryName>
      <SearchTags></SearchTags>
      <ToolVersion>1.00</ToolVersion>
      <Author>Me</Author>
      <Company></Company>
      <Copyright>2018</Copyright>
    </MetaInfo>
  </Properties>
</AlteryxJavaScriptPlugin>

Note that I have used an HTML GUI.  If you built your GUI using .NET forms you should be able to direct the XML file to that class, but I am not sure what it would look like.

 

Package this XML file into a YXI installer.  Alternatively, if you prefer a more manual installation method, create a folder for your tool in <Your user folder>\AppData\Roaming\Alteryx\Tools and copy the XML file there.  Note that the name of the XML file has to be the name of your tool followed by 'Config'.  So if I had a tool called 'SsasImporter', then I would create a folder in the AppData directory called 'SsasImporter' and place an XML file inside called 'SsasImporterConfig.xml'.

Alteryx Partner

Thanks for your insights on this.  The XML tool discovery format makes more sense than the old way of loading assemblies and searching for a particular class interface.  However, I don't see any way of specifying how to find the .NET based WinForm Control class with the XML format.  I suspect that it is not possible, but maybe someone at Alteryx can prove me wrong.  One of my tools has an intricate WinForms GUI that would take weeks to re-implement as an HTML GUI, so that isn't an option for me.

Yeah, I think you are correct; it doesn't seem possible.

 

Can you try putting your DLLs in the <Alteryx>\bin\plugins folder?  Do they show up anywhere in Designer (try looking in the Laboratory folder if you cannot find them).

 

I just created a test GUI and was able to get it working just by placing the DLL in bin/plugins folder.  I assume, because they work on your machine, that you have classes which implement the following set of interfaces?:

  • UserControl and AlteryxGuiToolkit.Plugins.IPluginConfiguration, for the GUI
  • AlteryxGuiToolkit.Plugins.IPlugin, which points to the engine implementation and provides the IPluginConfiguration GUI class
  • AlteryxRecordInfoNet.INetPlugin, for the engine implementation

Is it possible any of these classes are in DLLs which were not distributed to your colleagues?  Is it possible you created 64-bit DLLs and your colleagues are using a 32-bit OS?  I am kind of baffled that it is not working for you, so I am shooting in the dark here.

Alteryx Partner

Thanks again for your thoughts on this issue.

 

There is no doubt that my tool meet the interface requirements of Plugin tool.  We are also all using the same x64 version of Alteryx.

 

My main hypothesis at this stage is that there might be a missing DLL dependency in the tools.  If one of my plugin tools is dependent on X.dll which is not in the same folder as the plugin, then it might be found on my system by say the PATH variable, but not on another machine in which the folder location of X.dll is not in the PATH or it might not even be on that machine.  However, we have the same problem on one machine with the sample Xml plugin tool that Alteryx provides and it is very simple with few dependencies. We have tried using the Dependency Walker tool but it isn't readily apparent that there is anything missing.

 

My other hypothesis is that something goes wrong when Alteryx tries to use LoadAssembly() and .NET reflection on the DLLs in the folder pointed to by the AdditonalPlugins ini file.  AlteryxGui.exe would have to load every DLL in the folder to discover which have the plugin interface, and it could be that in the process of loading and reflecting an error occurs that throws it out of the load/reflect loop and then prevents any other plugins from being discovered.  I will try to change my code so that the DLLs that are NOT implementing the AlteryxGuiToolkit.Plugins.IPlugin interface are in a different folder.

 

 

We have tried putting our plugin tools in <Alteryx>\bin\Plugins.  That results in a lot of the standard plugin tools disappearing from the tools tabs, and our tools still aren't shown.  (I had to uninstall and reinstall Alteryx to clean up after that mess.)

 

 

Alteryx Partner

So after some more investigation it turns out that the reason the tools weren't getting loaded is due to the Windows .NET CAS policy. Code Access Security (CAS) is the .NET Common Language Runtime (CLR) mechanism for maintaining security based on the identity of code.  If you copy files through MS Teams or Dropbox (as we did with our plugin tool DLLs) then Windows flags the files as having been copied from the web, even as it resides on our computers.  Once the DLL file has been flagged in this way, any process that is dependent on these DLLs will be prevented from loading it for security reasons, even though there is no explicit message anywhere that this is happening.

 

This StackOverflow post covers the problem and describes how to un-flag the files:

https://stackoverflow.com/questions/15238714/net-local-assembly-load-failed-with-cas-policy

 

Once we did that, our tools loaded and displayed in Alteryx Designer as expected.  Whew!

Alteryx Partner

@tlarsen7572 You mention creating a YXI file with the config, which sounds grand, but were you able to put something in the package config that meant that it knew what to do with any DLLs involved? i.e. put them in the bin/plugins folder. We ended up creating a custom installer because of that, but would love to go the YXI route instead.

I have not explored that.  For now, my distribution process for custom .NET tools requires manually copying the DLL(s) to the bin/plugins folder.  From what I know, a custom installer would be required.