On the MSDN forums I answered a blog posting about how to update some values of a user profile.  I’ve answered this question more than a few times so I threw up this posting about it.

Here is some basic code to achieve this (its actually from MSDN but I’ve written the same code enough times just couldn’t find it offhand)

using (SPSite site = new SPSite("http://servername"))
{
    ServerContext context = ServerContext.GetContext(site);
    UserProfileManager profileManager = new UserProfileManager(context);
    string sAccount = "domainname\\username";
    UserProfile u = profileManager.GetUserProfile(sAccount);
    u[PropertyConstants.PictureURL].Value = "SOME URL";
    u.Commit();
}

 

 

Be sure to check out MSDN for the members of the PropertyConstants.


Tony Testa posted on March 4, 2009 18:30

I guess I can say that I was blessed and cursed all at the same time when it comes to work.  I was luck enough to be a consultant working on billable projects up until now, and not just 1 project but typically 2-3 at a time.  Finally it looks like I have a few weeks here to be only on 1 project and one that is easy and something I can tap on old resources and knowledge I've accumulated over the years.  That being said it means I now have a bunch of backlogged blog postings that i’ve been meaning to put up for everyone to hopefully save someone some headaches.

Upcoming postings:

  • Fix for errors that SharePoint throws regarding SharePoint’s licensed being “expired”
  • Ideas for how to programmatically create sites and assign permissions and issues related with the process
  • Workflow emails not being sent; what to look for, what to make sure is there in the first place
  • Using PSTOOLS to make managing a SharePoint farm easier
  • How to parse SharePoint IIS logs
  • Basic SharePoint troubleshooting techniques
  • SharePoint “terms of use” page
  • SharePoint Dev. tools you should be already using
  • SharePoint Web Service Gotchas
  • Why NOT to use server names when dealing with SharePoint
  • HowTo: Silverlight and SharePoint integration: Basic steps to get started
  • Programmatically set Search results page

 

Obviously from the list above I have a lot I’ve promised and a lot of live up to but I can assure you these have all been in the works for awhile so 90% of the work is done.  More to come…


Posted in: Sharepoint  Tags: , ,

Today while helping a colleague with a SharePoint solution I remembered about URL tokens that SharePoint can use.  I swore for the life of me that I had blogged about them but apparently I didn’t.  On that note…here it is.

To get straight to the point, SharePoint has certain URL tokens that it will read from a URL and in its processing, translate into the actual values.  According to the article on How to: Add Actions to the User Interface, the following tokens exist:

Windows SharePoint Services supports the following tokens with which to start a relative URL:

~site - Web site (SPWeb) relative link.

~sitecollection - site collection (SPSite) relative link.

In addition, you can use the following tokens within a URL:

{ItemId} - Integer ID that represents the item within a list.

{ItemUrl} - URL of the item being acted upon. Only work for documents in libraries. [Not functional in Beta 2]

{ListId} - GUID that represents the list.

{SiteUrl} - URL of the Web site (SPWeb).

{RecurrenceId} - Recurrence index. This token is not supported for use in the context menus of list items.

If you search the web for “SharePoint URL Tokens” you’ll find the same copied list.  The one thing that you won’t find most likely is the following article by Stefan Gobner, Stefan Gobners URL Tokens Posting.  Stefan is a MS Support Engineer which means that he works through these weird issues on a daily basis and he blogged about a few extra URL tokens/Querystring parameters that shouldn’t be used in your URLs.  According to Stefan, the following parameter names shouldn’t be used:

  • FeatureId
  • ListTemplate
  • List
  • ID
  • VersionNo
  • ContentTypeId
  • RootFolder
  • View
  • FolderCTID
  • Mode
  • Type

Luckily none of these stumped me in the past but certainly a few times I recall naming some “random” query string parameters and knowing that these “shouldn’t” be used would have been helpful.

(03/06/2009 UPDATE) A colleague of mine just mentioned I should add:

  • k

Reason for not using k is because the search queries use that.  I am going to navigate a sharepoint site in my sparetime and look for additional ones as well because I know search uses a few more as well.


Any SharePoint developer with about a days worth of SharePoint development knowledge tends to find out that you need to dispose of the SPWeb and SPSite objects.  Of course this is further conveluded by the fact that this isn't ALWAYS the case depending on whether your a webpart or not, context, etc. etc.

I was answering a few forum postings this evening when someone asked the question again, whether or not they should dispose something in a certain case. I think I sufficiently answered their post on the MSDN forum.

I thought that I would share the info again though on my site so that I can easily link to it later.

Roger Lambs SPWeb/SPSite dispose write up
Roger Lambs SPWeb/SPSite dispose when using try/finally blocks
Steve Gossner's SPWeb/SPSite dispose write up has some good tidbits about other objects that need disposing
MSDN's SPWeb/SPSite dispose write up

In addition MS is coming out with a tool that is basically like FxCop that will check for SPWeb/SPSite objects, but its not out yet. MS SharePoint Team Blog  word on the street is that its coming out very soon.

The tricky thing that most of the articles don't really discuss that much, is when you use statements like"item.ParentList.ParentWeb.RoleDefinitions" that it technically creates an SPWeb object in your method when you call the ParentWeb. You therefore should probably break that line out to something like


using(SPWeb parent = item.ParentList.ParentWeb)

{

//your code here

}


I presented on MOSS Search at the Philly Dot Net Code Camp 2008.3 yesterday and once again it went well.  This was the largest code camp to date and it seems like they just keep growing and growing in size. 

I gave this presentation for the first time a few months back at the Philly Office Geeks user group meeting and noticed that I went into too much detail in certain areas and skipped over other areas.  This time I focused a bit more on content sources and scopes since they are the heart of SharePoint search.  I think that it still needs a few more touches before I give this presentation again. 

There was also an "Ask the Panel of Experts" session that I think went pretty well.  Honestly, not a whole lot of questions were answered during the session but there was a whole lot of lively debate that now that I think about it, shows a few things.  First, SharePoint is a huge product and one can easily focus on one area and making a good living doing nothing but that.  Second, Bill Wolf made this point and I think its worth mentioning.  If you look at what SharePoint 2007 is built on top of today, its pretty safe to assume what the next version of SharePoint will be built on top of.  That being said, really learn SQL Server 2008, .NET 4.0, and most likely Silverlight.

 

As promised during the session, here are my slides and code samples that I used.

20081011_CodeCamp_Moss_Search.zip


Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017 Tony Testa's World