Domanda

I'm using the SSRS web service to generate HTML4.0 format reports and then I'm trying to send them with System.Net.Mail (I know SSRS has built in report scheduling, but we have a requirement to handle all scheduled processes in a central location). So, I'm generating the html files and then trying to construct the mail message something like this :

using (var sw = new StreamReader(htmlFile))
{
    mail_body = sw.ReadToEnd();
}

var mail = new MailMessage
                {
                    From = new MailAddress(mail_from),
                    Subject = mail_subject,
                    IsBodyHtml = true,
                    Body = mail_body
                };

The only problem being that when I do this, although the html file looks fine when I open it in a browser, in Outlook it ends up horizontally squashed.

e.g. this is what my html file looks like in IE :

enter image description here

But after when I send the email using the method above, in Outlook it ends up looking like this :

enter image description here

It seems as though there's some kind of line width limit being imposed, but I'm not sure at what level this is happening.

Does anyone have any insight at all as to what might be causing this?

Thanks!

È stato utile?

Soluzione

We faced a similar problem and after a lot of workarounds we finally found out the one parameter in SSRS configuration that did the trick: OutlookCompat. With this enabled the HTML4.0 e-mails no longer look squished in Outlook.

See the MSDN documentation for more details. You can set this value either in the SSRS configuration file (for all reports and callers) or directly when calling the ASMX.

Example of the SSRS configuration:

<Extension Name="HTML4.0" Type="...">
    <Configuration>
       <DeviceInfo>
          <OutlookCompat>True</OutlookCompat>
       </DeviceInfo>
    </Configuration>
</Extension>

Altri suggerimenti

I found a cause plus solution/work-around which I hope someone else can make use of.

I compared the base64 encoded HTML in the MHT file with the directly generated HTML4.0 markup and found a unique recurring discrepancy. Each table cell class in the HTML4.0 report is defined something like this :

.a23c
{
    padding-left: 2pt;
    padding-top: 2pt;
    padding-right: 2pt;
    padding-bottom: 2pt;
    border: 1pt solid Black;
    background-color: #d3d3d3;
    vertical-align: top;
    text-align: center;
    direction: ltr;
    layout-flow: horizontal;
    writing-mode: lr-tb;
}

However, when I look at the decoded html in the MHT file the classes in there have two extra properties - width and min-width, e.g.

.a23c
{
    padding-left: 2pt;
    padding-top: 2pt;
    padding-right: 2pt;
    padding-bottom: 2pt;
    border: 1pt solid Black;
    background-color: #d3d3d3;
    vertical-align: top;
    text-align: center;
    direction: ltr;
    layout-flow: horizontal;
    writing-mode: lr-tb;
    min-width: 28.05mm;
    width: 28.05mm;
}

It seems that having these properties unset causes Outlook to squash the table cells down (possibly because its HTML parser defines 100% width as somewhere around the 80 column limit?).

So, knowing this, the work-around would seem clear : read in the generated the MHT file, decode the base64 encoded HTML in there and send that as the mail body. This actually seems to work, and with a minimum of code :

var decoded_text = new StringBuilder();
using (var reader = new StreamReader(mhtFile))
{
    while (!reader.EndOfStream)
    {
        var line = reader.ReadLine();
        if (line != "Content-Transfer-Encoding: base64") continue;

        reader.ReadLine(); //chew up the blank line
        while ((line = reader.ReadLine()) != String.Empty)
            if (line != null)
                decoded_text.Append(Encoding.UTF8.GetString(Convert.FromBase64String(line)));
        break;
    }
}

I'm not entirely convinced of the robustness of this code, but it seems to work well enough for the moment so I'm going to accept this as the answer. Would be happy to learn of better solutions if anyone more knowledgeable ever ends up reading this!

I had the same problem but the accepted answer didn't work for me with Outlook 2013. The ExpandContent property helped me to fix the width issue.

This is my config for the device info:

            const string devInfo = @"<DeviceInfo>" +
                                "<HTMLFragment>True</HTMLFragment> " +
                                "<OutlookCompat>True</OutlookCompat>" +
                                "<Toolbar>False</Toolbar>" +
                                "<ExpandContent>True</ExpandContent>" +
                               "</DeviceInfo>";

Afterwards the report is rendered through the SOAP API with the devInfo provided:

reportBytes = reportService.Render(renderFormat, devInfo, out extension, out encoding, out mimeType, out warnings, out streamIDs);

Hope this helps.

Sven

first open the below file :

C:\Program Files\Microsoft SQL Server\MSRS12.MSSQLSERVER\Reporting Services\ReportServer

than try to locate the following extension :

<Extension Name="HTML4.0"

now make sure your extension element has the below child :

 <Configuration>
       <DeviceInfo>
          <OutlookCompat>True</OutlookCompat>
       </DeviceInfo>
    </Configuration>

now your report would be nicer in outlook.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top