Hi,
The core bundle provides you the interfaces (which we call as Core APIs) to invoke any API on the server (e.g. Data ONTAP). While using the Core APIs, you need to read the API Documentation to understand the structure of input and output parameters and then frame the input element (na_elem) and output element (na_elem) by yourself in order to successfully send appropriate inputs and receive the outputs of an API invocation.
In case of dotnet-bindings, all the APIs have been converted in "class" definitions and the input and output elements of the APIs are defined as the member variables of the corresponding classes. This provides you a completely Object Oriented approach. You can create "Objects" of the APIs and invoke them.
This is the primary difference between the two bundles. With this brief description, I am trying to answer the questions you posted above:
1. What are the recommendations for the usage of these two very different sets of API libraries?
>> In a pure .NET environment, we would recommend using dotnet-bindings as the development activity becomes much easier (particularly if you are using Visual Studio) and less prone to human error. In other cases where you may need a lot of customization with the API structure, you may consider using the core APIs.
2. When using the ontap-<version>.dll .Net Assembly libraries, can the latest version [currently ontap-8-1-1.dll] be used with NetApp filers of running all older versions of Data OnTap, or is it necessary to first identify the target device's version and then use a specific assembly that matches the device's version?
>> Using the latest version should be fine. However, please be aware that higher ONTAP version would contain some APIs (and hence would show up in the namespace) which are not present in the lower ONTAP versions. If you invoke such an APIs on a lower ONTAP version, you will receive "Unable to find API" exception. Similarly, some of the existing APIs may have undergone parameter changes in higher ONTAP versions. However, such instances are minimal.
3. If a mixture of NetApp branded and IBM branded devices are being used, are the API library and/or assembly DLL requirements the same for a particular Data OnTap version regardless of what the vendor/brand name is?
>> Yes, vendor/brand does not affect the API definitions and the assembly DLLs.
4. For the full v5.1 SDK, are there currently any libraries or assemblies that provide high level wrapper functions or classes, or is that type of functionality only present in the zip file that is specifically only for .Net Bindings?
>> High level wrappers are not available in SDK. You need to make individual invocations for each APIs.
5. When using the ontap-<version>.dll .Net Assembly libraries, is the Windows RPC transport available for use in place of HTTP/HTTPS?
>> No, ontap-<version>.dll files support only HTTP and HTTPS transport protocols. Please note that Clustered ONTAP does not support RPC.
6. Regardless of whether the Windows RPC mechanism is being used by unmanaged native C++ code or managed C# .Net code, does it fully honor thread-level impersonation such that the identity specified by the thread-level access-token is used as the identity that is presented to the remote RPC server on the NetApp device?
>> Since managed C# .NET code (part of dotnet-bindings) does not support RPC, this question only pertains to unmanaged native C++ code (part of core NMSDK). I am not sure if I understood this question correctly, but if you are asking if NMSDK libraries are "thread safe", then the answer is - yes. The libraries having "_md" (or "_mdd" for debug version) appended to the files names (e.g. libnetapp_md.lib, libxml_md.lib, etc.) are thread-safe.
Please revert back to us if some of your questions are unanswered or if you have any further queries on this.
Regards,
Sen.