SharePointRoot

I was recently looking into a problem with a Document Information Panel – within Microsoft Word.

There was an error being shown as the document loaded :

Document Information Panel cannot open a new form.
The form cannot be opened. To fix this problem, contact the form designer.
Form template: http://spr/proppanel.xsn
Document Information Panel cannot open the following view: [CONTENT TYPE] Properties – Server
The following view file is not valid: view2.xsl
The .xsl file is not valid XSL.
xsl:choose must have at least one xsl:when child.

Within my SharePoint feature, I was deploying a few custom columns – one of these was a CHOICE field :

<Field ID=”{a75f81c8-a860-4967-996a-0f7941b81119}” Name=”SenderLocation” Group=”SPR Columns” DisplayName=”Sender Location” Type=”Choice” FillInChoice=”TRUE” />

This was intended for a user to add the name of a “Sender Location” – I didn’t actually know the initial choices – so I didn’t include them – but the “FillInChoice” would allow them to add values over time.   

** NB. The fields works OK (in the DIP) if you don’t specify “FillInChoice” (default = false).   The DIP won’t error – just no choices selectable.

Here in lies the issue – related to the fact that you have to specify the choice values.

When you create a field via the User Interface, you get an error – SharePoint Choice fields require at least one choice.

As it turns out, my CHOICE field deployed via ELEMENTS.XML didn’t have any choice values.

Thus – when Microsoft Word was trying to display from this column (within the DIP), it was error’ing.

Simple answer was to make sure it included “at least one” CHOICE value – via the UI – or via my original feature :

<Field ID=”{a75f81c8-a860-4967-996a-0f7941b81119}” Name=”SenderLocation” Group=”SPR Columns” DisplayName=”Sender Location” Type=”Choice” FillInChoice=”TRUE” >
  <CHOICES>
    <CHOICE>OTHER</CHOICE>
  </CHOICES>
</Field>

So, if you have this error, make sure you include some values in the fieldef URL – it makes sense if you think about it. 

NB.  It will only error if/when the field is specified as “FillInChoice = true”

Happy SharePoint’ing !

Further to my previous post about how to determine a “Feature ID” using the developer tools within a web browser, you can do the same for the “Site Templates” – if you’re wanting to automate – and/or refer within PowerShell, or another SharePoint feature.

When you select “New Site”, you’re prompted for the actual Site Template to use – this uses the “Silverlight” control.

BUT – if you navigate to the following URL – you’ll see the standard HTML view – this is the page that is shown when you create a Site Collection without a Site Template type selected.

http://server/_layouts/templatepick.aspx

• Click F12 to open Developer Tools – and then click on the picklist (combo box).

** You might have to click the ‘refresh’ button – after switching tabs – Collaboration, Meetings, Enterprise, etc.

• Check the HTML for the “SELECT” tag – and the various “OPTION” buttons.
• This will give you the NAME+ID of the Site Template.

Eg. This is the “US Asset Operations” Site Template – which can then be used within a script :

{06E52819-0AF2-4162-BB44-221DBA13CC50}#TU_Template_US_Asset_Operations

Nice & easy – hopefully that’s a good tip for someone – I’ll certainly use that in the future…

Recently, I was using some PowerShell scripts to automate the creation of a bunch of Site Collections.  

The script I have goes a little like this :

$template = Get-SPWebTemplate “STS#0″

write-host “Create SC /team/HR”
New-SPSite https://spr/team/HR -Name “Human Resources” -OwnerAlias “SPR\fred” -SecondaryOwnerAlias “SPR\brenda” -ContentDatabase SPR_SQL_TEAMS01 -QuotaTemplate LargeSiteCollection -Language 1033 -template $template

To break this apart – the parameters are :

• URL
• Name = Display Name of the Site Collection
• Owner + Secondary Owner = Site Collection Admins
• ContentDatabase = which SQL DB to use
• QuotaTemplate = define a sizing to the Site Collection
• Language – to use English (1033)
• Template = sourced from the STS#0 template (Team Site)

But – I’m getting an error – which is kinda strange – and resulting in some log-looking…

EVENT LOG :

The site /team/HR could not be created.

The following exception occurred: The system cannot find the file specified. (Exception from HRESULT: 0×80070002).

I re-tried the script – and removed the “-template” parameter – AND – it worked !

When I loaded up the Site Collection – I was prompted to select the Site Collection Template (/_layouts/templatepick.aspx)…

