RiskFactor

If your looking for the solution to the above error in SharePoint due to the use of the SPUrlExpressionBuilder (SPUrl) you will want to try a couple of things. The first is to include the following page declarations in the MasterPage if you have not already. 

<%@ Register Tagprefix="PublishingWebControls" Namespace="Microsoft.SharePoint.Publishing.WebControls" 
             Assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, 
             PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="PublishingNavigation" Namespace="Microsoft.SharePoint.Publishing.Navigation" 
             Assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, 
             PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="PublishingVariations" TagName="VariationsLabelMenu" 
             src="~/_controltemplates/VariationsLabelMenu.ascx" %>
<%@ Register Tagprefix="PublishingConsole" TagName="Console" src="~/_controltemplates/PublishingConsole.ascx" %>
<%@ Register TagPrefix="PublishingSiteAction" TagName="SiteActionMenu" 
             src="~/_controltemplates/PublishingActionMenu.ascx" %>

If you continue to get the above error you might be having the issue that I ran into where I was using the SPUrl inside of an ASP.NET User Control.  This has to do with the way that the User Control and MasterPage are parsed.  The User Control is parsed by ASP.NET first prior to the MasterPage.  This means that the declarations in the MasterPage are not present for the User Control.  The solution is to also include the above declarations in the markup for the User Control. Including the declarations in the User Control insures that the SPUrl tag prefix has been registered prior to the parsing of the expressions that use it.

Tags: asp.net, sharepoint

My team at work has finally gotten to a good point for migrating our source code for several of our products into Team Foundation Server.  I have been using the Workgroup edition of TFS at home for over a year now and really enjoy the features of both the source control as well as the project portals.  In fact, I haven’t had a single issue with TFS at home which is why when I ran into a puzzling issue with my project portals at work I really got thrown for a loop.  With my new portals I was experiencing an issue on both of my development machines that was preventing various action menus from being displayed on the home page as well as in my document libraries and on other pages.

For instance, if I was in a document library and tried to open the drop down menu for a given document I would get a Javascript error of Object expected generated in the script from the ~/_layouts/1033/ows.js file.  Here’s a screenshot of what I was getting:

So, after spending two days reviewing permissions in TFS, verifying that IE was up to date, working with our local SharePoint expert, and searching on Bing and Google till my eyes bled, I had just about given up.  Then this afternoon I found what I was looking for here. Come to find out my whole issue was the my User Agent string being generated by IE was too long for the TFS WSS instance to handle properly which resulted in the thoroughly baffling behavior I was seeing on my portals.  Since I have every version of the .NET Framework on my machine, plus a slew of other add-ins and applications my UA string was well over 200 characters.  So, to resolve it I made a few edits in the registry to eliminate the nonessential keys being used in IE to generate my bloated UA string.

If you are having these same issues, you can check your UA string length here. And if you need to shorten it, you can find a quick guide for the registry keys to pin point here.

Tags: sharepoint, tfs, team foundation server