Hello Brian,

Why not to create the control for this?
or expose the interface with method with output string where your content
is rendered?

---
WBR,  Michael  Nemtsev [.NET/C# MVP].  
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

BC> I've developed software (vb.net) that renders maps using svg. My
BC> manager would like this "mapping component" to be migrated into a
BC> library so it can easily be used by other web based applications. So
BC> far so good.
BC>
BC> However, the page that generates the svg (currently a .aspx file)
BC> writes directly to response. Unless I'm being silly, it doesn't look
BC> like I can put a .aspx file into a web control library, so what
BC> would be the best way to tackle what I need to achieve?
BC>
BC> TIA.
BC>

Hi,

You could "pack" the functionality in a custom class, deriving from
System.Web.UI.Page. Then, let your ASPX inherit from your custom page
instead of System.Web.UI.Page.

I use this a lot, for example to "pack" a method allowing to let an ASPX
page save itself to a static HTML "snapshot".

HTH,
Laurent

Consider converting it into a user control in .ascx file.

My advice is going to be a bit different from the others.

I suggest that you abstract as far away from ASP.NET as you can, but a step
at a time.

Step 1: When you do a Response.Write(string), you're pretty much doing the
same thing as Response.Output.Write(string). Same for the other overloads of
Response.Write. So, first, try replacing one of the uses of Response.Write
with Response.Output.Write. Then Test. If it works, replace another one.
Then Test. If you get bored, you can replace all the references to
Response.Write with Response.Output.Write. Then Test. If it works, you can
go on to step 2.

Step 2: Find your lowest-level Sub or Function that calls
Response.Output.Write. By this I mean the Sub that calls
Response.Output.Write, but which does not call any other Sub or Function
that calls Response.Output.Write. Let's say that Sub is like this:

Sub LowLevelWrite(arg0 As Integer, arg1 As String)
'...
   Response.Output.Write(Something)
'...
End Sub

Change it as follows:

Sub LowLevelWrite(arg0 As Integer, arg1 As String, writer As TextWriter)
'...
   writer.Write(Something)
'...
End Sub

Locate the callers of LowLevelWrite (that should be easy, since they won't
build!) and add a third parameter:

' Old:
   LowLevelWrite(1, "One")

' New:
   LowLevelWrite(1, "One", Response.Output)

After making those changes, Test. If it works, do the same for all your
other methods that call Response.Output.Write. Do it from the innermost
outwards, and you'll eventually have only the outermost parts of your code
that reference Response.Output. Remember to Test. When it all works, go on
to step 3.

Step 3: Since this is a Web Application, your remaining references to
Response.Output will probably be in event handlers and possibly in the
markup. Find one of the event handlers that still references
Response.Output. If it's simple, then leave it alone and go on to the next
one.

When you find a handler of significant size, you'll need to turn most of it
into one or more separate Subs or Functions. This can take a while if you do
it by hand, so I can only show you the ultimate result.

' Old:
Sub btnSubmit_Click _
   Handles btnSubmit.Click    ' Pardon any syntax errors, it's been a while
'...
   LowLevel1(intVar1, stringVar1, Response.Output)
   LowLevel2(intVar2, stringVar2, Response.Output)
'...
End Sub

' New:
Sub btnSubmit_Click _
   Handles btnSubmit.Click    ' Pardon any syntax errors, it's been a while
'...
   Separate(intVar1, intVar2, stringVar1, stringVar2, writer)
'...
End Sub

Sub Separate(intVar1 As Integer, intVar2 As Integer, stringVar1 As String,
stringVar2 As String, writer As TextWriter)
'...
   LowLevel1(intVar1, stringVar1, writer)
   LowLevel2(intVar2, stringVar2, writer)
'...
End Sub

This is called an "Extract Method" refactoring. Do it a little at a time,
and Test frequently.

If you do this for all the handlers that reference Response.Output, you'll
get to the point where the only code that still references Response.Output
is in your event handlers, which are pretty specific to ASP.NET web pages
anyway. You'll be in a better position to separate the code that isn't
web-page specific into separate classes (do it a little at a time, and
Test).

When you're done with all that, the part you separated out will be your
library. And, because you tested so frequently, you will not have broken
anything (or not much) in the process.

If this is important to your manager, he should spring for the $200 for a
ReSharper license. Version 3.0, recently released, now supports VB.Net. See
http://www.jetbrains.com/resharper/features/newfeatures.html#Editor_Enhancement.

Good luck with this. It's the sort of thing that can be fun, assuming that
you Test frequently enough to have confidence that you aren't breaking
anything.