SharePoint 2010: Setting custom User Profile properties Gotchas

The Goal

The goal is to create a custom User Profile property and then set and retrieve its value using C#.

The resources

Here’s the best resources on the net for creating, modifying, etc.

The Gotchas

Using the above resources, you can piece together how to programatically create custom user profile properties (and sections), set their value(s), and get their value(s). As a developer, you’ve probably only configured enough of your dev farm to get done what you need to do…which isn’t nearly enough to set the values on a custom user profile property.

What else do you need?

Custom User Profile Properties (and several of the Out of Box ones) depend on a Managed Metadata Service Application being setup and associated with the application you’re working with. This is fairly trivial to setup. Just remember that after you set it up via the UI, you’ll need to start it on the “Manage services on this server” page, and then perform an IIS reset. Forgetting these will keep your Managed Metadata service from working.

Read More >

Jon's General SharePoint 2010 Development Tips

In the time I’ve been doing SharePoint development, and SharePoint 2010 development in particular, I’ve tried to blog about the snags or neat stuff I’ve come across. This post is for all those little pieces of knowledge that come from working with the platform that don’t seem large enough for their own post. If you find it useful, let me know in the comments.

The Very Basics

The better understanding of the following resources you have as a SharePoint developer, the better. These are considered absolute must-knows.

Deploying .WSP solution packages

Don’t use Visual Studio 2010 to do this. ”But Jon! They built it to do that! Why shouldn’t I use it?” There are a few reasons why you shouldn’t use VS to do your deployment. Here are a few I’ve learned:

  • You as a SharePoint developer need to be 100% comfortable with using PowerShell to do your deployments. You shouldn't be using stsadm anymore, and neither should your administrator(s). Learn the commandlets for every part of deployment through using them in your own development environment.
  • Visual Studio 2010 out of the box wants to activate all of your features on every web application in the farm. This isn't how you'll treat your production environment, so don't do it in your dev environment. You can disable this behavior, but then using VS for your deployment doesn't net you much time savings.
  • Bad things happen when developing content types and site columns. From my experience, Visual Studio keeps a connection to your application open to help you with developing content types and site columns - that's cool, but not always the best thing. Whenever you retract your solution, make some changes to content types or site columns and redeploy - you're very likely to end up with Visual Studio telling you that some of those content types and site columns already exist. You can either sort through getting rid of these through powershell/the UI and then continuing to use Visual Studio while trying to make it not have this behavior - or just use PowerShell for your solution/feature deployment and enablement. I chose PowerShell after 2 long days of fighting Visual Studio and haven't looked back (and haven't had the issue either!)

Debugging your deployed code

Deploying with PowerShell now? Good. You still need to debug your code. Here are some gotchas.

  • How to attach the Visual Studio debugger manually: If you're new to SharePoint 2010 and don't know how to debug without letting Visual Studio 2010 manager your deployment - here are the steps to attach the debugger manually:
    • Build and Package your latest solution package using Visual Studio (I use Ctrl + Shit + B to build, and then click Package in the Build menu).
    • Deploy the solution package using PowerShell.
    • Attach the debugger by clicking the "Debug" menu and "Attach to Process". Next make sure the "Show processes from all users" and "Show processes in all sessions" are selected. If you're debugging something running in a web application, select all w3wp processes. If you're debugging feature activation, attach to your powershell process. If you are debugging a timer job, attach to the owstimer.exe process.
    • Set a breakpoint and debug as normal.
  • Debugging Feature Receivers using PowerShell: PowerShell is really slick. It's not your normal commandline though. It acts like a .NET application. That means that the first time it loads a dll to run some code, it keeps it handy in memory and doesn't go and load that dll again. So - if you are testing a feature, checking your results, redeploying your code, and retesting...you're not going to get the results you want. Why? Because the first time you activated your feature and tested, PowerShell cached your code. It didn't reload it for your second test run. The solution? Close the PowerShell window and re-open. Repeat as necessary.
  • Debugging Timer Jobs: This has the same caveat as debugging a feature receiver. OWSTimer will cache your dll the first time it runs any code from it. Need to change something in a timer job and retest? Deploy your solution and then restart the "SharePoint 2010 Timer" service in Server Manager. Reattach your debugger if necessary. Retest.

Writing Console Applications against the SharePoint Object Model

