8

I seem to be having a bit of trouble with binary components getting corrupted on publish.

I'm using the following code to publish the binary:

var img = (Component)Engine.GetObject(binaryWebdav);
var binaryPublishPath = Engine.AddBinary(img.Id,
                                         template.Id,
                                         structureGroup.Id,
                                         img.BinaryContent.GetByteArray(),
                                         filename);

This all works; but, the published file has different binary data then the file that has originally uploaded to Tridion as shown in the Hex comparison below.

BeyondCompare Hex compare

Downloading the file straight out of Tridion results in no problems so definitely something to do with the publishing.

The site is current set to publish out as UTF8 so can only think that this has something to do with it.

The storage config is pretty standard with the following:

<Storages>
    ....
    <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" 
             Id="defaultFile" defaultFilesystem="false">
        <Root Path="C:\inetpub\wwwroot" />
    </Storage>
    <Storage Type="filesystem" Class="com.tridion.storage.filesystem.FSDAOFactory" 
             Id="defaultDataFile" defaultFilesystem="true" defaultStorage="true">
        <Root Path="C:\inetpub\wwwroot\data" />
    </Storage>
</Storages>
...
    <Item typeMapping="Binary" itemExtension=".eot" storageId="defaultFile" cached="true"/>
...

Is there a way to disregard the encoding? Is it even the encoding that is causing this?

The files need to match as there is a problem with eot fonts unless the file matches exactly as it was before being added to Tridion.

| improve this question | |
  • 1
    Have you tried using Engine.PublishingContext.RenderedItem.AddBinary(stream, filename, variantId, img, img.BinaryContent.MultimediaType.MimeType) instead? You can get the stream via img.BinaryContent.WriteToStream(stream). – Bart Koopman Oct 11 '13 at 15:25
  • As you're dealing with binary data, I'm not entirely sure that character encoding plays a part here... Could you add some info about how you're storing this binary and how you're delivering it from the content delivery environment (storage config, web server info, from database/API or straight from disk etc.)? – David Forster Oct 11 '13 at 16:43
  • @BartKoopman Not tried using the RenderedItem.AddBinary with a stream - tried a stream to byte array and Engine.AddBinary but got reoccurring 00 - probably my fault that one though so will give this a try instead – ajwhitehead88 Oct 11 '13 at 16:52
  • 2
    The point of a "binary" is that the bits get transferred intact. The encoding of the target controls the transformation of textual data. – Dominic Cronin♦ Oct 11 '13 at 16:56
  • 4
    Check where this goes wrong: have you checked the binary in template builder after its added to the package in the binary output view? Next, unzip the actual transport package on the front end to see how it looks there. If its still good there, then there must be something wrong when the deployer copies the binary to its final location (maybe on a compressed location?), or stores it in a DB. In short - narrow down where in the publish stack it goes wrong exactly. – Raimond Oct 11 '13 at 20:45
5

I remember running into a similar issue writing a binary, but my problem was that the stream's position needed to be reset to the start. Perhaps under the hood your issue is along similar lines.

I've also taken a look at a number of TBBs laying around and I see the following code over and over when adding a binary to the package, first writetostream and get the array from the stream:

MemoryStream ms = new MemoryStream();
img.BinaryContent.WriteToStream(ms);

var binaryPublishPath = Engine.AddBinary(img.Id,
                                     template.Id,
                                     structureGroup.Id,
                                     ms.ToArray(),
                                     filename);

Give the above a try and see if it solves the problem. If not, look beyond the code.

| improve this answer | |
4

Found out the problem and it was a simple one!

Seemed to be an issue with publishing out an older version of the EOT file. Whether this was due to the cache channel service or the component being checked out which sometimes happens I don't know.

Making sure the cache channel was restarted and ensuring all items where checked in fully made sure the item was deployed correctly.

| improve this answer | |
  • 1
    So not an encoding problem at all. Phew - glad you found that out. – Dominic Cronin♦ Oct 15 '13 at 21:04

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.