*hhhhmmmm*

RESOLUTION :

When executing the PowerShell command, I was logged in as a Farm Admin – so I have plenty of permissions (god-mode).

HOWEVER – the PowerShell session does not have access to the local File System – and thus cannot read the files (ONET.XML) for the Site Template – aaaahhhaaa !!

The simple answer (facepalm !) is to RUN AS ADMIN when opening the PowerShell command window.

*phew*

Thankfully, that’s ALL it was !

When dealing with PowerShell, it’s often tricky to work out how to get the GUID of a SharePoint feature.

There’s an easy way to grab the GUID – from within the “Site Settings > Site Collection Features” screen.

1. Within Internet Explorer – click F12 for Developer Tools.
2. Click on the ‘arrow’ – and then choose the ‘Activate’ button for the feature you’re checking
3. In the HTML – there is an “ID” value above the button (surrounding DIV) – this is the feature ID !

Just need to click on the GUID – and can do a copy+paste to a PowerShell window.

The following statement will get the details for the feature (just replace with your GUID) :

Get-SPFeature |  Where-Object {$_.Id -eq “[GUID]“}

The above feature is the “Open Documents in Client Applications by Default” feature – I needed the ‘DisplayName’.

This means I can have a script like THIS – this activates the feature for a specific SPSite (Site Collection).

$site = Get-SPSite https://server/site
Enable-SPFeature -Identity “OpenInClient” -Url $site.Url

Very simple solution then – to determine the “DisplayName” of a feature – using the GUID, sourced from the HTML within the page.

Hope this tip is useful to someone out there – has been very helpful for me !

Today was my session at AUSPC – covering some developer level topics – within SharePoint 2013.

The AppModel is a new paradigm – with some changes in perspective – before embarking on a new project.

The agenda for my session was :

• Where have we come from ?
• The new AppModel (SP2013) + Why ?
• New thinking for developers
  • CSOM
  • REST
  • JSON
  • ODATA
  • OAUTH

The changes to application architecture bring some changes & challenges :

• Security – OAUTH
• Code – CSOM + REST
• Data – ODATA + JSON

There were a few demo’s covering each of these– with some code samples – I’ve uploaded these to SkyDrive.

Click here to download the slides/ZIP’s – or you can flip through the deck below :

The other very useful tip/site was the JSON viewer : http://jsonviewer.net

Please let me know if you enjoyed the session – and leave me any questions/comments – cheers !

Within SharePoint 2013, as there was with 2010 & 2007, there are a multitude of GUIDs everywhere – for Sites, Lists, Fields and so forth.

When using these inside a feature, like a custom Content Type and/or Field Ref, it can be a little tricky to determine the GUIDs.

There are a number of places you can grab the URL, and the LIST GUID is within the QueryString – but can be tricky if they are ‘encoded’.

I’ve found a very useful site that does a quick encode/decode – just need to paste in the text.

http://meyerweb.com/eric/tools/dencoder/

Another scenario is within SharePoint Designer, and needing to work with a DataViewWebPart – when you save this out to a .WEBPART, there is a “CDATA” section that is encoded.

Usually (in the past) I’ve had to change the &lt; into <, and the &gt; into >.

But – can now just past the whole slab of text into the “DENCODER”.

Thanks a lot Eric Meyer…!

I’ve been working on a project that deploys a SharePoint “Content Type” – and an associated Document Template – which works nicely…!

I’d changed the template file – and updated within Visual Studio – and then it wasn’t working anymore – what the ??

Failed to instantiate file "_cts/Outgoing Letter/OutgoingDocumentTemplate.docx" from module "Template Outgoing Letter": Source path "Features\xxxxx.Intranet.Correspondence_Content Types\Outgoing Letter\OutgoingDocumentTemplate.docx" not found.

It all looks OK in Visual Studio…>

And – the manifest file is referencing the file…>

The next step was to check the actual WSP…>

• Open Windows Explorer
• Navigate to the BIN folder – and find the WSP that Visual Studio created
• Change the name to CAB – and have a look inside

THAT’S when I noticed the file wasn’t included in the CAB file – and thus not in the WSP !

Aaaah – I know now…>

• Need to ensure that the actual file (DOCX) is included as an “ElementFile”

The default is “NoDeployment” – especially for a DOCX – not normally needed as part of the deployment.

Problem solved – phew !