If you’re trying to do this from Server 2008 R2 you’ll need to do a simple piece of config first; Simply go and add the Desktop Experience Feature and reboot your server!

A nice and easy fix

Also make sure you use the http:// path and not the file:// path that you’ll get with right click > copy shortcut

1) Download and install http://www.microsoft.com/web/downloads/platform.aspx (you should probably do this for all development environments anyway)

2) Launch the Web Platform Installer and search for SharePoint

3) Add install the latest version of the “”Microsoft Office Developer Tools for Visual Studio 2012” (currently it’s Preview 2)

There are plenty of great articles on waiting for or getting user input, personally I really like Windows PowerShell Tip of the Week: Pausing a Script Until the User Presses a Key and the User Interaction chapter from the PowerShell Cookbook. After seeing that [Console]::ReadKey() would give me an object which told me about the modifers on the key press (Crtl, Alt and/or Shift) I started thinking about making that key press more specific, say Ctrl + G, so I wrote a function to handle this:

function Pause
{
	param([string] $pauseKey,
			[ConsoleModifiers] $modifier,
			[string] $prompt,
			[bool] $hideKeysStrokes)
			
    Write-Host -NoNewLine "Press $prompt to continue . . . "
    do
	{
		$key = [Console]::ReadKey($hideKeysStrokes)
	} 
	while(($key.Key -ne $pauseKey) -or ($key.Modifiers -ne $modifer))	
	
    Write-Host
}

This function received a bit of inspiration from How to Properly Pause a PowerShell Script which itself is pretty interesting.

Things to note:

Ctrl + C will still cancel the script, you’ll need to use $host.UI.RawUI.ReadKey with the AllowCtrlC option to prevent that, but then accessing the Modifiers is done differently.

$modifers is a simple enum value of ConsoleModifiers if you want to do combinations like Atl+Shift you’ll pass a collection of modifers and do –band operations to see if your conditions are met.

To call the Pause function use something like this:

$modifer = [ConsoleModifiers]::Control
Pause "G" $modifer "Ctrl + G" $true  

And then you’ll see this:

A couple of weeks ago I got one of the coolest emails I’ve received in my professional career, it read:

Dear Gavin Barron,
Congratulations! We are pleased to present you with the 2012 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in SharePoint Server technical communities during the past year.

I’m really happy receive this honour! I’d really like to thank everyone at Intergen for the support they’ve provided over the years and for an environment where community involvement is encouraged. I’d like to personally call out Chris, Chan, Debbie, OJ and Brendan for their personal support and help since I first got involved with this crazy SharePoint thing.

It’s been a heck of a ride so far and with the public preview of Office 2013 announced this morning I’m looking forward to the next few months.

-Gavin

I was horrified to see all those extra spaces there!!! Now this Visual Studio 2010 instance is just running the default setup with the productivity tools installed (Oh and I hit Ctrl+R, Ctrl+W to show the whitespace characters used)

That’s an 81KB XML file!

Now I’m a believer in tabs over spaces and full tab sized indents in all cases, to me it’s cleaner and reduces page weight.

So, open up Visual Studios options, Tools > Options and go to Text Editor > All Languages > Tabs. For me this is what I found….

Settings that were not consistent across all the file types and Spaces used as indents! Grrrr!!!!! So, a quick change of settings:

A quick Ctrl+A, Ctrl+K, Ctrl+F to re-format the file and things looks much tidier:

The file size came down to 80KB, so about a 1.25% savings, not a huge amount, but if you think about that over all of the code sitting in source control for a development company like ours that’s likely to be gigabytes worth of savings. Plus the double space in the file stood out nice and clearly!

Now that the preferences for VS are ‘fixed’ all of the files will get the ugly space based whitespace removed as they get worked on.

-Gavin

Ok, you’re back and have read all those? Great! I’ve got a few more for you.

1. Shared Fields are push down only:

   If you go into a document within a document and edit a property which is set as a shared property for the Document Set that change does not get propagated to the either the containing Document Set or to other documents within the set. If you need to change these across the entire Document Set you must make the change to the Document Set itself and then SharePoint will propagate these changes down.

2. Versions have to be declared:

   Despite the fact that a Document Set itself can have metadata which users change there is no automatic tracking of changes made. You must use the Capture Version functionality manually to record changes made against the metadata at a Document Set level.

3. No Check-In/Check-Out functionality:

   The notion of check-in/check-out does not apply to Document Sets. This kind of makes sense when you consider that they are just special folders and a check-out at the folder level would imply that they user had also checked out all child documents. But it’s a little annoying, especially as there is metadata against the Document Set which users can freely edit with no automatic version history captured.

Note the missing padlock icons on some files. The files missing the padlock were retrieved on my last Get Latest operation.

To ensure that Visual Studio treats these correctly and enforces source control behaviour you have to refresh the source control connection. Ensure that you select the solution file, to refresh all projects, or just a single project to target the refresh at just that project. Then select File > Source Control > Refresh Status or Alt + F, Alt + R, Alt + T for you keyboard jockeys out there.

Lo and behold, padlocks are present and source control behaviour is correct!

I’d been using this code to create my document sets:

/*
Broken but sort of works
*/
public static void GenerateNewApplicationDocumentSet(string applicationNumber, SPList targetLibrary, SPWeb web)
{
	if (applicationNumber == null) throw new ArgumentNullException("applicationNumber");
	if (targetLibrary == null) throw new ArgumentNullException("targetLibrary");
	if (web == null) throw new ArgumentNullException("web");
	//You can use a hashtable to populate properties of the document set
	var docsetProperties = new Hashtable {{"Name", applicationNumber}};
	var documentSetContentType = web.ContentTypes[ContentTypeNames.ApplicationDocumentSet];
	documentSet = DocumentSet.Create(targetLibrary.RootFolder,
                                                    	applicationNumber,
                                                    	documentSetContentType.Id,
                                                    	docsetProperties,
                                                    	true);
}

Creating my Document Sets via the UI worked fine and gave me the right icon and a link to my Welcome Page. I was well puzzled. After a bit of head scratching and getting back to SharePoint basics I realised my mistake. I was creating an instance of the Documents Set Content Type that was on the SPWeb and not that which was bound to the Document Library.

Once I start using the content type from the library things started working perfectly!

public static void GenerateNewApplicationDocumentSet(string applicationNumber, SPList targetLibrary)
{
	if (applicationNumber == null) throw new ArgumentNullException("applicationNumber");
	if (targetLibrary == null) throw new ArgumentNullException("targetLibrary");
	//You can use a hashtable to populate properties of the document set
	var docsetProperties = new Hashtable {{"Name", applicationNumber}};
	var documentSetContentType = targetLibrary.ContentTypes[ContentTypeNames.ApplicationDocumentSet];
	documentSet = DocumentSet.Create(targetLibrary.RootFolder,
                                                    	applicationNumber,
                                                    	documentSetContentType.Id,
                                                    	docsetProperties,
                                                    	true);
}

Subtle but telling reminder that the content types bound to lists are different from those site wide content types that they inherit from.