Remove 32-bit plugin warning with 64-bit Firefox 4/SharePoint 2010

If you are using the 64 bit version of Firefox 4 with SharePoint 2010 you have probably noticed the annoying alert bar at the top of your window that says:

“This page requires a plugin that can only run in 32-bit mode. Restart in 32-bit mode.”

On every. Single. Page. I learned to live with it for a while, but it became really annoying when it would shift the elements on the page a few seconds after load time, sometimes causing me to click the wrong thing. I came up empty handed after searching the internets so I set out into the world of Firefox’s about:config to find a solution.

Here’s how to fix the problem:

Type about:config in your address bar in Firefox. If it’s your first time in here you’ll get a warning to let you know that you could break things. Understand the risks and continue. Next you’re going to want to search this long list of settings for “x86″ and find “dom.ipc.plugins.enabled.x86_64″. Double click this setting to flip the boolean value from “true” to “false”. Now restart your browser and you should no longer see that warning when browsing a SharePoint 2010 site.

I have not noticed anything not working as a result of this change but I’d like to hear if you come across any problems.

Update: I did discover some problems with Flash not being properly displayed on other sites. Since changing the flag described above in the about:config settings and restarting your browser is not something you’ll want to do frequently, check out this post on how to run multiple instances of Firefox: https://devongovett.wordpress.com/2009/04/14/multiple-firefox-mac/

I now have two instances running, one with the x86_64 flag set to true (for general web use) and one with x86_64 flag set to false (for SharePoint 2010).

terminals

I am loving Terminals. Tabbed RDP sessions, RDP profile manager, credential manager and some built in screen capture tool (that I can’t seem to get working). Uses the built-in RDP as the engine and wraps it in a new UI.  It’s good stuff. I’m never opening Microsoft’s Remote Desktop Connection on its own again.

SPDisposeCheck is your friend

.Net has some known issues with garbage collection and SharePoint has inherited those problems. When you create SPWeb objects (references to SharePoint sites) it does not automatically dispose of the object because (among other reasons) it does not know if you are finished using it.

SPDisposeCheck is an incredibly useful tool which will analyze your custom SharePoint assemblies (compiled dll files) for memory leaks in the form of poorly handled SPWeb objects (very common issue!). Some of my company’s externally developed SharePoint applications were causing server wide SharePoint issues (memory leaks, poor server performance) which sparked the investigation. I was able to find most of the memory leaks just browsing through their code but SPDisposeCheck did it in seconds versus manually searching through thousands of lines of code and even flagged some bad coding practices that I did not spot. It does not fix the code for you but it does tell you the exact file, method, line of code and bad pattern detected so you can easily fix it. Most cases can be resolved with a simple using statement around SPWeb objects so that they are automatically released at the end of the code block but there are three options for disposing:

1. Wrap the new SPWeb object (“SPWeb web = new SPWeb(SPSite.OpenWeb())”) in a using statement
2. Use a try, catch, finally and call SPWeb.Dispose() in the finally block
3. Explicitly call SPWeb.Dispose() every time you’re finished with the object

Option #1 is usually my choice, but each have their use cases.

Note: You do need to use caution when disposing of objects that are called using SPContext (versus “newing up” a SPWeb object… “SPWeb web = new SPWeb()”) because objects created from SPContext are actually managed by SharePoint very well and if you dispose of it, the server will freak out when it tries to dispose of it. You won’t get memory leaks but your users will get nasty errors like Exception occurred. (Exception from HRESULT: 0×80020009 (DISP_E_EXCEPTION)) if not handled properly.

There is a great blog post that analyzes the patterns and shows how to prevent the memory leak in each case.

A great idea would be to configure SPDisposeCheck to automatically run as part of your Visual Studio build process and/or prior to being checked in to a code repository.

This is something that should be kept in mind when working with third party SharePoint developers and when developing solutions in house. It’s easy to miss these bugs but they can cause some serious problems for your SharePoint environment. Nothing should be deployed to production server until SPDisposeCheck returns a happy report on your custom assemblies.

sharepoint 2010 beta

