Category: Development

  • Dealing with corrupt WebConfigModification entries.

    Recently, I came across a problem.  I had created a new SharePoint Designer Custom Action and I created a feature solution package to deploy it to the production farm.  In testing it in a dev environment, I kept getting errors from the code I was using to make the appropriate web.config entries.  A custom SPD workflow action requires an ‘authorizedType’ entry in the web.config.  I have code in my feature receiver that will create a WebConfigModification entry in the WebConfigModifications collection and then use the SPService to apply the modifications.  (MSDN).  My problem was that someone had created a corrupt entry in the collection and it kept erroring out before executing my change.  It took a little understanding of how this works to find the solution to the problem.

    The WebConfigModifications are a persisted object. That means that they remain until they are operated on.  In essence, it is a persisted queue.  Each entry is related to a SPWebApplication and added to the queue.  To remove the offending entry, I had to identify which web application the entry was registered with.  I just started going through every web application in my farm.  You could iterate through each application but in my case, I just hard-coded the URL for each application.  Here is the code that I used to clear the corrupt entries:


    string siteUrl = @"http://localhost:44689";
    SPSite site = new SPSite(siteUrl);
    SPWebApplication webApp = site.WebApplication;
    webApp.WebConfigModifications.Clear();
    webApp.Update();
    SPWebService service = SPWebService.ContentService;
    service.WebConfigModifications.Clear();
    service.Update();
    service.ApplyWebConfigModifications();

    I created a console app and put the code above in the Main() method. I kept executing the code using different web application URL’s until it executed without any error. Once I didn’t get an error, I was pretty sure that I had cleared the bogus entry. The next time I ran my feature code, it executed flawlessly!

    A couple of notes. Obviously, this code is meant to be executed on the server and not a client. My dev machine has a single WFE. I would think that the best place to execute this would be on the same machine where Central Admin resides. Also – this was for a problem on a MOSS (WSS3) install. I am sure that it works the same in SharePoint 2010.

    You can find the correct URL’s in IIS for each web application on your server. In my case, it was a shared development machine so there were many web applications executing under many different ports.

  • It Happens To Everyone

    Unexpected Error at SharePoint.Microsoft.com

     

     A co-worker pointed this out to me.  Seems like someone was making a change to SharePoint.Microsft.com without testing and got the Unexpected Error!  I’m sure it was unexpected! 

    The site was down for only a little while but it gave both of us a chuckle. 

    Thanks Matt!

  • Removing OPTIONS with jQuery

    Here’s a usability solution that was necessitated by my desire to present a logical, workable solution to my end-user.  I’m still learning jQuery so my solution may not be the most elegant – but it works. I welcome any improvements!

    The Setup

    I have a SharePoint site that is displaying the results of an SQL stored procedure.  I’m using Quest Web Parts for SharePoint – qSIListView part which is part of their fine System Integration web parts package.  The great thing about these web parts is that I can create a stored procedure on a database and then use the Filter capabilities of the qSIListView to supply the stored procedure with the parameter values.  It’s a pretty slick solution and very easy to configure.  My problem  is that when you use the filter fields as the Parameter input fields, only the “Equals” operator has any meaning.  I can select “Begins with” or “Contains” but it will only just pass the parameter value and not the operator.  That means that my End User will be presented with a lot of false options.  To avoid the confusion, I would like to present the user with one operator – “Equals”, or in the case where I’m trying to do some wild card matching in SQL, I would remove all but “Contains”.  You get my point.  The problem is that the Web Parts do not have the ability to filter out the operator selections.  I’ve submitted this change idea to Quest for future versions but in the mean time, I needed to find a solution.  My solution was to use jQuery.

    Click to enlarge.

    Solution

    There are many posts out on the web about using jQuery to manipulate the SharePoint interface.  One of the best sites for jQuery on SharePoint can be found on EndUserSharePoint.com.  The solution I am talking about today can be used in any web environment, including SharePoint.  Essentially, my short script removes all <option> elements from all select boxes that match a certain text value.  This effectively narrows the choices presented to the User to only the valid choices, Exclude from search and Equals.

    To do this, I placed a Content Editor Web Part (CEWP) onto my page and pasted my script in it.  In the script, I use jQuery to select all <OPTION> elements of the page and remove them if they contain any of the invalid choices.   The script is pretty straight forward.  I have jQuery stored in a script library on my SharePoint site.  This library provides read-access to all users on the site.  It is also a common place to store all of my scripts.  A good post on creating a script library can be found on here.

    Once I load the document, I have search for all matching <OPTION> elements and remove them.


    <script src="http://mysharepointdomain.com/scripts/jquery-1.4.2.min.js" type="text/javascript"></script>
    <script type="text/javascript">
    $(document).ready(function(){
    $("option").remove(":contains('Does not equal')");
    $("option").remove(":contains('Contains')");
    $("option").remove(":contains('Starts with')");
    $("option").remove(":contains('Ends with')");
    $("option").remove(":contains('Is empty')");
    $("option").remove(":contains('Is not empty')");
    });
    </script>

    That’s it!  The end result looks like this.

    Click to enlarge.

    As I said earlier, this is a pretty simple solution to a problem that I was having.  Now, every time I use filter fields to supply parameter values, I can be assured that I have presented my User with valid options.

    I welcome any feedback!

  • Default Quick Launch Heading Paths

    Every so often, I come across sites that have the default Heading entries on the Quick Launch deleted.  I decided to write them down here in case I ever needed to put them back.  It’s also handy to be able to navigate to the All Items link in a site with no Quick Launch.  This is really for my reference but I hope this helps someone else out!

    Default Quick Launch Heading Paths

    View All Site Content
    /[web url]/_layouts/viewlsts.aspx

    Documents
    /[web url]/_layouts/viewlsts.aspx?BaseType=1

    Lists
    /[web url]/_layouts/viewlsts.aspx?BaseType=0

    Discussions
    /[web url]/_layouts/viewlsts.aspx?BaseType=0&ListTemplate=108

    Sites
    /[web url]/_layouts/viewlsts.aspx?ShowSites=1

    People and Groups
    /[web url]/_layouts/people.aspx

    Recycle Bin

    /[web url]/_layouts/recyclebin.aspx

    ******  UPDATED for 2010 ************

    Pictures

    /[web url]/_layouts/viewlsts.aspx?BaseType=1&ListTemplate=109

  • Easy Check If An SPWeb/SPList Exist

    I write a lot of code using the SharePoint object model.  Often times, I want to check to see if a particular Web exists in a Site Collection or a List exists in a Web.  I used to write methods that enumerated through the collection to see if they existed or I wrapped a Try-Catch block around the code in case the object didn’t exist.

    Recently I came across a code snippet that made checking for the existence of a web or list easy.  I can’t remember where I found it so I’ll thank the nameless person who originally wrote the code.  I’m only capturing it here for my own reference and possibly help someone else.

    
            static bool ListExists(SPWeb web, string listName)
            {
                return web.Lists.Cast().Any(list => string.Equals(list.Title, listName));
            }
    
    
            static bool WebExists(SPSite site, string webName)
            {
                return site.AllWebs.Cast().Any(web => string.Equals(web.Name, webName));
            }
    
    
  • Determining SQL Requirements for SharePoint

    Joel Oleson has a good post about determining your SQL server requirements in your SharePoint implementation.  A good resource for planning.

    10 Key Questions Determining SharePoint SQL Server Count

  • Great SharePoint 2010 Planning Reference

    Here is a list of SharePoint 2010 Architecture and Planning links.  I am mainly capturing this link for future reference!

    http://rdacollab.blogspot.com/2010/01/sharepoint-2010-planning-and.html

  • Dealing with the [Today] problem in SharePoint Calculated Fields

    Today I was presented with a problem that I thought should have been easy.  Create a calculated field that displayed the number of days that had passed from an [EndDate] field.  My first thought was to use a calculated field with a function  =[Today]-[EndDate].  When I got that, I was informed that calculated fields could not use [Today] or [Me].

    A quick Bing informed me that a number of people had run into this same problem. There were references all over of a hack that would have me create a field called [Today] and then use it in the calculated field and then delete the bogus [Today] field.  That was really a hack since it didn’t fully work.  That hack only calculated [Today] based on when the item was last modified.  It wasn’t dynamic.  You could have saved a lot of trouble by just using the [Modified] field.

    More searching didn’t turn up any other solutions.  I tried various vbscript/excel functions in the calculated field to no avail.  Then I started thinking clientside.  I figured that if I could identify the fields in the list display, I should be able to manipulate them with jQuery.  A quick search turned up a nice little piece of code by Paul Grenier on EndUserSharePoint.com.  He has written a series entitled jQuery for Everyone and one of his articles was on Replacing [Today].  In his article, Paul talks about replacing a DateTime field with an Aging calculation. His article calculates a DateTime from the last modification date.  That works – but it didn’t work for me. What I needed was to calculate the difference between any date set by the user and the current date.  My solution was to create an [Aging] field of type Calculated.  The formula that I used in the calculated field was =[EndDate] which is the date I need to calculate the difference on.  I then modified Pauls code to use the [Aging] field and I also modified his date calculations to only calculate for the date and not hours or minutes.  The result ended up looking like the illustration below.  Thank you Paul for your awesome tutorial on jQuery in SharePoint.  I learn so much.

    testaging

  • Live Blogging

    EUSP-LiveBlogger I’m planning on LiveBlogging during the conference and the link above will take you to the Live Blogging feed.

  • Another example of how JQuery can help your site!

    I like this post because it illustrates how JQuery can make your UI code more efficient. Look at the code examples in this post. What once took 6 lines of code only takes one using JQuery. Of course, you have the overhead of loading the JQuery framework – but if you are doing a lot of client-side manipulation of the user interface then look to how JQuery can help you be more efficient.

    Low impact text changing in SharePoint with jQuery