Well, I've been looking at httphandlers as you know.
FrameworkSDK\Samples\QuickStart\aspplus\samples\apps\handler\cs

What you can do is this ::
put this in your web.config
<httpHandlers>
<add verb="*" path="myfile.cs" type="Acme.SimpleHandler, SimpleHandler" />
</httpHandlers>

if you set IIS to server  file extensions ".kkk" you can get the handler to specifically handle the file  of type myfile.kkk .... the extension is pretty much immaterial so you might as well use one that is already server by IIS ( namely and perhaps .resources or .cs ... the point being that a single url  maps to the handler)
So really your file doesn't even have to exist ... as long as the handler code (i.e. dll ) is in the bin

So then when you call the url ... say http://localhost/QuickStart/aspplus/samples/apps/handler/cs/myfile.cs then you can get the handler to handle it.

That handler wouldn't necessarily have to be in a sepearte dll, it could be part of your web app ... so long as you put the right type in the webconfig add verb.

So I think that may be it.

I haven't coded or tried it yet outside of messing about .... but if you specify an url for say a web controls  ImageUrl property, and you have a handler to spit out an image, both being wrapped in the same dll and in the bin, along with the altered web.config then the control  should get the generated image at runtime.

Problems that may arise are that if you wrap the handler into the same control as the server control, the the user may not (and probably wont) add that server control to the toolbox from that webapps bin (where it needs to be), and you also have to inform him to alter his web.config.

But I think the method would work  for pulling images from dll's and serving them to aspx pages via the handled url.

The great thing is that you don't even need a physical file at the url, it's handles from the dll ... so it is (sort of ) internal. But it's not fully internal  because you need to venture out just that little bit to get on the right side of a response stream. The hassles arise because you HAVE to givethe web control an ImageUrl ... and you cannot give it an image .... so you need to get on the other side of the server to collect the image.

There may be a way to handle it completely internally .... i.e. without the web.config bit ..... I (think I did) read something about adding handlers verbs programmatically.

If that can be done then there's a chance ... else th eabove outline may (as far as my knowldeg takesme) be the best solution to get it at least up and running.

I've decided to start looking at this too.
I want what everyone wants: The ability
to create thumbnails and such from a source
file, without having to save resulting files
to disk and delete them later. This seems
easy to do with a Handler. However, this
begs the question, can I access the Handler
without going outside the Image control
I create. This makes the control  self-
contained and doesn't necessitate
all this config stuff, or perhaps a config
file within the control could do the job.
Hey, here are a couple of files  I got on
the web that show another example.

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 !

Interesting stuff to think about. Since all
web output must consist of streamed bytes
and all streams must have some backing
store, it is necessary to have an <img> tag
to have an endpoint for the stream.
It is easy to create dynamic images which
are simply output to the stream, but these examples
I have sent you provide a way to direct
the stream's output to a particular device
context (the <img> tag). This is really no
different than the WinForms model of being
able to associate a Bitmap image with a control.
I think that the HttpHandler will
work fine to accomplish what I need.
After reading some articles on the web
it seems that it is necessary to keep
the handler separate from the control
which uses it, so the easiest way to
use the handler is to just place it in the
root folder of the app. I found an article
which demonstrates the use an Asynchronous
handler an I will use that to implement
my controls.