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
Write-Log "Successfully connected to $filername`:$filerport via $filerprot"
Write-Log "Unable to connect to $filerfqdn - Exiting"
Write-Log "### Exiting $me ###"
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  = "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?
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.
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.
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.
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.