7

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?

6

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).

| improve this answer | |
3

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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