Setting item level permissions was straight forward in SharePoint 2010, you selected the items you wanted to break inheritance on and selected the Permissions item. When moving to SharePoint 2013 and trying to do the same thing, to a lot of users this functionality appears to no longer exist. Worry not!
To set item level permissions for an item (or multiple items) select the candidate items and switch to the Items tab in the ribbon.
Notice the ribbon item called Shared With. This is what replaces the Permissions item from 2010. Click it and a list of users that the item is shared with loads.
SharePoint Short #21
A quick short today 🙂
Instead of adding new fields to a content type or list creating the object (SPFieldText, etc.) and adding it, simply pass the XML definition for whatever field you are looking to create into the AddFieldAsXml method of the Fields collection.
public void AddFieldToList(SPList list, string xmlDefinition)
string fieldName = list.Fields.AddFieldAsXml(xmlDefinition);
SPField newField = list.Fields.GetField(fieldName);
// Do whatever you need to with the new field
// and then update it.
The xmlDefinition is simply a copy of the Field tag, for example from a content type definition.
A quick post today, just to say that there’s been an update to the ULS Viewer from Microsoft. A big improvement, main features are now:
- Monitor all server logs in real time across the farm
- Personalise the output and and colour code specific entries
- Command line tool
All good and well worth downloading. Get it from here.
I recently came across the following whitepaper for configuring SQL Server to get the best performance from it when used in a SharePoint environment.
Download it from here
Or view it from here
Lots of good information in it and well worth keeping to refer to when building SharePoint environments 🙂
Creating a SharePoint package is easy enough with Visual Studio but each time you restart it, the package location used previously is replaced with the default location of the current user’s Documents folder.
To save a few seconds from my life I decided to write a PowerShell script to build and package the solution, meaning I no longer have to specify the publish location whenever Visual Studio is restarted.
I’m using Visual Studio 2013 and SharePoint 2013
& "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild.exe" "C:\Projects\TestProject\TestSolution.csproj" /t:rebuild;package
Write-Host "Copying TestSolution.wsp to Packages folder" -NoNewLine
Copy-Item -Confirm:$false "C:\Projects\TestProject\bin\Debug\TestSolution.wsp" C:\Packages\
Write-Host " - done."
The script shown has been simplified for this post and is easy enough to parametrise to allow you to specify different SharePoint projects to package.
Anyway, back to the main reason for this post.
After doing the above and running the script the following error was generated:
C:\Projects\TestProject\TestSolution.csproj(88,3): error MSB4019: The imported project “C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools\Microsoft.VisualStudio.SharePoint.targets” was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.