If you are looking to customize SharePoint 2010 using Custom Actions (CustomAction element), you may encounter a situation where the contents of the ScriptBlock do not fire. For example, when adding SharePoint support for jQuery you might have something like this in your elements.xml file:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction ScriptSrc="JQueryLib/jquery-1.7.1.min.js" Location="ScriptLink" Sequence="100"></CustomAction>
<CustomAction ScriptBlock="$.noConflict();" Location="ScriptLink" Sequence="110"></CustomAction>
</Elements>
This is intended to make the jQuery library available to every page and also to eliminate potential issues with using the dollar sign ($) for referencing jQuery in your SharePoint 2010 environment. ScriptSrc is used to reference the file containing javascript (in this case the jQuery library), while ScriptBlock gives you the ability to add in-line javascript.
I see two potential issues with the above approach, and both are related to your inability as a SharePoint developer to control or even be aware of the actions of SharePoint, other developers, third party tools, etc. within the same SharePoint environment.
Issue #1: The first issue is encountered when you have more than one ScriptBlock defined within the same scope but you haven't assigned the CustomAction a unique id. For example, let's say your SharePoint environment has two features activated at the site collection level, and both have CustomActions with ScriptBlocks defined. The ScriptBlock with the lowest "Sequence" number will execute and the other will be ignored entirely. You can avoid this situation by including "id=<your unique identifier>" on your CustomAction elements.
Issue #2: While the Sequence number is helpful in influencing the order of .js files and the processing order of in-line code from ScriptBlocks, the .js files and in-line code are not placed "together" at run-time. All of the .js files are referenced in one area of the page, and the in-line code is located in another. As a result, if multiple features were using custom actions to reference their own versions of jQuery (and perhaps using the noConflict trick of obtaining a reference to their specific version of the jQuery library), then using the ScriptBlock as above would always reference the "last" jQuery library (or the one with the highest Sequence number). Placing the noConflict code in its own .js file and referencing it that way gives you much greater control over the order of how your libraries and javascript are deployed.
In summary, if you have a ScriptBlock that isn't firing in your SharePoint implementation, check to make sure your CustomAction is assigned a unique identifier. Having more than one ScriptBlock with no unique identifier will cause all but one (the one with the lowest Sequence number) to be ignored.













