Elevator Pitch
Using external .NET SDKs from NuGet or elsewhere can provide some big benefits when working in PowerShell, as well as introduce some new pain points. This session covers tips, tricks, and how to avoid some of the “gotchas” while working with .NET from PowerShell.
Description
When you are approaching new problems with PowerShell, it can be commonplace to find answers that cover how to solve it in C#/.NET, but not necessarily PowerShell. You may be trying to improve file enumeration and start to see references to AlphaFS or writing an automation process for a hosted service who doesn’t have a very intuitive REST API, but does offer a .NET SDK. If you are not coming from a typical software development background, some of the references and troubleshooting methods can seem incredibly foreign.
This session will focus on:
- Why leveraging available .NET SDKs can offer immediate benefits to your tasks at hand
- Finding packages you need on NuGet as well as resolving package dependencies
- Adding external assemblies to your PowerShell session safely
- Demystifying OverloadDefinitions
- Common headaches from working PowerShell code with .NET SDKs and how to avoid them
Notes
Throughout my experience as a PowerShell module developer, I’ve worked with a number of external .NET SDKs to solve problems. I’ve integrated multiple Google SDKs for PSGSuite, some of the AWS SDKs for VaporShell, written my own class libraries for tools like PEMEncrypt to pair with external SDKs like BouncyCastle, and more. I do not come from a typical software development background myself, so there were a large amount of stumbling points along the way. With this session, I hope to answer some questions that I wish I knew the answer to when I was first going through this.