4 Replies Latest reply on Mar 26, 2020 9:08 AM by Wes Hunt

    Using Hyper API with LINQPad

    Wes Hunt

      Trying to get the HyperAPI to work with LINQPad to iterate on code ideas and tool quickly. Had some issues, and thought I'd share the results. You have to do two things to get it to work with LINQPad:

       

      1. HyperAPI requires the native DLL tableauhyperapi.dll to be installed alongside the managed assembly Tableau.HyperAPI.NET.dll.

      Turn off LINQPad assembly reference shadowing (Edit|Preferences|Advanced|Execution|Do not shadow assembly references). This will ensure the assembly you add is not shadow-copied to a location where the assembly can't find the native DLL.

       

      2. By default, the HyperProcess ctor tries to use the application's working directory to output hyper logs and the "database". In LINQPad the working directory defaults to the LINQPad executable location, which is not writable in general (and a bad place to put these things anyway).

      Two options:

        a) simple: set Environment.WorkingDirectory to a writable location at the top of your script.

        b) less hacky: add the following options to the HyperProcess using the undocumented parameters argument:

        new HyperProcess(..., new Dictionary<string, string>() { { "log-dir", @"c:\temp" }, {"database", @"c:\temp\hyper_db_randomstring"} })

       

      It would be helpful if Tableau would allow better control over the native DLL and hyperd process startup. With the previous Extract API, I wrote a C# wrapper around the native DLL using P/Invoke wrappers. in that case, I was able to defer the binding to the native assembly until I could SetDllDirectory() FIRST in the constructor of my wrapper. This allowed end users to direct the wrapper to the location of the native DLL before making the P/Invoke calls that would load and bind to it. I suspect that the API could expose such a parameter as well that could be added to the HyperProcess constructor.

       

      HTH,

      Wes