ScriptingContext Object??

[usp004]

I am building an asp page which calls a VB Dll. I was thinking of using the ScriptingContext Object in my VB Dll so that I can write my asp code within the dll. I don't see this done all that much and I was wondering if its better to keep the the asp code in the asp page and not in the vb dll. Can someone help me with this.

Thanks.

 

[DannyB]

I would say keep things in their place, avoiding mixups. not too hard to make a dll and invoke whatever you might need from there. Maybe have properties to let you know how to output whatever in your asp page and do the testing on the asp page.

 

[jfriestman]

Be careful about writing HTML code from your dll. When your client decides he wants a red font, you don't want to have to recompile your dll.

In general however, if you want to access the ASP built in objects you have four options:

1. Use ScriptingContext (bad)
2. Use ObjectContext (good)
3. Use COM+ (better)
4. Use Property Procedures (best)

ScriptingContext is provided for backwards compatibility with IIS 3.0. If you are using IIS 4, you should be using ObjectContext. Add a reference in your VB Project to "microsoft transaction server type library" and then use code like this:
[tt]
Dim oContext as ObjectContext
Dim oResponse as Response
Set oContext = GetObjectContext()
Set oResponse = oContext("Response&quot
[/tt]

If you are using IIS 5, you will add a reference to the COM+ Services library but the VB Code remains the same.

Another way to do it is to identify what you will need from your ASP application and set that info to Properties. For example, if you need a cookie variable in your VB dll... In your ASP page:

[tt]
oMyDll.Color = Request.Cookies("color&quot("red&quot
[/tt]

Then in your dll..

[tt]
Public Property Let Color(NewValue as String)
[tab]sColor = NewValue
End Property
[/tt]

This way, if you decide you want to store the color info in a querystring or session or whatever, you don't have to recompile the dll.

Hope this helps.