Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I'm trying to modify some of the XSL in a DataForm web part (thanks to migration from SP2007 -> SP2010), and I'm able to checkout the file (several files, eventually), find the relevant XSL, and replace it with the SP2010 equivalent.

But what's not working is attempting to save the changes.

The code looks roughly like this:

       currentPage = CheckPageOut(...);
       web.AllowUnsafeUpdates = true;

       using (SPLimitedWebPartManager wm = web.GetLimitedWebPartManager())
       {
           SPLimitedWebPartCollection wpc = wm.WebParts;
           for (int i = wpc.Count - 1; i >= 0; i--)
           {
               Microsoft.SharePoint.WebPartPages.WebPart mwp = wpc[i] as
                       Microsoft.SharePoint.WebPartPages.WebPart;

               // ... find and replace XSL bits

               wm.SaveChanges(mwp);
           }

           wm.Web.Dispose();
       }

       currentPage.Web.Update();
       CheckPageBackIn(currentPage);

The call to SPLimitedWebPartManager.SaveChanges always triggers an exception that says "The file is currently checked out or locked for editing by another user.". This is the case no matter who I'm logged in as (even when I supply SystemUser's SPUserToken).

What could I be doing wrong?

Thanks in advance
Josh

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

The path turned out to be a lot more tortured than I thought. Thanks to one of Gary Lapointe's SP2010 cmdlets (Replace-SPWebPartContent), I was able to see and step through a working example with source code.

To make a long story short, checking out the current page causes the Limited Web Part Manager to lose track of who exactly has this page. To rectify the situation, you have to dispose of both the existing LWPM and the existing DFWP and rebuild their references. You then apply .SaveChanges to the freshly-created LWPM.

The code looks roughly like this:

    currentPage.Checkout();

    currentPage.Web.AllowUnsafeUpdates = true;

    wm.Web.Dispose(); // Resolves a memory leak that would result if we didn't do this.
    wm.Dispose();
    string wpId = dfwp.ID;
    dfwp.Dispose();
    dfwp = wm.WebParts[wpId] as DataFormWebPart;
    dfwp.Xsl = replacementXsl;
    wm.SaveChanges(dfwp);

(Who woulda thunk it?)

Regards Josh

share|improve this answer
add comment

Use the GetLimitedWebPartManager on the SPFile object instead.

And there is no need to call Update() on the SPWeb object.

share|improve this answer
    
>> Use the GetLimitedWebPartManager on the SPFile object ... I tried that, but it gives me the same result. It still thinks the file is checked out to some other user. Good try, though. I'd appreciate hearing any other ideas on what might be wrong. Thanks. –  Josh Korn Sep 15 '11 at 14:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.