The TOM.NET API has quite a few AddBinary methods and overloads:

  • RenderedItem.AddBinary (+ 7 overloads)
  • TemplatingRenderer.AddBinary
  • Engine.AddBinary

Other than the different method signatures is there any difference in behaviour between these?

2 Answers 2


Mihai Cădariu explains we should use the non-obsolete methods under:

  • Tridion.ContentManager.Publishing.Rendering.RenderedItem
  • Tridion.ContentManager.Templating.Engine

(avoid TemplatingRenderer.AddBinary)

The additional String in most of the method signatures lets you add a Variant ID to publish variations to different places. The string is saved in storage (broker) as explained in this SO answer. An example use case would be publishing a regular and small version of the same image (to different structure groups).


Some of those are deprecated. Note: the deprecated ones may not clean up added binaries when unpublishing.

Also if you want unpublishing of added binaries to work, you should specify the "relatedComponent" (as in one of the overloads) or the "componentUri"+"templateUri" (as in another overload). I believe for the overloads that only take a stream, filename and variantId will cause the binary to be unmanaged after publishing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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