Just a quick one for the frustrated searchers out there. If you've recently installed the SP1 beta for Visual Studio 2008 (or just the 3.5 sp1 beta alone), and you find that you have serious difficulty using SharePoint Designer 2007 against a remote instance of SharePoint running in a VM (or a physical machine) that doesn't have the SP1 Beta bits, you know what to do. My SPD would refuse to load the master page from my virtualized SharePoint instance until I had installed .NET 3.5 SP1 Beta onto the virtual machine also. Just so you know!

Discovered while playing around with the new SPUserToken class and associated goodness that is the new impersonation APIs in WSS 3.0 / SPS 2007. from Reflector:

public static void SetApplicationCendentialKey(SecureString password)
{
    SPCredentialManager.CreateApplicationCendentialKey(password);
}

Ouch! how did that get past QA? there are only five methods on the class - looks like it was a late night for whomever wrote these bits. Unless I'm very much mistaken, shouldn't that read Credential?

microsoft.sharepoint.spsecurity.setapplicationcendentialkey

My last post got me thinking about the problems experienced when trying to write culture aware software. Yeah, I know it was actually me that was unaware of the culture, but this time it's about the software end of the deal; in particular, the recently updated Microsoft Business Data Catalog Definition Editor for Microsoft's popular SharePoint 2007 server. If you read some of the comments on the blog, you'll see that various people (using a non US English version of Windows) have installed it and have come across a problem where the tool cannot find the local security group called "Builtin\Users." Oops. In the world of cutting-edge technology, people often install software that doesn't match the installed language of their O/S. The fact of the world is that all major symbolic computer languages are based around English, and the most popular software gets written in English first. Here in Quebec, Canada, French is the primary language with English coming second (Canada is officially bilingual - although most of the country only speaks English). Localization of software takes a fair amount of time. It's not just translating a resources file - there are hot-keys to reassign (the Bold shotcut in French MSWord is CTRL+G for example, bold being Gras in French) dialog boxes to resize, labels and controls to reposition etc. Some languages are more verbose than others and end up with text that won't fit. However, there are things you do to avoid certain problems -- lets take the issue above as an example.

Logins and Group names are just an abstraction in the Windows security subsystem. These things are actually represented by value called a SID ( system.security.principal.securityidentifier ). No matter what version of Windows you use, the SIDs for built-in accounts and groups are the same:

First using an en-US system:

and a French (fr-FR) system:

As you can see, the SID is the same: S-1-5-32-545. An example of this is shown below - a simple If-Elevated function that takes two Scriptblocks: the first is executed if the user is running as an administrator, the second is running if the user is just a plain well, user:

Some weeks ago, I started a new contract for a pretty monstrous MOSS (Microsoft Office SharePoint Server) 2007 project. The thing is, this is my first pure Francophone environment since I first came to Canada four years ago. As the agency is part of the Canadian Government -- and located in Quebec -- most of the software installed is the French version. The keyboards are fr-ca, Windows is French, and yep, SharePoint is installed in French. It's proving quite difficult to find my way around as the translations are not really comparable. Sometimes they are not even close. It's worse though, because a lot of the idioms are France-French, not Quebec-French. As Quebecers (and confused French people) will tell you, it can be quite a different language sometimes.

Today, it got a lot worse.

I found myself having to define a calculated column - that is to say, a cell in a list that performs calculations based on other cells in the row. You've got the usual SUM, AVG etc functions available. Only except this time I don't. After several frustration attempts, I discovered that the scripting language itself has been translated into French. At first my reaction was incredulity - what is the point of that? They don't translate C# for other cultures, so why do that? Surely this kind of functionality is aimed at power users, like Excel users! they don't translate the Excel formulas in other locales of Office?!

Except they do.

Merde.

Someone on the newsgroup ran into an issue whereby a instance of a non CLS Compliant type was fed to PowerShell's default formatter. The type in question had two properties with the same name, but in different casing. I'm pretty much just going to carbon-copy the qestion and answer here as I feel this is worth preserving in the annals of blogdom.

Hi Jerry,

This is a tricky one for people very new to powershell without any real experience of the .NET framework. One of the rules of a so-called "CLS compliant type" (cls = common lanaguage specification) is that you should not expose any public members that only differ in casing. The SPContentDatabase type has two properties, "Id" and "ID." This is perfectly legal in C# since case in important in that language and the compiler sees them as different as chalk and cheese. However, in VB.NET, case is not important and as such it [vb] has no native mechanism to differentiate between the two. The same goes for PowerShell's grammar. So, how do we get around this?

First, you grab a handle to the method directly by asking for it from the Type itself:

PS> $idMethod1 = [Microsoft.SharePoint.Administration.SPContentDatabase].getmethod("get_ID")

and for the second version,

PS> $idMethod2 = [Microsoft.SharePoint.Administration.SPContentDatabase].getmethod("get_Id")

Note the differing case for get_Id and get_ID. Btw, Properties like ID in .NET are actually served by special accessor methods prefixed with get_ and set_, hence the prefixes. Next, you need a way to invoke those methods on the instance itself: this is done by using the Invoke method on the MethodInfo object representing the method itself. You pass the instance to the Invoke method telling it that the method is "instance" (e.g. not static/shared) and "public" and it will call that method for you on the instance, returning the value, if any.

PS> $result = $idMethod1.Invoke($site.ContentDatabase, "instance,public", $null, $null, $null)

I know from the SharePoint documenation, that this property returns a guid. Also, due to another oversight, Posh does not know how to format Guids, so you must call ToString() on the result to get the value back or you'll be greeted by a blank line from powershell's formatter.

PS> $result.ToString()
1ade149d-2049-4668-b555-4b7be9374c65

