Body:
Well, looks like I’m finally biting the bullet and jumping into PowerShell. I’ve not had much use for it in the past because none of my previous clients requirements necessitated the use of PowerShell, however I am working on a new project that I believe PowerShell is a great answer for.
Basically, I need to create a site, a few lists, and populate a document library with a few files to create the framework for my application. I was going to (and had actually already started) to deploy a solution as a feature, and when the the feature was activated create the site and all it’s artifacts. I’ve done it before and it works great. So, why change to PowerShell you might ask? Well, let’s pretend you did ask or the blog would end now and you could get back to your life. So, great question, thanks for asking. I was mulling through some design best practices for my solution and asked the question on Twitter about some options for adding files that were part of a solution to a document library. Well, my buddy Alistair Pugin (@AlistairPugin), who talks kinda funny because he’s from South Africa but that’s another story, suggested that I use PowerShell for my task.
PowerShell?? I asked? Isn’t that Black Magic and Witchcraft used for wannabe devs like Todd Klindt (@ToddKlindt)? I initially scoffed at the notion and went along my merry way…
But then I began to think. Instead of asking “Why PowerShell?” I asked “Why a feature?” Why go to the effort to deploy a solution to the farm that in theory is only activated once and in this case maybe only on one Site Collection? I mean, every update of the feature would require un-deploying the old solution and redeploying the new one. Plus, I’d have to take into account the brilliant user poking around who decided to deactivate and reactive the feature… I’d have to make it idiot proof…
HOWEVER, if I used a PowerShell script I could run the entire script, or just parts of it without having to deploy a thing. I could easily tweak the script and run it again. I don’t have to worry about idiot users playing with it. If I need to change any of the list names, urls, fields, etc. I don’t have to worry about a config file or recompiling, I just change the script and VIOLA…
Maybe Alistair is on to something. So, I’m now undertaking the journey undertaken by many of my colleagues who’s shoulders I will stand on to figure out my issues and look like an expert. So, thanks in advance guys. If I run across any quirks or issues I’ll be sure to blog about it as well.
You are probably asking yourself what the point of me blogging about all of this is?? Well, in the end, this blog is 99% just a bookmark for me so I can easily find the great blog post by Scot Hillier walking you through the process of setting up PowerShell ISE for SharePoint 2010.
Setting up PowerShell ISE for SharePoint 2010
Apparently you have to actually install the SharePoint Snap-In before you can really do anything with SharePoint… It’s not just there automatically…
Last bit of advice I’ll give you is make sure you run the 64 bit version of PowerShell ISE… I was the idiot who spent an hour today trying to figure out why I could not get the SharePoint Snap-In to load before realizing I was running the 32 bit version of PowerShell ISE. Brilliant I am I tell ya…
For anyone else banging their head against the wall, if you get the following error you maybe accidentally running the 32 big version as well:
Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version 2.
At C:\Windows\SysWOW64\WindowsPowerShell\v1.0\profile.ps1:2 char:15
+ { Add-PSSnapIn <<<< -Name Microsoft.SharePoint.PowerShell }
+ CategoryInfo : InvalidArgument: (Microsoft.SharePoint.PowerShell:String) [Add-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.AddPSSnapinCommand
Thanks @ferringer for not laughing at me too hard…
That’s it, short and sweet, and remember, in the immortal words of Brian T. Jackett (@BrianTJackett) “PowerShell makes you a better person.”
It’s about time I started.