This is a really handy way of proving out some application logic, or when you need to provide a utility to your administrator(s) that would just be too complex and hairy to write using PowerShell.

  • To use the SharePoint Object Model, your Console Application needs to be compiled for x64 processors. Go to your Project Properties, and under the Build tab change the "Platform Target" to x64. This setting is specific to the chosen build configuration (most likely "Debug" for your current app). So - if you change your build configuration to Release, you'll need to set the Platform Target to x64 again.
  • Certain actions in the Object Model require that you have an HttpContext open to the web you're working with. I ran into this when working with the webpart manager for a web. Google should be able to help you with establishing an HttpContext from within your console application.

Provisioning the User Profile Service Application

  • The instructions on MSDN indicate that the service account running this service app should be a local administrator. In my experience, this means the account must be directly in the Administrators group. It's not enough to have it in a security group that is then nested in the Administrators group. If you do this, it will be stuck on "starting".

I’ll add to this as I come across little snippets of knowledge. Have a quick tip for SP2010 to share? Let me know.

Read More >

SharePoint 2010: The web application at ... could not be found. Verify that you have typed the URL correctly.

and so on with the error message. Do these also fit your situation? 1) The error happens when running a console application 2) Using PowerShell works to access the SPSite, SPWeb, or SPWebApplication that you’re accessing in your console application

How do you fix this? Change your build platform target to x64 instead of x86. Also keep in mind that this is a per build configuration setting (so you have the setting for Debug and Release compile modes).

Why did I post this? Because every few months this bites me in some way. Normally for at least an hour at a time. It’s extremely confusing at first and a ‘doh moment when you figure it out.

Read More >

SharePoint 2010: Add a file to the root of your site using PowerShell

This can be useful when you need a file to be right off the root of your Internet facing site - files like robots.txt, sitemap.xml, or the verification file for Google Webmaster tools. We’ll take advantage of PowerShell’s ability to use any .NET methods along with the Files collection on each SPWeb in SharePoint.

[code lang=”ps”] $fileBytes = [system.io.file]::ReadAllBytes("c:\the\full\path\to\your\file.txt"); $site = Get-SPSite "http://yourdomain:portifneeded"; $site.RootWeb.Files.Add("file.txt", $fileBytes, $true); [/code]

This will result in a file.txt located at “http://yourdomain:portifneeded/file.txt”. Sweet!

Read More >

SharePoint 2010: Finding the largest document library in a site collection

SharePoint 2007 came with a page (storman.aspx) dedicated to showing you how much space each of the lists in your site collection were taking up. SharePoint 2010 removed this page. Luckily, SharePoint 2010 SP1 added it back in. But what if you’re still haven’t updated to SP1 and you’re getting warnings/errors about running out of space?

Obviously - up the space so as to avoid additional noise from your users. Then - figure out which libraries are taking up the most space. This can be done by using the (now obsolete - but working) StorageManagementInformation method off of SPSite. You can write some C# to use it, or you can use PowerShell.

The required arguments for this method (listed below) can be found by looking at the above MSDN link. I’ll also include the potential values that can be found by using Reflector to look at the Microsoft.SharePoint dll:

  1. ltVar: What kind of storage management information to display
    • List = 1
    • DocumentLibrary = 2
    • Document = 3
  2. sordVar: the direction in which the items are to be sorted
    • Increasing = 0x10
    • Decreasing = 0x11
  3. soVar: whether the items are sorted by size or by date
    • Size=0
    • Date = 1
  4. nMaxResults: the number of results to return

So if you want to find the top 5 largest document libraries in a specific site collection, here’s the PowerShell: [code lang=”ps”] $site = Get-SPSite "http://yoursitecollection:portifneeded"; $dataTable = $site.StorageManagementInformation(2,0x11,0,5); $dataTable | Select * [/code]

This is very helpful if you aren’t yet on SP2010 SP1. A note though - the method is marked as obselete with this description “SPSite.StorageManagementInformation is expensive; avoid using it.”. There’s no further explanation on what is being spooled up to execute the method or why it was OK in SP2007 but not SP2010. So I’d consider this OK to use if you have to…but not in some kind of recurring scheduled script. Your mileage may vary, I’m not responsible for what happens to your farm, etc. etc.

Hope you found this useful. Let me know!

Read More >

subscribe via RSS