EmbedImage is creating corrupt files, does not care about file type

[GoogleCodeExporter]

EmbedImage is taking valid WatiN generated PNG files and turning them into
invalid PNG files. 

It is also ignoring the file type (always generates .png files regardless
of whether WatiN outputs .bmp, .png etc.)

I have attached a sample class file and two images - tmp26B6.png is
generated from WatiN, test.png is the broken output file from Gallio / mb-unit

Steps to Reproduce:
1. Use WatiN 2.0.20.1089 (WatiN 2.0 RC 1)
2. Create a png image using WatiN CaptureWebPageToFile(filename)
3. EmbedImage("test", System.Drawing.Image.FromFile(filename))

Test Environment: 
Windows 7 Ultimate x86, .NET 2.0, WatiN 2.0 RC 1 (2.0.20.1089), 
GallioBundle-3.1.397.0-Setup-x86.msi, Visual C# 2008 Express Edition

Original issue reported on code.google.com by gmcdonald@vividas.com on 21 Dec 2009 at 2:02

Attachments:

• Class1.cs
• tmp26B6.png
• test.png

[GoogleCodeExporter]

Note - I'm using Icarus to run my tests

Original comment by gmcdonald@vividas.com on 21 Dec 2009 at 2:04

[GoogleCodeExporter]

Hmm.  EmbedImage currently always emits a PNG without considering the filetype 
of the
original image, however that shouldn't really be a problem and certainly 
shouldn't
result in any corruption.  I'll have to look into that.

Instead of saving the capture to a file and reading it back in, I do recommend
capturing to an image instead.  You'll find an example of how to do that in the 
WatiN
samples distributed with Gallio.

Original comment by jeff.br...@gmail.com on 21 Dec 2009 at 5:22

• Added labels: Type-Defect, Priority-Medium, Component-Gallio, Milestone-3.2

[GoogleCodeExporter]

Thanks Jeff - I have converted the process to capture to an image file instead -
that's a much nicer way of doing it.

The failure remains the same.

Original comment by gmcdonald@vividas.com on 21 Dec 2009 at 5:51

[GoogleCodeExporter]

It's still emitting an invalid PNG?  Whoa...

So I took a look at the file you uploaded.  There are a couple of oddities 
about it.

First, it looks like it used to be a valid PNG file but somehow got munged and
reencoded a text or something.  It contains a whole bunch of "EF BF BD" 
characters
which is UTF-8 corresponding to the Unicode replacement character \uFFFD.

I can't think of anywhere in the pipeline where that would happen except at the 
point
of display in Icarus if the wrong MIME type were being passed to the browser...

When you copied the image, did you right-click on it in the browser and select 
Save
As or did you grab it directly from disk in the saved report directory?

Original comment by jeff.br...@gmail.com on 21 Dec 2009 at 7:08

[GoogleCodeExporter]

Yep.

Hmm that's interesting.

I took both the correct (WatiN generated) and incorrect (Gallio / mbunit 
generated)
PNG from the system temp folder (Users/username/AppData/Local/Temp/ etc) so the
corruption hasn't been caused by the browser.

Original comment by gmcdonald@vividas.com on 21 Dec 2009 at 7:38

[GoogleCodeExporter]

Jeff, I don't know if this is related or may help, but I came across this 
similar
problem report this morning: 

http://social.msdn.microsoft.com/forums/en-US/csharpgeneral/thread/21b2c560-ed16
-4edb-bdab-6a55902d6ae3

Judging by the MemoryStream class documentation, the encoding might need to be
explicitly set prior to the read / write operations:

http://msdn.microsoft.com/en-us/library/system.io.memorystream.aspx

Original comment by gmcdonald@vividas.com on 21 Dec 2009 at 10:31

[GoogleCodeExporter]

MemoryStreams don't have encoding because they're pure binary.

The other thing to keep in mind is that I've never encountered any problems of 
this
sort with attachments.  If it were a simple encoding issue, I should have 
noticed by now.

Original comment by jeff.br...@gmail.com on 21 Dec 2009 at 10:38

[GoogleCodeExporter]

Ahh I see.