Bizarrely, these two properties return the same guid, but hey, I'll let someone from the sharepoint team answer that one. Anyway, you should have enough information here to extract the properties that you need.

So, that's the interesting portion out of the way. Another way to do this might be to create a custom view for the SPContentDatabase type omitting the duplicated property and use the Update-FormatData cmdlet to activate it. This may not work though, as the non-cls compliancy issue may rear it's ugly head before posh's formatter gets this far.

Hope this helps,

- Oisin / x0n.

I got tired of typing add-pssnapin blah, especially with Quest's AD snap-in's longer than usual name so I came up with a little script that enumerates registered snap-ins, and lists a simple numbered menu showing those that are not already loaded into memory. You just type the number and hit enter to load it. Enter on an empty line exits the script. Yeah, it's brain-dead, but hey, I think I was brain-dead to continually type long commands in every single session to load stuff  

UPDATE 2007-08-16: I was even more braindead than I realised - I copied up a broken version without the $notloaded array. Ooops. Fixed.

1. write-progress "Enumerating Snapins" "Registered..."
2. $snaps = get-pssnapin -r
3.  
4. write-progress "Enumerating Snapins" "Loaded..."
5. $loaded = get-pssnapin | % {$_.name}
6. $notloaded  = @()
7.  
8. write-progress "Enumerating Snapins" "Complete." -Completed # glitchy
9.  
10. $i = 0; "";
11.  
12. foreach ($snap in $snaps) {
13.         if (-not($loaded -contains $snap.name)) {
14.                 Write-Host -fore cyan -nonewline "${i}) "
15.                 write-host -fore green $snap.name
16.                     $notloaded  += $snap
17.                 $i++
18.         }
19. }
20.  
21. if ($i -eq 0) {
22.         Write-Warning "Any eligible snapins are already loaded."
23.         exit;
24. }
25.  
26. $i--;
27. Write-Host -fore yellow "<enter> to quit"
28.  
29. do {
30.         write-host -nonewline "Load 0 - ${i}: ";
31.         $choice = [console]::readline()
32.         if ($choice -and ($choice -lt 0) -or ($choice -gt $i)) {
33.                 Write-Warning "'${choice}' is out of range!"
34.                 continue;
35.         }
36.         if ($choice) {
37.                 "loading $($notloaded[$choice].name) ..."
38.                 add-pssnapin $notloaded[$choice]
39.         }
40. } while ($choice)

Just pop it into a function or a ps1 script.

You'll notice how when this is run from a clear screen, the progress bar disappears, then suddenly reappears and the first few menu items are hidden. This is a bug in the powershell.exe host. Vote on it here:

https://connect.microsoft.com/feedback/ViewFeedback.aspx?FeedbackID=291380&SiteID=99

I like to see myself as a competent SharePoint developer having worked with it since beta 1 on various large scale projects, but it always bothered me that there were large swathes of it on which I was no expert, primarily due to one thing: CAML. It disgusts me - in fact, my brain downright rejects it. Every time I have to create some markup for a simple SPQuery, I have to look pull out the SDK reference material. CAML for me symbolizes everything bad that came out of the 1998-2001 "XML revolution," where absolutely everything had to be xml/xslt driven, where all wisdom concerning the separation of presentation and data disappeared in a puff of <smoke />.

It's not often that you see a new technology and you just "get it." No thinking required; instant grokkage. I thought I "got" LINQ, but it wasn't until today that I truely got it. So, I'm not sure if this qualifies as a "straw" as per the metaphor used in the title, perhaps a full-on hulking haybale would be more apt. Enter Bart de Smet's savegely impressive LINQ to SharePoint project on CodePlex. No more of the nausea-inducing verbosity that is CAML; just plain old C# 3.0.

So, happy new year everyone (read: both of you reading this blog) -- fyi, there's a powershell v1.0 binary compatible build of my SharePoint PSProvider up on codeplex now. I also filled out the Wiki with some information that was sorely lacking.

http://www.codeplex.com/PSSharePoint

As a sign that I'm trying to ramp up development (especially getting a MOSS 2007 layer working), I've snagged me a spot on the codeplex for this code. Feel free to ask for features, provide ideas, critique whatever on the forums provided. I'm also working on an ArchivePSProvider which will allow navigation of Zip and Tar files as hierarchical stores as well as providing some pipe-friendly cmdlets for tar/gzip/zip, e.g.  get-childitems -inc *.log | out-tar | out-gzip

No changes. Too busy at work. Argh. However, it now works with PS RC2. Argh.

(old binary removed) - latest version always at:
http://www.codeplex.com/PSSharePoint

I'm also trying to finish off zip, gzip, tar and bzip2 cmdlets along with an experimental tar/zip provider. Stay tuned, if you've got nothing better to do and a few months to spare. Honestly though, I hope to finish them before the end of the month. There's a warm bed waiting for them up on the CodePlex I'm told...

Just released SharePoint SDKs; these look quite meaty -- The wss one weights in at nearly 34MB, compressed.

Windows SharePoint Services V3: SDK

This SDK contains conceptual overviews, programming tasks, samples, and references to guide you in developing solutions based on Microsoft® Windows® SharePoint® Services (version 3).
 
SharePoint Server 2007: SDK

The Microsoft Office SharePoint Server 2007 (Beta) SDK contains conceptual overviews, programming tasks, code samples, and references to guide you in developing solutions based on Microsoft® Office SharePoint® Server 2007.
 

Hmm, I just realised that RC1 and RC1 Refresh have different build numbers and are not binary compatible. Here's another drop built for rc1 refresh, 1.0.9567.0:

(old binary removed) - latest version always at:
http://www.codeplex.com/PSSharePoint

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)

...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!