May 2012 - Posts
I’ve been writing a series of posts about SharePoint development using Visual Studio 11 Beta for a while. Since I have written quite a few posts now, I thought it would be useful to compile all of them here in a list if you want to review what’s new quickly at a glance. Maybe this isn’t everything you need to know but it’s a good start. :)
I’m sure I’ll have a few more posts after too long too. I’ll update this post when that happens. Enjoy Visual Studio 11.
I’ve posted a number of articles about Visual Studio 11 to date and today’s article talks about the new SharePoint Project Item, Site Definition. This is a new SPI available in Visual Studio 11. Previously, you had to create site definitions manually or using the Community Kit for SharePoint. This new template has enough to get you started. Start off by creating a new blank SharePoint project and then add a new item.
Notice how the Add New Item dialog indicates that Site Definitions are available in Farm Solutions only. Once you create the new item, you’ll have three items created for you visible in the Solution Explorer, a default.aspx, onet.xml, and a webtemp_<sitedefinition>.xml.
I won’t go into the details of the specific of what goes into each specific file, since there are many posts out there already covering that. However, I will show you what each file looks like. We’ll start with onet.xml.
Onet.xml controls the features that the site definition automatically activates as well as custom list instances. The files support IntelliSense so that will help you customize the XML as you can see in this example below.
The WebTemp XML file automatically has the name of the site definition appended to it. You can customize this file with multiple configurations as well as change the category. In the example below, notice that the DisplayCategory is set to SharePoint Customization. If you are deploying multiple site definitions be sure and change the ID to avoid conflicts.
The default.aspx file contains a simple placeholder that gets you started. Of course, you will likely want to create custom WebPartZones to allow someone to add web parts to your page.
Once you have made any customizations that you would like, deploy your solution. One thing to remember when deploying site definitions is that an iisreset is required. When I deployed my solution the first time, it did not show up in the New Site list. I deployed the solution again and I could pick it from the list.
Notice that it’s in the SharePoint Custom category. Create your new site and when it is complete, you should have a site definition that looks like the one below.
That’s what you get. It’s nothing fancy but it might save you a few steps the next time you have to deploy a site definition.
One of my most popular posts on DotNetMafia.com is my post on using PowerShell to add and deploy SharePoint solution packages (.wsp files). However, in that post, I never went in detail in deploying sandboxed solutions. Today, I want to talk about that and show you what you need to know. I started by using Visual Studio 11 to build a sandboxed solution using the new Visual Web Part.
To get started with PowerShell, run the SharePoint 2010 Management Console located in your Microsoft SharePoint 2010 Products folder on your start menu. This automatically loads the Microsoft.SharePoint.PowerShell snappin so that we can execute SharePoint commands. To install a solution we will use the Add-SPUserSolution command. It takes two parameters. Specify –literalpath, which is the path to the solution file. One thing that is different is that you must specify the full path to the file for some reason. You then need to specify the URL to the site collection with the –site parameter. Here is an example.
Add-SPUserSolution –LiteralPath c:\code\SandboxedSolutionProject.wsp –Site http://sp2010/sites/sandbox
It looks like this in PowerShell. If it executes successfully, you’ll just be returned to the command prompt.
We can now see our .wsp file in the solution gallery.
We can see the solution package but note that it is not activated. For that, we need Install-SPUserSolution. It’s parameters are similar. We use –Identity with the name of the solution package (minus the path) and the –Site parameter with the URL of the site collection again.
Install-SPUserSolution –Identity SandboxedSolutionProject.wsp –Site http://sp2010/sites/sandbox
Once activated you can confirm it in the solutions gallery. You can now activate features as desired (using PowerShell if you want).
At some point, you might want to remove your solution. We can do that with PowerShell as well. First, we need to deactivate the solution using Uninstall-SPUserSolution. It takes the exact same parameter as Install-SPUserSolution.
Uninstall-SPUserSolution –Identity SandboxedSolutionProject.wsp –Site http://sp2010/sites/sandbox
Many of these commands may prompt you with an “Are you sure?” type prompt. You can skip this prompt by adding a –confirm parameter. Now, the last step is to remove the .wsp file from the solution store. For that, we’ll use Remove-SPUserSolution. It uses the –Identity and –Url parameters like the other commands. Just pass the name of the solution package along with the URL of the site collection.
Remove-SPUserSolution –Identity SandboxedSolutionProject.wsp –Site http://sp2010/sites/sandbox
Now the solution is gone from the Solutions gallery. I like to automate everything that I can so these simple PowerShell commands should help if you are working with sandboxed solutions.
I love me some PowerShell. I use it a lot in the context of SharePoint 2010, but I use it just as much on my own laptop. If you have been administering and configuring SharePoint enough, you have become accustomed to the shape and size of the PowerShell window that you get when you run the SharePoint Management Shell. That’s just the way I prefer things to look when I am in the command prompt now. However, by default, when you run PowerShell in Windows 7, you get this huge window that is just cumbersome.
That’s why I thought I would share these quick configuration settings to make your PowerShell experience in Windows 7 just like in SharePoint. Start by finding PowerShell in the start menu, right click and go to Properties. Jump over the Layout tab and you will find the first settings we need to change.
Let’s compare it to the settings on the SharePoint Management Shell.
From the screenshots, you can tell there are a few differences in the Screen buffer size and the Window Size. Let’s talk about Window size first. Start by reducing the Window size width from 120 to 80. You then want to change the Window size height from 50 to 25. You then want to adjust the Screen buffer size. I set the Width to match with a new value of 80. However, I leave the height at 3000, because having a bigger screen buffer is nice when you want to scroll back and look at something. Here are what my modified settings look like.
Once you’ve changed the layout, you may want to also change the color back to black instead of the Windows 7 default color. That’s easy to do by going to the Colors tab. Just click on the black box with Screen background selected.
That’s all there is to it. Click OK and then open a new PowerShell window. Your new command prompt will look just like the one in SharePoint 2010.
So it’s kind of weird tip for today but I find it useful because I like it when PowerShell looks this way. :) Try it out and see for yourself. You can customize other value as well.
I like blogging about errors and their resolutions. Sometimes the answer is simple, but I think there is a lot of value in posting the details of an error so that users can find answers in the search engines. After doing a My Sites upgrade from SharePoint 2007, you will have a whole heap of user photos that you need to beat into submission. This command goes through all of the existing user photos and creates thumbnails. This is often useful when a user has uploaded a giant image of themselves and you need to fix it. To do this, you may be familiar with the PowerShell command Update-SPProfilePhotoStore. You call it by passing the URL to your My Sites host.
Update-SPProfilePhotoStore http://mysitehosturl
If you don’t have the right permissions, you will find yourself with the following error:
Update-SPProfilePhotoStore : Object reference not set to an instance of an object.
At line:1 char:27
+ Update-SPProfilePhotoStore <<<< -MySiteHostLocation http://mysites
+ CategoryInfo : InvalidData: (Microsoft.Offic...ofilePhotoStore:
SPCmdletUserProfilePhotoStore) [Update-SPProfilePhotoStore], NullReference
Exception
+ FullyQualifiedErrorId : Microsoft.Office.Server.UserProfiles.PowerShell.
SPCmdletUserProfilePhotoStore
Now clearly to you that means you don’t have the right permissions, correct? Of course not. To run this command, you need the permissions as defined in this post on MSDN blogs. Now, you could take the easy way out and just run PowerShell as the farm account. However, I know you know better. Just go set up the right permissions and you’ll be set. The post on MSDN summarizes them as follows:
- Go to Service Applications, select your User Profile Service Application, and then click Permissions. Add your account and check the Full Control checkbox.
- Select the User Profile Service Application, and then click the Administrators button. Add your account there and check the Manage Profiles checkbox and nothing else.
Note that you can add groups on the Administrators section but you can’t on the Permissions section. Once you do that, run PowerShell with the Run as Administrator option and run Update-SPProfile again. It should execute without an object reference error.