I dug a bit deeper - it turns out that the images stored by Icarus prior to 
clicking
"View Report As" are actually valid.

These images are stored in
C:\Users\username\AppData\Roaming\Gallio\Icarus\Reports\test-report-20091222-102
657\66c167ece0444cf4

The invalid images are stored in
C:\Users\username\AppData\Local\Temp\Gallio\Gallio.Icarus.Services.ReportService
\tvmtdrqg\66c167ece0444cf4

Are the image files processed by Icarus in order to generate the reports?

Original comment by gmcdonald@vividas.com on 21 Dec 2009 at 11:48

[GoogleCodeExporter]

Ah ha!  I'll bet there a bug in the code that reads reports back from disk.  
It's
probably not handling binary attachments properly.

Original comment by jeff.br...@gmail.com on 22 Dec 2009 at 10:46

[GoogleCodeExporter]

Yann is looking into this now.

Original comment by jeff.br...@gmail.com on 12 Feb 2010 at 7:26

• Changed state: Accepted

[GoogleCodeExporter]

Oh! I had never noticed that there was an issue for that! I just saw that bug a 
few 
days ago and fixed it today... :)

Indeed there was an inconsistency in the way reports are loaded, between 
'inline' and 
'linked' attachments. It should be solved in the next daily build. 

Original comment by Yann.Tre...@gmail.com on 12 Feb 2010 at 8:01

• Changed state: Fixed

[GoogleCodeExporter]

So is this fixed in both v3.1 and v3.2 branches?

Original comment by jeff.br...@gmail.com on 2 Mar 2010 at 1:41

[GoogleCodeExporter]

Mmh... No, only in the v3.2 branch.
Do you plan to release a new update for v3.1?

Original comment by Yann.Tre...@gmail.com on 2 Mar 2010 at 1:58

[GoogleCodeExporter]

Now I remember... You had proposed to get rid AttachmentEncoding and to replace 
it by AttachmentType. I went completely out of my mind. I will handle it 
tonight. Should I 
port this to v3.1 too?

Original comment by Yann.Tre...@gmail.com on 2 Mar 2010 at 4:38

• Changed state: Started

[GoogleCodeExporter]

Oh right!

On reflection, let's not port that to v3.1 because it will be a breaking change 
in
the report format.

Original comment by jeff.br...@gmail.com on 2 Mar 2010 at 7:53

[GoogleCodeExporter]

Yup... That's what I was saying to myself.

Original comment by Yann.Tre...@gmail.com on 2 Mar 2010 at 8:14

[GoogleCodeExporter]

Done and done.

I made various tests by using the FormatReport command of Gallio.Utility to 
ensure that 
attachments are saved, re-loaded, and re-saved properly. But there is a change 
to in 
the CCNet plugin that I was not able to test. We will see...

Original comment by Yann.Tre...@gmail.com on 2 Mar 2010 at 8:15

• Changed state: Fixed

[GoogleCodeExporter]

Hi Yann,

I tested this again in Gallio Icarus 3.1 build 499 (March 17th) - it's still 
failing
to generate a valid .png when, within Icarus, you right click the test report 
and
click View Report As->(anything).

The images displayed within the Icarus Execution Log are now valid though :)

Original comment by gmcdonald@vividas.com on 17 Mar 2010 at 10:42

[GoogleCodeExporter]

Hi.

Sorry. The issue was solved in v3.2. But as indicated earlier by Jeff, we 
cannot 
easily port the fix back to v3.1 because it's a breaking change which affect 
the 
report format. 

May I suggest you to use the latest v3.2 daily build? It's currently very 
stable (I 
have been using it in production at work for months) And we are very close to 
release 
it as "v3.2 beta 1" anyway.

Original comment by Yann.Tre...@gmail.com on 18 Mar 2010 at 6:28

[GoogleCodeExporter]

Sorry Yann, I must have misunderstood the comment trail.

All good in 3.2 b371 :)

Original comment by gmcdonald@vividas.com on 18 Mar 2010 at 10:23

[GoogleCodeExporter]

Issue 694 has been merged into this issue.

Original comment by Yann.Tre...@gmail.com on 29 Jul 2010 at 5:24