Just some minor fixes, and the obvious API changes needed to be RC1 compatible. Source has been pushed the the MSH Community Extensions Workspace. For those of you who just want to play, you can get the latest binary at the bottom of this entry. Installation has changed slightly:

PS c:\temp> InstallUtil Nivot.PowerShell.SharePoint.dll
...
PS c:\temp> Add-PSSnapin Nivot.PowerShell.SharePoint
PS c:\temp> New-PSDrive wss SharePoint http://mywss/
PS c:\temp> cd wss:
PS wss:\>

Apart from some minor refactoring, I've added some more actions to allow copy/move/delete between users/roles/groups and webs. Here's an example of how easy it is to define the operations for adding and removing users to a SPWeb using my generics-based provider model:

// remove SPUser
RegisterRemover<SPUser>(
    new Action<IStoreItem>(
        delegate(IStoreItem item) {
            SPUser user = (SPUser)item.NativeObject;
            NativeObject.Users.Remove(user.LoginName);
        }
    )
);

The above code allows the following to work:

   PS wss:\subweb> copy ..\!roles\contributor\username .

where . represents wss:\subweb, an SPWeb object.

Have fun!

Build RC1 Only, NOT RC1 Refresh -- for latest version see homepage 
Download: Nivot.PowerShell.SharePoint-0.51.zip (40.94 KB)

(edit: minor bug found -- v0.51 update)

Well, one sign that we're close to a release -- they've let the marketing monkeys out of their boxes for the day. What's the first stinky poop thrown from the cage? the name change: "powershell." I find all this kind of self-congratulatory naming very indulgent or something. I imagine the ultimate extension of this to be renaming a country to "WE ROCK."

I find it hard to believe that the richest company in the world can send a dozen highly paid marketeers into a room with their free soda and the best they can come up with is the "power" prefix. Anyhow, perhaps it fits in with the "powertoys" brand or something. Another thing that makes it seem a bad choice is that there are already several "powershell" products out there in the world. Not to mention "powerdiets," "powershoes," and no doubt several varieties of "power-pants."

Man, I'm spending too much time on this non-issue already. I'm starting to feel psychotic... go grab yerselves a new shell already.

http://www.microsoft.com/downloads/results.aspx?freetext=powershell&DisplayLang=en

I wish I could say I'm busy working on my SharePoint provider, but eh, no. I'm currently embroiled in the living hell that is house hunting: mortages, loans, notaries, agents and other such savagery. Why can't I just buy the friggin' thing on eBay? Oh yeah, just remembered why: you would pay $400,000; get hit by PayPal for $50,000; it would be the wrong colour; it would be late; the seller would insist on you paying via Western Union before shipping you a garden shed. etc etc.

...released to GotDotNet's MSH Community Extensions run by Monad MVP Blogger, Keith Hill.

So, another drop for you today:

Update April 8th: for latest version -- see home page http://www.nivot.org/

This was a lot of pain; but through a combination of Lutz Roeder's Reflector, MDBG and tinkering, I've got a functioning NavigableCmdletProvider derived SharePoint provider working:

• only supports Drive-Qualified operation at the moment
• no support for copy,delete or move, yet.
• each web exposes pseudo container paths of !Alerts, !Groups, !Lists, !Roles, !Users
• no format-types xml included yet, so directory display is a little messy

This initial release only supports running on the same server as sharepoint, meaning you'll need to install 2.0 framework and Monad 3.1 onto your sharepoint box. Just extract the DLL and run the following commands to get started:

MSH C:\Monad\Snapins> c:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe MshSharePointProviderSnapin.dll
...
MSH C:\Monad\Snapins> add-mshsnapin nivot.monad.providers
MSH C:\Monad\Snapins> new-drive wss sharepoint http://wss.server.com
MSH C:\Monad\Snapins> cd wss:
MSH wss:\>

So, from here you can use cd or set-location and hit tab to cycle through the pseudo containers and subwebs. Once inside, e.g. wss:\subsite\!roles, you can type dir to enumerate all SPRole items. Alerts, Groups, Lists, Roles and Users are treated as containers. Alert, Group, List, Role and User are leaf nodes. I'm extending this to treat a List and a User as a container too to expose their collections (List.Items) and (User.Alerts) as further containers. Currently, only simple paths are supported, some examples:

\!alerts\alerttitle
\subweb\!roles
\subweb\!users\username
\subweb\subweb2\

Complex nested paths will be in the next release, e.g.

\subweb\!users\username\!alerts\alerttitle

Currently, it does support not SPS; you can map a drive to the root of a portal, but you will experience some weird behaviour. I plan to incorporate support for that in the future.

The next release will support copy, move and delete semantics between containers. It will also support complex paths. Post any ideas, feature requests and/or anything you feel might a bug or just done wrong. I'm working on a list of concrete features for my next post.

Have fun!

( for latest version, see homepage )

For me, the Microsoft Command Shell (MSH) has to be the most exciting thing to come out of Microsoft for years; yes, I'm a command line whore, but proud of it. In the *nix world I used ksh and when I ended up working a lot with DOS, 4DOS was my trusty companion. Up until recently 4DOS's 32bit successor, 4NT, was my main workhorse in the nt4/2000/xp world, but it's slowly losing ground now to MSH.

I've been working a lot with SharePoint Products & Technologies 2003 the last few years, and I've increasingly found myself writing little c# console apps to perform menial work like batch uploads into lists, mass user management/migrating, site cloning etc. I actually started to sit down and write a shell which was christened SPSH (pronounced speh-shell -- e.g. special, geddit!) which was going to work like NETSH with command contexts etc; NETSH is pretty nice, it feels like very much like IOS. Then I discovered MSH and the Cmdlet Provider model and I saw the light

So, I'm announcing my work on a SharePointProvider which I expect to have ready in about 6 weeks from now in it's first release form. I'm about 2 weeks into it now. Incidentally, since I'm developing it with the unbelievably cool -- and free -- Visual Studio Express, I've entered the project for the "Made in Express" Contest. It'd be nice to get the $10k, but I'm doing this for fun already and to help ease my workload (and yours too if you decide to use it). Imagine being able to do this:

MSH C:\monad\snapins> new-drive wss sharepoint http://intranet

Name       Provider      Root                    CurrentLocation
----       --------      ----                    ---------------
wss        nivot.mona... http://intranet

MSH C:\monad\snapins> cd wss:
MSH wss:\> cd subsite\!Users
MSH wss:\subsite\!Users> copy * ..\!roles\contributor

Anyhow, the list of things you can do is endless once the provider is in place. Check all users in a site collection against AD to see if they locked out their accounts? easy. Copy users from one site to another? easy. Downgrade all contributors from a particular domain to reader? easy.

Also, you'll be able to copy files from one document library to another while preserving metadata, optionally creating the source schema in the destination if the document libraries do not match.

And finally, if you don't want to wait for me before you get scripting SharePoint, take this in:

MSH c:\monad> [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")

GAC    Version        Location
---    -------        --------
True   v1.1.4322      C:\WINDOWS\assembly\GAC\Microsoft.SharePoint\11.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.dll

MSH c:\monad> $site = new-object Microsoft.SharePoint.SPSite("http://intranet")
MSH c:\monad> $site.ID.toString()
d5dfb76b-fd15-4666-b9f1-93f2ae617086

Exciting times!