Chart controls in ASP.NET 3.5 may not appear when Printing

We implemented a solution for a client recently which leveraged the Dundas Charting controls that were part of the 3.5 framework. They were really good for the simple charts we were trying to render, but there was one problem – when printing the page, the charts came up as “Missing Images” for some users (you know, the hole in the page with the red X in the top left corner…). Also when you right-clicked on the image and tried to open the image path in a new window (driven through the /ChartImg.axd?i=chart_0_15.png&g=9316796b85bd41c895e6ff7e7e4d41aa URL), it would fail as well with a SharePoint exception.

As we were tracing the mechanics of rendering the charts back through the solution, we noticed that the charts would exist for a split second in the “Temp Chart” folder and then they’d be deleted… which is why (when you tried to print the page) the charts would appear as missing images.

The solution was to add a parameter to the web.config setting to tell the system to not delete the charts automatically… so this –

<appSettings>
<add key=”ChartImageHandler” value=”storage=file;timeout=20;dir=d:\Temp\;” />
</appSettings>

became this:

<appSettings>
<add key=”ChartImageHandler” value=”storage=file;timeout=20;dir=d:\Temp\;deleteAfterServicing=false;” />
</appSettings>


 

That was one side of the problem… we then had to set up a housekeeping scheduled task to delete the images at midnight every night. There are other options (store the images in memory and not delete them, store them in the session and store the images in the page), but none of them are fantastic…

Notes:

  1. This was only an issue for people who had Internet Explorer set to check for a new page version every visit to the page.
  2. If you are using a load-balanced environment, you will need to set up sticky sessions on your load balancer – because the files are written to a local folder, the ChartImg.axd app cannot retrieve chart images from another server – Using a shared folder is probably a worse option, as there are more points of failure than a local folder
  3. Don’t use C drive – if something you are developing has the ability to consume increasing storage, put it on any drive except C drive. Same goes for logs, search indexes, etc…
Advertisements

About Brad Saide

I'm a SharePoint consultant. I'm also slowly going bald, seem to have a permanent spare tyre around my waist and enjoy socialising with friends over a beer or 10. The last 2 may possibly be related. Started working with SharePoint when the first version was in limited beta release (participated in the Technology Adoption Program while at Woolworths) and have been committed to the adoption of the technology as a business enabler ever since.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s