Hot off the press for MSDN subscribers: https://msdn.microsoft.com/en-us/subscriptions/securedownloads/default.aspx?PV=42%3a393%3aEXE%3aen%3ax64

inject line breaks into data views for infopath repeating fields

If you’ve ever promoted a field from InfoPath to SharePoint you may have noticed that when working with repeating data you get some different options in the promotion property dialog than if you work with non-repeating data. The additional options are to store your data as First, Last, Count or Merge. First/last will show only the first/last value in the repeating table, count will display the total number of items and merge will take them all and slap them together one after another. The data looks great when you view the columns in a SharePoint list view, breaking each item onto its own line just as you would expect. If you try to work with that same data in a data view web part, however, you’ll notice that it scrunches all of you rows together and eliminates any line breaks.

What we want to do is to go from displaying our column data like this

to this

The key is to rely on the ddwrt XSLT extensions and wrap your selected element with the AutoNewLine function: “ddwrt:AutoNewLine (string(yourelementhere))”. Make sure you typecast it as a string or else you will get nasty xslt transform errors.

The resulting XSLT would look something like this:

<xsl:value-of select="ddwrt:AutoNewLine(string(@_x007b_70e17bba_x002d_be48_x002d_4f3f_x002d_ac0c_x002d_ebe359bebf49_x007d_))" disable-output-escaping="yes" />

MS has a summary of the ddwrt properties available here. Although the article refers to SPS 2003, the properties seem to hold true for WSS 2007 data views as well.

I hope this helps someone out there because there are not many clear references to this on the web that I could find!

infopath unclosed literal string

When making changes to one of our browser forms I came across an issue where when I would switch views in the form, I would get the generic “the form has been closed” error with no description. Checking into the server logs I found this

02/13/2009 09:08:47.20     w3wp.exe (0x1158)                           0x1008    Forms Server                      Forms Services Runtime            82fp    Warning     Exception occurred during request processing. (User: server\dev, Form Name: , IP: , Request: http://server/_layouts/FormViewNotify.aspx?XmlLocation=/sites/ff/Formulations/032034.xml, Form ID: , Type: XmlException, Exception Message: There is an unclosed literal string. Line 1, position 898.)

I couldn’t find any problems in the form code or the xml schema so I hit google and found a hotfix that microsoft released for this issue. The kb is 949752 and you can get it here: http://support.microsoft.com/kb/949752. It solved my issue and the forms render fine when views are changed.

form upgrades and property promotion

Strange issue I encountered today when upgrading my InfoPath form via forms services. If you have added any property promotion fields as part of this upgrade, they will not actually get promoted to SharePoint. The column did not appear. No data was promoted. So I checked my property promotion settings and the field I wanted to promote was in the list. What’s the problem?

Not sure really. Bug or undocumented feature? For some reason the form needs to be deactivated and then reactivated to your site collection in order for the fields to be properly promoted.

get user’s full name in infopath using sharepoint profile web service

InfoPath forms give you some really great abilities to interact with external sources and services. One of these is the SharePoint profile service. You can easily get the full name of the user but it is not very clear how to do this at first.

First, create a new data connection to receive data from a web service:

http://<yoursharepointserver>/_vti_bin/UserProfileService.asmx?WSDL

The operation you want in order to get the user’s full name is GetUserProfileByName

leave the account name parameter blank, we will populate it on the fly

uncheck ‘store a copy of the data’

then check the ‘automatically receive data when form is opened’ box and the web service is ready for use.

What I have done is created a new string data source (field) called ‘name’, you can call this anything you want. Set the default value of the field to be this formula (click the fx button) and make sure to remove any line breaks:

("GetUserProfileByName")/dfs:myFields/dfs:dataFields/
s0:GetUserProfileByNameResponse/s0:GetUserProfileByNameResult/
s0:PropertyData[s0:Name="PreferredName"]/s0:Values/
s0:ValueData/s0:Value

If you have problems pasting this in, make sure to turn on the “Edit XPath (advanced)” checkbox option on the Insert Formula window. You could replace “PreferredName” with “WorkEmail” or any other SharePoint profile property you want to retrieve.

Now you’re ready to display the user’s full name in your form or append it to a filename or anything else you can think of.