an ugly method to call an ASP script from C#/ASP.NET pages

[I like to party]

Looked all over news archives/forums for a simple solution that would work
like

<script language="c#" runat="server">

// works
Server.Execute("page.aspx");

// doesn't work - error: System.Web.HttpException: Error executing child
request for page.asp.
Server.Execute("page.asp");

</script>


Here's an ugly but fast solution to this:

<script language="c#" runat="server">
Response.Write("<iframe src='page.asp' style='display:none;'></iframe>");
</script>

 

[Scott M.]

What about Server.Transfer("page.asp")

or

System.Diagnostics.Process.Start(http://www.page.asp)

-Scott

 

[I like to party]

Server.Transfer redirects from the sender page, and sometimes you want
specifically to execute code while remaining where you were.
But regardless of this, it returns the same error - Exception Details:
System.Web.HttpException: Error executing child request for ztest.asp.

System.Diagnostics.Process.Start might eventually work as a solution, but it
appears it needs extra server settings due to a different error (below)

Description: The application attempted to perform an operation not allowed
by the security policy. To grant this application the required permission
please contact your system administrator or change the application's trust
level in the configuration file.

Exception Details: System.Security.SecurityException: Request failed.

 

[Michel Posseth [MCP]]

System.Diagnostics.Process.Start

would run the page in the context of the server process on the server side i
can`t inmagine that you would want that ( security vulnerability )

Server.Transfer redirects from the sender page, and sometimes you want
specifically to execute code while remaining where you were.

The only 2 posibilities i see is a hidden frame or hidden iframe to do that,
you choose the hidden i frame wich is a verry good solution in this case as
it makes
it more dynamic ( you could set that through a string literal in the code
behind on a postback or even in a update pannel on a asynch trigger )

HTH

Michel

 

[Gregory A. Beamer]

Looked all over news archives/forums for a simple solution that would
work like

<script language="c#" runat="server">

// works
Server.Execute("page.aspx");

// doesn't work - error: System.Web.HttpException: Error executing
child request for page.asp.
Server.Execute("page.asp");

</script>

As ASP and ASP.NET are in different process spaces, I am not surprised
that this does not work.

Here's an ugly but fast solution to this:

<script language="c#" runat="server">
Response.Write("<iframe src='page.asp'
style='display:none;'></iframe>");
</script>

I would hope, however, that this is a temporary measure and one would
not continue to support a mixed environment in this manner.

In general, there is no logical reason to use Server.Execute on an ASP
page from an ASP.NET page. The more sane approach is replace the
functionality and then deploy the new ASP.NET version. This does not
mean it is insane to have a half ASP site and half ASP.NET site, just
that it is not sane to continue to try to run the code from one environ
from another perpetually.

It is always nice to have a temporary solution when you are up against
the wall and have to quickly solve an issue. Continuing to use the
kludge is unwise, however.

Peace and Grace,

 

[Gregory A. Beamer]

Server.Transfer redirects from the sender page, and sometimes you want
specifically to execute code while remaining where you were.
But regardless of this, it returns the same error - Exception Details:
System.Web.HttpException: Error executing child request for ztest.asp.

But this leads to the question of why you would want to execute ASP code
in an ASP.NET application.

Before you answer this, think a bit. If you want to just skip ahead, I
will show you a better way.

Ready?

If you have a lot of ASP code that cannot easily be moved and you
"have" to execute it, move the code to a classic VB COM component. you
still deal with interop and have to rewrite a bit of UI code, but you
avoid kludging up ASP.NET to hold on to legacy ASP.

I understand the main argument against this, which is time and
investment, but kludging up a system has many ill effects that overrule
the time argument and chasing sunk costs is just plain stupid.

I would also argue that having all that code in an ASP page is insane. I
know the insanity is common (even in ASP.NET, where pages often contain
the entire app, as well), but common does not mean right.

Now, you might answer "but the time it takes to move the code to VB is
just as long as rewriting in ASP.NET". Bingo. You get the point. ;-)

System.Diagnostics.Process.Start might eventually work as a solution,
but it appears it needs extra server settings due to a different error
(below)

Description: The application attempted to perform an operation not
allowed by the security policy. To grant this application the
required permission please contact your system administrator or change
the application's trust level in the configuration file.

Exception Details: System.Security.SecurityException: Request failed.

This is to be expected, as you are stepping out of the apartment, or
"crossing a process boundary". You more commonly see this error when you
try to run system processes (outside of the web folders) from a web
page. The sane solution to this problem is wrap the system process in a
service that has a front end you can connect to (WCF works, for
example).

In this case, you see the error not because of running outside of the
web folder, but running outside of the ASP.NET worker process.

Either way, it is a wrongheaded solution, as ASP is run under the IIS
process (like ASP.NET) and not as a separate process. You might be able
to kludge it and make it work, if you want to earn a geek brass ring,
but it would be a nice mental exercise and not a practical solution.

Peace and Grace,

 

[Gregory A. Beamer]

What about Server.Transfer("page.asp")

Acceptable solution, as you are moving from the ASP.NET process space to
the ASP process space.

System.Diagnostics.Process.Start(http://www.page.asp)

Not going to work without destroying security, if it even works then.

Peace and Grace,

 

[Gregory A. Beamer]

Would webrequest webresponse work for this?

As the OP framed it, I would doubt it. I think the issue is there is a huge
amount of code in the ASP page that has to be run (a common mistake in ASP,
often a common mistake in ASP.NET). Running a request/response mechanism
(ie, running the ASP page) would end up with a lot of screen scrapping. A
wonderful mental exercise, as it expands the mind, but most likely not
usuable as the OP framed the question.

I like the fact that it is outside of the box, however. ;-)

Peace and Grace,

 

[Scott M.]

Here's another hack, if all you want to do is initiate the .asp page and get
it to run.

Do it via client side code embedded into the .aspx page.

In the .aspx Page_Load send down a client script of
window.location="page.asp"

-Scott

 

[Michel Posseth [MCP]]

The TS does already a simular thing only then in a hidden frame as one of
the requirments is that the page should stay as it is ( it should not
transfer to the the ASP page )
window.location.href ='http://www.bla.com' wil transfer the page from the
client side just as you typed the location in the browser


HTH
Michel ( the dumb programmer )

 

[Michel Posseth [MCP]]

eureka !

You could also do this from the code behind ( if you only goal is that the
asp page is called ) you could use a instance of the webclient object to
call the asp page from your code behind
now on your ASP.NET GUI page you could easily invoke it with a button .

http://msdn.microsoft.com/en-us/library/system.net.webclient.aspx


hth

Michel