SP2010 Forcing previously deployed file to update to latest version in site definition

 

I’m a big fan of quickly making changes to my SharePoint JavaScript file in SharePoint Designer and then test whether they work correctly in the browser.  Quick browser refresh and I’m testing.

But I don’t recommend this on your test or production environments.  For those cases, you should package your JavaScript files into a solution and deploy them.

SharePoint 2013 ReplaceContent Attribute

SP2013 introduced a new attribute ReplaceContent=”True” http://msdn.microsoft.com/en-us/library/office/ms459213(v=office.15).aspx when this attribute is set to True, when your feature is activated it will replace existing files on SharePoint with the contents of the files from the package.  This attribute is excellent for deploying JavaScript files.

 

SharePoint 2010 IgnoreIfAlreadyExists Attribute

In SP2010, you aren’t as lucky.  The IgnoreIfAlreadyExist attribute needs to be set to true.  Otherwise your feature will most likely fail to activate if a file already exists.  This is troublesome because with the ignore flag on, your JavaScript files won’t update to the latest new version.

There are a few approaches that people take.  Some chooses to delete all the assets when deactivating the feature.  Then on reactivation, the assets are recreated brand new with the latest bits.  This works fine for CSS, JavaScript files, but will not work for MasterPage or PageLayout files that are in use.

 

Add Reset to Site Definition

I propose this fantastic method:

SPFile.RevertContentStream();

http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.spfile.revertcontentstream(v=office.15).aspx

This forces the SPFile to revert back to the site definition.  Essentially this is what SharePoint Designer does when you click on

image

 

When I deploy to production, but I know I need to bump 2 of my JavaScript files to the latest site definition, I run this powershell.

PS D:\> $web = Get-SPWeb http://server
PS D:\> $file = $web.GetFile("Style Library/app/John/john1.js")
PS D:\> $file.CustomizedPageStatus
Uncustomized
PS D:\> $file.RevertContentStream()
PS D:\> $file = $web.GetFile("Style Library/app/John/john2.js")
PS D:\> $file.CustomizedPageStatus
Uncustomized
PS D:\> $file.RevertContentStream()

 

This works whether the file is Uncustomized (deployed via a previous package) or Customized (deployed manually or updated by a user).  After the method is run, the file content will be the latest version that was in the deployed WSP package.

Try it out.  Quite useful for fixing 1 JavaScript file in a package.

Using SharePoint Designer 2013 Workflow to copy file via REST on Office 365

This is a bit of trial and error, but works very well at the end, so I want to publish this and share the syntax.

 

Related References:

 

I will tackle the next step.  How do you call a POST REST service, with the CopyTo function on SPFile.  http://msdn.microsoft.com/en-us/library/ms455020.aspx

The flexibility is that you can easily tweak the urls and essentially allow your workflow to copy files anywhere.

 

Step 1.  Understand the correct URL

 

Put this into your browser's address bar (this executes a GET request):

image

No good.  Need POST.

 

Step 2.  Make that SharePoint Designer 2013 Workflow

 

  1. First step, with the POST call, we need to add a Request Header for Accept: application/json; odata=verbose
    Put this in a dictionary variable.

    image
  2. Second step.  Call Web Service!
    image

    You need to set up Request Headers as well.  This has to be done via the Properties, since it's not a link that's shown.  Set this to the dictionary created in the previous step.
    This step is the same as mentioned in Adrian Fiechter's blog.

    image
  3. You should capture the ResponseContent, and add an additional action to log it to History
    The Stage ends.  Go to End of Workflow.

    image

  4. The whole thing, in 3 lines:

    image

Step 3.  Run it.

 

image

Here's me starting the workflow on the top1.png file.

 

image

The top1.png is copied to top2.png!  Interestingly, it's copied the Call Workflow "workflow status" column.  Both links (which is a lookup field) go to the same workflow.

 

image

This is the workflow history. 

Notice that the CopyTo method returned void (null) in this case.  Should there be an error, you'll see it logged here.

 

That's all!  Hope you find these steps useful.