topic Using Data ONTAP PowerShell Toolkit objects in C# Managed Code in Microsoft Virtualization Discussions

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

tom_maher — Thu, 05 Jun 2025 06:46:54 GMT

Hi,

Apologies if this question isn't appropriate to this forum as the problem may be more my lack of .Net knowledge than anything else but I'm trying to use the DataONTAP powershell module from within a C# windows application I'm writing to automate/simplify some operational checks we currently run manually (snapmirror lags, snapshot space, vol usage, etc).

I'm trying (for example) to connect to a controller (using the Connect-NaController cmdlet) and return it as an NetApp.Ontapi.Filer.NaController object. In previous powershell scripts we've produced we've done wrapped that in a function, called it at the start of the script and used the resultant $filer variable as the -Controller parameter when calling subsequent cmdlets like Get-NaSnapmirror, GetNaVol, etc.

#Connects to and returns a NetApp Filer controller object

function ConnectNAFiler($filerfqdn)

{

try

{

$filer = Connect-NaController $filerfqdn -ErrorAction "stop"

$filername = $filer.Name

$filerport = $filer.Port

$filerprot = $filer.Protocol

Write-Log "Successfully connected to $filername`:$filerport via $filerprot"

}

catch

{

Write-Log "Unable to connect to $filerfqdn - Exiting"

CleanUp

Write-Log "### Exiting $me ###"

break

}

return $filer

}

In my limited grasp of C# I go add the DataONTAP module to my session, create a runspace, invoke Connect-NaController and see that I get back a PSObject with a base type of [0] = "NetApp.Ontapi.Filer.NaController" and I can enumerate properties just as I would in PS. My stumbling block from here is how would I use that object in subsequent cmdlets later in the managed code? Can I just store it somewhere and append as a parameter as in PS?

class DataONTAP
{

public static void ConnectNAFiler()
{

            InitialSessionState initialSession = InitialSessionState.CreateDefault();
            initialSession.ImportPSModule(new[] { "DataONTAP" });
            Runspace runspace = RunspaceFactory.CreateRunspace(initialSession);
            runspace.Open();
            RunspaceInvoke invoker = new RunspaceInvoke(runspace);
            Collection<PSObject> results = invoker.Invoke("Connect-NaController myfiler");

            foreach (PSObject ps in results)
            {
                Debug.WriteLine(ps.Properties["name"].Value);
                Debug.WriteLine(ps.Properties["port"].Value);
                Debug.WriteLine(ps.Properties["protocol"].Value);
                Debug.WriteLine(ps.Properties["version"].Value);
            }

        }
    }

Is this even worthwhile? I've seen some great examples in the manageability SDK to using the APIs to do this kind of thing but we'd like to go down the "C# managed PS" route to 1) preserve our investment in what we've done in PS and 2) we're hearing that stuff like the Exchange 2010 tools and the AD Admin Center are just wrappers for PS code.

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

cknight — Tue, 06 Sep 2011 13:53:21 GMT

Hi, Tom. When you invoke Connect-NaController and the login succeeds, the NaController instance is stored in $global:CurrentNaController, so as long as you continue using the same runspace, subsequent cmdlets should use that. Most Toolkit cmdlets also provide a -Controller parameter, so you can explicitly provide the controller instance (such as when looping through a list of controllers). Either way, you should be able to use the Toolkit from C# as you are doing.

And yes, it's worthwhile. Microsoft suggests writing new management applications in PowerShell and then invoking that functionality from the UI layer. That guarantees separability so one may test the UI apart from the underlying functions. And the resulting product is then fully accessible from PowerShell scripts, so your users can script your application in ways you probably haven't even considered.

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

tom_maher — Wed, 07 Sep 2011 09:27:18 GMT

Hi Clinton and thank you for taking the time to address my post. I'd completely forgotten the NaController gets set globally.

Where you say "Microsoft suggests..." is there any public visibility of this? I only ask as I'm finding resource on MSDN & Technet pretty scarce.

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

cknight — Wed, 07 Sep 2011 18:43:16 GMT

Tom, my comments regarding PowerShell are based on my attendance at several conferences the last few years. I had the opportunity to meet with PowerShell inventor Jeffrey Snover and his team on each of those occasions, and their message was consistent: invest in PowerShell, build new applications on top of it, and that investment will pay off in spades. Now that Snover is lead architect of Windows Server, I'd say he is well positioned to keep that promise.

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

jausch — Wed, 07 Sep 2011 19:51:46 GMT

If you look carefully, MSFT is using this strategy in their own tools. Exchange was the leader here but all other MSFT management tools are headed this way.

PowerShell support is mandated as part of Microsoft's Common Engineering Criteria (CEC) which is public: http://www.microsoft.com/cec/en/us/default.aspx

Alex

Using Data ONTAP PowerShell Toolkit objects in C# Managed Code

tom_maher — Thu, 08 Sep 2011 08:04:08 GMT

Thank you very much for the feedback guys.

Clinton, I first came across Mr Snover's name on a blog post extolling (ironically enough) the DataONTAP module which led us to other blog posts that suggest using WPF to lay out your GUI over pure PS and that's more or less led us to where we think we want to be.

Alex, thank you very much for the link to the CEC - that's exactly what I was after to formally justify adopting managed PS.

Thanks again.