To tell the truth Mark I'm cream crackered at the moment but we maybe missing the obvious.

That obvious being ::

Whatever we do and whatever control  we make for the server, it will get rendered to the browser as html. And that html will HAVE to have a <img> tag with a url.

So does it really matter where that url  points, whether to a jpg or whether to a aspx file  delivering a jpg through response stream.

If what we are looking at is (referring to the Pie Chart sample) as Chart.Image = Chart.Image.Resources.Image1 then even this must be rendered as an <img src="url"> tag - so ultimately Chart.Image.Resources.Image1 is an url string and not an image.

Say the Chart dll was in "http://www.piechart.com/bin/pie.dll" then perhaps what we are saying is that it would be nice for the url to look like that, perhaps pie.dll having the functionality  to output a response stream having gottom the image from itself or from a resource dll. A built in handler and a query string and your there.
However - although I have read that handlers act like isapi extensions and you can access them through their file name, I have been unable to get any success from directly going to the dll (though a .cs file is served by IIS). Maybe an isapi extension is mapped to IIS and to achieve the same here we need to tell IIS to map dlls to aspnet_isapi.dll. Even if we did, we would still have to use the web.config else all urls ending in .dll will be mapped to the same handler.
(ISAPI you would simply be able, with no messing about with web.config files  to go straight into the dll through an url)

I suppose we could say .. well when we save html files as mht files the image gets embedded into it :: and maybe that is what we are unwittingly trying to accomplish.

I have the added dilemma of trying to keep it all intrenal so I can use a resources image to render it in the designer - why I don't even know - why don't I just forget about that - it's only the designer !

Having said that, if we were to wrap all of our images into resources dll on the server, then to access them from an <img src="url"> we would need functionality that can get a bmp out of resource dll and deliver it via response stream. Which we can do using
System.Drawing.Bitmap im = new Bitmap(Assembly.GetExecutingAssembly().GetManifestResourceStream("my.bmp"));

What we are attempting to do is to get that bitmap out of the resources dll and deliver it to a control on the server  (my designer rush here) as an image, without leaving the server. Which is pointless since as sson as the control is rendered to the browser it must have a string url anyway.
I think I have been getting mixed up in my mind, basically trying to paint a web server control which cannot be done. Web server controls  deliver html which are made up of html controls that exist are painted client side, on the client machine, and are all built into windows.
The closest we could get to that would be to deliver (to the browser) an embedded control (winform control) to the browser, painted internally, using a bmp (collected from a resource dll or internal) and NOT using an url.

Basically all server controls using images use image urls (not images) because thats how they need to be when they get to the browser.

What would be nice however is if we could download a resource dll to the cache, an image or data store - and access the data from there.

Anyway, keep thinking .... personally I feel like ghost sledghammer has just wiped out my entire neural network, so it's 1hr TV and then the biiiiiiiiiig sleep.

Hope I haven't bored/confused the hell out you : you probably have as much eye strain as I do just from reading these posts !