Custom actions are usually deployed in a declarative manner, such as an Elements.xml file. They can be deployed to a specific content type in case your document library inherits from the specific content type, such as below:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
</CustomAction>
<CustomAction
Id="{ACE9ADB4-A9CE-4503-9819-AC9C6FC09E01}"
RegistrationType="ContentType"
RegistrationId="0x01010059dee241fa9e47e8aded6c595cb2b406"
Location="EditControlBlock"
Sequence="101"
Title="Approve/Reject Monthly Report">
<UrlAction Url="javascript:MyNamespace.retrieveListItems({ItemId});"/>
</CustomAction>
</Elements>
However, when your document library gets deployed via code, such as feature receiver, and especially if the document library is not associated with a content type, there is the option to attach a custom action programmatically such as in the example below.
Guid formlibID = web.Lists.Add("My Library", string.Empty, SPListTemplateType.XMLForm);
SPList formLib = web.Lists[formlibID];
SPUserCustomAction printForm = formLib.UserCustomActions.Add();
printForm.Title = "Print Form";
printForm.Url = "javascript:MyNamespace.printForm({ItemId},'{ItemUrl}')";
printForm.Location = "EditControlBlock";
printForm.Update();
In both examples, the custom action performs some javascript logic (in this case the two functions both open up a modal popup), that takes in the current items' out-of-the-box ID and URL.
