CGI C# Executables on IIS6

Hi

I have read reams of info regarding the ability to use C# for CGI, and tried
loads of approaches. I am getting a mixed message. Microsoft documentation
indicates that references to .exe cgi files won't work. That seems to be
verified through numerous attempts. But there is always the vague inference
that it is possible. I have found references that say that if I create an
intermediate file such as CGI.CSX, and add that Service Extension, it should
work. So far it doesn't. I hate to say this, but I have been trying to do
this for a week with no success. Should I acknowledge defeat and go back to
Perl? Or is there a way?

Thanks in Advance
Don Bretz

Re: CGI C# Executables on IIS6

Don wrote on Tue, 8 Apr 2008 06:53:00 -0700:

> Hi

> I have read reams of info regarding the ability to use C# for CGI, and
> tried loads of approaches. I am getting a mixed message. Microsoft
> documentation indicates that references to .exe cgi files won't work.
> That seems to be verified through numerous attempts. But there is
> always the vague inference that it is possible. I have found
> references that say that if I create an intermediate file such as
> CGI.CSX, and add that Service Extension, it should work. So far it
> doesn't. I hate to say this, but I have been trying to do this for a
> week with no success. Should I acknowledge defeat and go back to
> Perl? Or is there a way?


I haven't touched .NET yet, but are you sure you took all the steps required
to get your CGI to be allowed to run? You need to check the permissions on
the executable itself, and also make sure it has been placed in a directory
that in IIS has been set to allow Scripts and Executables, and it appears
that you should stick to .exe for the extension. There are plenty of pages
showing that it does work, at least on IIS5. Have you tried running IIS6 in
IIS5 mode?

The uise of a CSX file (it could be called anything) is simply to call the
CGI without having the CGI itself within the web directory structure - but
you don't create the Service Extension referencing the CSX, you create an
Application Extension Mapping which maps .CSX onto your C# executable. Then
you create a Web Service Extension for a .csx file (eg. your CGI.CSX), and
then request it via IIS - this triggers the C# executable because you've
requested a .CSX file and the executable is called in a similar way to a
script handler such as ASP.DLL.

In the logs, what is the error code shown? That might give a better idea as
to what is preventing it from working. You haven't provided any details on
what errors you're seeing or exactly what steps you've taken so far, making
it hard to determine what the issue might be.

--
Dan

Re: CGI C# Executables on IIS6

On Apr 8, 6:53=A0am, Don Bretz
wrote:
> Hi
>
> I have read reams of info regarding the ability to use C# for CGI, and tri=
ed
> loads of approaches. I am getting a mixed message. Microsoft documentation=

> indicates that references to .exe cgi files won't work. That seems to be
> verified through numerous attempts. But there is always the vague inferenc=
e
> that it is possible. I have found references that say that if I create an
> intermediate file such as CGI.CSX, and add that Service Extension, it shou=
ld
> work. So far it doesn't. I hate to say this, but I have been trying to do
> this for a week with no success. Should I acknowledge defeat and go back t=
o
> Perl? Or is there a way?
>
> Thanks in Advance
> Don Bretz


Why don't you just use ASP.Net? It is the best approach to use C# to
handle web requests.

Managed Code executed as CGI EXE on Windows Platform is about the
worst possible choice.

Managed Code requires CLR, which takes non-negligible amount of time
to load into a process -- and CGI EXE is a process that is spawned on
demand and immediately terminated -- so every request to the CGI EXE
will incur the CLR load time. Furthermore, since CGI is executed
single-threaded and single-instance, concurrent requests to the
Managed CGI EXE will load multiple copies of CLR, each taking the CLR
Load time hit. In short, C# for CGI is about the worst possible design
choice.

The references such as CGI.CSX and adding Web Service Extension will
also work, but why? IIS is able to launch the CGI EXE directly with
CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
that simply changes the request extension and little else.

FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
for exactly the same reasons as Managed CGI EXE. ISAPI DLL
implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
PHP ISAPI.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: CGI C# Executables on IIS6

"David Wang" wrote:

> On Apr 8, 6:53 am, Don Bretz
> wrote:
> > Hi
> >
> > I have read reams of info regarding the ability to use C# for CGI, and tried
> > loads of approaches. I am getting a mixed message. Microsoft documentation
> > indicates that references to .exe cgi files won't work. That seems to be
> > verified through numerous attempts. But there is always the vague inference
> > that it is possible. I have found references that say that if I create an
> > intermediate file such as CGI.CSX, and add that Service Extension, it should
> > work. So far it doesn't. I hate to say this, but I have been trying to do
> > this for a week with no success. Should I acknowledge defeat and go back to
> > Perl? Or is there a way?
> >
> > Thanks in Advance
> > Don Bretz
>
>
> Why don't you just use ASP.Net? It is the best approach to use C# to
> handle web requests.
>
> Managed Code executed as CGI EXE on Windows Platform is about the
> worst possible choice.
>
> Managed Code requires CLR, which takes non-negligible amount of time
> to load into a process -- and CGI EXE is a process that is spawned on
> demand and immediately terminated -- so every request to the CGI EXE
> will incur the CLR load time. Furthermore, since CGI is executed
> single-threaded and single-instance, concurrent requests to the
> Managed CGI EXE will load multiple copies of CLR, each taking the CLR
> Load time hit. In short, C# for CGI is about the worst possible design
> choice.
>
> The references such as CGI.CSX and adding Web Service Extension will
> also work, but why? IIS is able to launch the CGI EXE directly with
> CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
> that simply changes the request extension and little else.
>
> FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
> PHP ISAPI.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

Thanks for the reply. I do use your alternatives, but the "Why" is to
satisfy a curiosity and, to add a bit of knowledge to the tool bag. I found
so much information (pro and con) on the subject, I wanted to see for myself.
A common point made was that C can be used to improve the server side
throughput. I wanted to compare with a set of matching compiled C# methods.
Purely academic. But, sometimes I am supprised by the gems that surface.

Don

Re: CGI C# Executables on IIS6

On Apr 15, 5:42=A0am, Don Bretz
wrote:
> "David Wang" wrote:
> > On Apr 8, 6:53 am, Don Bretz
> > wrote:
> > > Hi
>
> > > I have read reams of info regarding the ability to use C# for CGI, and=
tried
> > > loads of approaches. I am getting a mixed message. Microsoft documenta=
tion
> > > indicates that references to .exe cgi files won't work. That seems to =
be
> > > verified through numerous attempts. But there is always the vague infe=
rence
> > > that it is possible. I have found references that say that if I create=
an
> > > intermediate file such as CGI.CSX, and add that Service Extension, it =
should
> > > work. So far it doesn't. I hate to say this, but I have been trying to=
do
> > > this for a week with no success. Should I acknowledge defeat and go ba=
ck to
> > > Perl? Or is there a way?
>
> > > Thanks in Advance
> > > Don Bretz
>
> > Why don't you just use ASP.Net? It is the best approach to use C# to
> > handle web requests.
>
> > Managed Code executed as CGI EXE on Windows Platform is about the
> > worst possible choice.
>
> > Managed Code requires CLR, which takes non-negligible amount of time
> > to load into a process -- and CGI EXE is a process that is spawned on
> > demand and immediately terminated -- so every request to the CGI EXE
> > will incur the CLR load time. Furthermore, since CGI is executed
> > single-threaded and single-instance, concurrent requests to the
> > Managed CGI EXE will load multiple copies of CLR, each taking the CLR
> > Load time hit. In short, C# for CGI is about the worst possible design
> > choice.
>
> > The references such as CGI.CSX and adding Web Service Extension will
> > also work, but why? IIS is able to launch the CGI EXE directly with
> > CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
> > that simply changes the request extension and little else.
>
> > FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> > for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> > implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
> > PHP ISAPI.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> Thanks for the reply. I do use your alternatives, but the "Why" is to
> satisfy a curiosity and, to add a bit of knowledge to the tool bag. I foun=
d
> so much information (pro and con) on the subject, I wanted to see for myse=
lf.
> A common point made was that C can be used to improve the server side
> throughput. I wanted to compare with a set of matching compiled C# methods=
..
> Purely academic. But, sometimes I am supprised by the gems that surface.
>
> Don- Hide quoted text -
>
> - Show quoted text -


I am actually concerned about the validity of the documentation and
information you are reading. We all know the Internet is full of
misinformation.

1. What "Microsoft documentation indicates that references to .exe cgi
files won't work" ? Exact URL would be good starting point.
2. "I have found references that say that if I create an intermediate
file such as CGI.CSX, and add that Service Extension, it should work."
I do not believe the source of that information understands what
is going on:
- Prior to IIS6, running CGI just requires "Scripts and
Executables" Execute Permissions
- IIS6 requires a Web Service Extension enabling the specific CGI
along with the "Scripts and Executables" permissions
- IIS7 requires the CGI Feature installed in addition to IIS6's
requirements

Anything else is extraneous. I'm not saying they won't work; I'm
just saying that it shows a lack of understanding of the basics. And
the fact that it gets interpreted as "experience" is more frightening.


//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//

Re: CGI C# Executables on IIS6

"David Wang" wrote:

> On Apr 15, 5:42 am, Don Bretz
> wrote:
> > "David Wang" wrote:
> > > On Apr 8, 6:53 am, Don Bretz
> > > wrote:
> > > > Hi
> >
> > > > I have read reams of info regarding the ability to use C# for CGI, and tried
> > > > loads of approaches. I am getting a mixed message. Microsoft documentation
> > > > indicates that references to .exe cgi files won't work. That seems to be
> > > > verified through numerous attempts. But there is always the vague inference
> > > > that it is possible. I have found references that say that if I create an
> > > > intermediate file such as CGI.CSX, and add that Service Extension, it should
> > > > work. So far it doesn't. I hate to say this, but I have been trying to do
> > > > this for a week with no success. Should I acknowledge defeat and go back to
> > > > Perl? Or is there a way?
> >
> > > > Thanks in Advance
> > > > Don Bretz
> >
> > > Why don't you just use ASP.Net? It is the best approach to use C# to
> > > handle web requests.
> >
> > > Managed Code executed as CGI EXE on Windows Platform is about the
> > > worst possible choice.
> >
> > > Managed Code requires CLR, which takes non-negligible amount of time
> > > to load into a process -- and CGI EXE is a process that is spawned on
> > > demand and immediately terminated -- so every request to the CGI EXE
> > > will incur the CLR load time. Furthermore, since CGI is executed
> > > single-threaded and single-instance, concurrent requests to the
> > > Managed CGI EXE will load multiple copies of CLR, each taking the CLR
> > > Load time hit. In short, C# for CGI is about the worst possible design
> > > choice.
> >
> > > The references such as CGI.CSX and adding Web Service Extension will
> > > also work, but why? IIS is able to launch the CGI EXE directly with
> > > CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
> > > that simply changes the request extension and little else.
> >
> > > FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> > > for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> > > implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
> > > PHP ISAPI.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > Thanks for the reply. I do use your alternatives, but the "Why" is to
> > satisfy a curiosity and, to add a bit of knowledge to the tool bag. I found
> > so much information (pro and con) on the subject, I wanted to see for myself.
> > A common point made was that C can be used to improve the server side
> > throughput. I wanted to compare with a set of matching compiled C# methods..
> > Purely academic. But, sometimes I am supprised by the gems that surface.
> >
> > Don- Hide quoted text -
> >
> > - Show quoted text -
>
>
> I am actually concerned about the validity of the documentation and
> information you are reading. We all know the Internet is full of
> misinformation.
>
> 1. What "Microsoft documentation indicates that references to .exe cgi
> files won't work" ? Exact URL would be good starting point.
> 2. "I have found references that say that if I create an intermediate
> file such as CGI.CSX, and add that Service Extension, it should work."
> I do not believe the source of that information understands what
> is going on:
> - Prior to IIS6, running CGI just requires "Scripts and
> Executables" Execute Permissions
> - IIS6 requires a Web Service Extension enabling the specific CGI
> along with the "Scripts and Executables" permissions
> - IIS7 requires the CGI Feature installed in addition to IIS6's
> requirements
>
> Anything else is extraneous. I'm not saying they won't work; I'm
> just saying that it shows a lack of understanding of the basics. And
> the fact that it gets interpreted as "experience" is more frightening.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>


David.

I certainly appreciate the time you are giving to my problem. I have reread
the mass of references I found on this subject and I correct my original
statement about MS documentation stating that .exe cgi files won't work. It
seems more of a security warning regarding enabling all unknown CGi
extentions, of which .exe seems to be one.

I have tested a simple a pair of matching CGI files. One in ActivePerl 5.8
and the other in Watcom c just to back away from C# for the moment. The Perl
works and the c doesn't. I have documented both tests in the comments of the
c program and include it below. Since I am having the same issue with the c
based CGI, I am convinced I have missed some crutial piece of configuration
and, I have reached that point of working in circles.




/* Goal: CGI using c .exe.
A fallback test on the road to using C#.

This Watcom c program fails, but the Perl
script in the trailing comment run fine from
the same virtual directory (CGI). See "Sanity
Check" below. Also tried this all on another
2003 server. Results same.

This c program returns "The page cannot be found".
Other Watcom c programs run fine on this server.
(I switched to c from C# since it is also advertised
to work. Still want C# to work)

The environment is:
Windows 2003, SP2
Internet Explorer 7
IIS 6, Anonymous enabled
Virtual directory, CGI, is in default WEB site.
Execute permissions: Scripts and Executables
IUSR_DJBMSI64 granted: Read and Execute
run as local administrator.

Tried:
http://localhost/CGI/HelloWorld_C.exe
Where:
"All Unknown GCI Extentions" is set to Allowed.
Restarted IIS after change.
"The page cannot be found"

Also tried:
http://localhost/CGI/HelloWorld_C.xyz
Where:
New Web Service Extention was added via IIS Manager.
File Name: C:\CGI\HelloWorld_C.exe
Status: Allowed
After IIS service restart, Entry in
WebSvcRestrictionList:
1,C:\CGI\HelloWorld_C.exe,1,,.xyz
"The page cannot be found"
HTTP Error 404 - File or directory not found.

Log Entry:
#Software: Microsoft Internet Information Services 6.0
#Version: 1.0
#Date: 2008-04-22 11:40:27
#Fields: date time s-ip cs-method cs-uri-stem
cs-uri-query s-port cs-username c-ip
cs(User-Agent) sc-status sc-substatus sc-win32-status

2008-04-22 11:40:27 127.0.0.1 GET
/CGI/HelloWorld_C.xyz - 80 - 127.0.0.1 Mozilla/4.0
+(compatible;+MSIE+7.0;
+Windows+NT+5.2;+.NET+CLR+1.1.4322;
+.NET+CLR+2.0.50727;+.NET+CLR+3.0.04506.648;
+.NET+CLR+3.5.21022) 404 0 0


*/

#include

int main() {
printf("Content-Type: text/html\r\n\r\n");
printf(" \n");
printf("\n");
printf("\n");
printf("\n");
printf("

Hello, World!

Hello, world!

Re: CGI C# Executables on IIS6

"David Wang" wrote:

> On Apr 15, 5:42 am, Don Bretz
> wrote:
> > "David Wang" wrote:
> > > On Apr 8, 6:53 am, Don Bretz
> > > wrote:
> > > > Hi
> >
> > > > I have read reams of info regarding the ability to use C# for CGI, and tried
> > > > loads of approaches. I am getting a mixed message. Microsoft documentation
> > > > indicates that references to .exe cgi files won't work. That seems to be
> > > > verified through numerous attempts. But there is always the vague inference
> > > > that it is possible. I have found references that say that if I create an
> > > > intermediate file such as CGI.CSX, and add that Service Extension, it should
> > > > work. So far it doesn't. I hate to say this, but I have been trying to do
> > > > this for a week with no success. Should I acknowledge defeat and go back to
> > > > Perl? Or is there a way?
> >
> > > > Thanks in Advance
> > > > Don Bretz
> >
> > > Why don't you just use ASP.Net? It is the best approach to use C# to
> > > handle web requests.
> >
> > > Managed Code executed as CGI EXE on Windows Platform is about the
> > > worst possible choice.
> >
> > > Managed Code requires CLR, which takes non-negligible amount of time
> > > to load into a process -- and CGI EXE is a process that is spawned on
> > > demand and immediately terminated -- so every request to the CGI EXE
> > > will incur the CLR load time. Furthermore, since CGI is executed
> > > single-threaded and single-instance, concurrent requests to the
> > > Managed CGI EXE will load multiple copies of CLR, each taking the CLR
> > > Load time hit. In short, C# for CGI is about the worst possible design
> > > choice.
> >
> > > The references such as CGI.CSX and adding Web Service Extension will
> > > also work, but why? IIS is able to launch the CGI EXE directly with
> > > CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
> > > that simply changes the request extension and little else.
> >
> > > FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> > > for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> > > implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
> > > PHP ISAPI.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > Thanks for the reply. I do use your alternatives, but the "Why" is to
> > satisfy a curiosity and, to add a bit of knowledge to the tool bag. I found
> > so much information (pro and con) on the subject, I wanted to see for myself.
> > A common point made was that C can be used to improve the server side
> > throughput. I wanted to compare with a set of matching compiled C# methods..
> > Purely academic. But, sometimes I am supprised by the gems that surface.
> >
> > Don- Hide quoted text -
> >
> > - Show quoted text -
>
>
> I am actually concerned about the validity of the documentation and
> information you are reading. We all know the Internet is full of
> misinformation.
>
> 1. What "Microsoft documentation indicates that references to .exe cgi
> files won't work" ? Exact URL would be good starting point.
> 2. "I have found references that say that if I create an intermediate
> file such as CGI.CSX, and add that Service Extension, it should work."
> I do not believe the source of that information understands what
> is going on:
> - Prior to IIS6, running CGI just requires "Scripts and
> Executables" Execute Permissions
> - IIS6 requires a Web Service Extension enabling the specific CGI
> along with the "Scripts and Executables" permissions
> - IIS7 requires the CGI Feature installed in addition to IIS6's
> requirements
>
> Anything else is extraneous. I'm not saying they won't work; I'm
> just saying that it shows a lack of understanding of the basics. And
> the fact that it gets interpreted as "experience" is more frightening.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>

David...

An amazing thing just happened! In the message I posted to you a few minutes
ago, there are three links I had used to test the perl, .exe, and .xyz CGI
entries. Only the Perl had worked. But, I clicked the .exe link in the
message and it worked! The .xyz still doesn't work, and the .pl continues to
work. ALSO, the .exe file now works from a new IE7 page.

I am now going to create a new C# .exe that matches the Watcom c version and
try it.

Don

Re: CGI C# Executables on IIS6

"David Wang" wrote:

> On Apr 15, 5:42 am, Don Bretz
> wrote:
> > "David Wang" wrote:
> > > On Apr 8, 6:53 am, Don Bretz
> > > wrote:
> > > > Hi
> >
> > > > I have read reams of info regarding the ability to use C# for CGI, and tried
> > > > loads of approaches. I am getting a mixed message. Microsoft documentation
> > > > indicates that references to .exe cgi files won't work. That seems to be
> > > > verified through numerous attempts. But there is always the vague inference
> > > > that it is possible. I have found references that say that if I create an
> > > > intermediate file such as CGI.CSX, and add that Service Extension, it should
> > > > work. So far it doesn't. I hate to say this, but I have been trying to do
> > > > this for a week with no success. Should I acknowledge defeat and go back to
> > > > Perl? Or is there a way?
> >
> > > > Thanks in Advance
> > > > Don Bretz
> >
> > > Why don't you just use ASP.Net? It is the best approach to use C# to
> > > handle web requests.
> >
> > > Managed Code executed as CGI EXE on Windows Platform is about the
> > > worst possible choice.
> >
> > > Managed Code requires CLR, which takes non-negligible amount of time
> > > to load into a process -- and CGI EXE is a process that is spawned on
> > > demand and immediately terminated -- so every request to the CGI EXE
> > > will incur the CLR load time. Furthermore, since CGI is executed
> > > single-threaded and single-instance, concurrent requests to the
> > > Managed CGI EXE will load multiple copies of CLR, each taking the CLR
> > > Load time hit. In short, C# for CGI is about the worst possible design
> > > choice.
> >
> > > The references such as CGI.CSX and adding Web Service Extension will
> > > also work, but why? IIS is able to launch the CGI EXE directly with
> > > CreateProcessAsUser() as CGI.EXE -- no need for an Application Mapping
> > > that simply changes the request extension and little else.
> >
> > > FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> > > for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> > > implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAPI,
> > > PHP ISAPI.
> >
> > > //David
> > >http://w3-4u.blogspot.com
> > >http://blogs.msdn.com/David.Wang
> > > //
> >
> > Thanks for the reply. I do use your alternatives, but the "Why" is to
> > satisfy a curiosity and, to add a bit of knowledge to the tool bag. I found
> > so much information (pro and con) on the subject, I wanted to see for myself.
> > A common point made was that C can be used to improve the server side
> > throughput. I wanted to compare with a set of matching compiled C# methods..
> > Purely academic. But, sometimes I am supprised by the gems that surface.
> >
> > Don- Hide quoted text -
> >
> > - Show quoted text -
>
>
> I am actually concerned about the validity of the documentation and
> information you are reading. We all know the Internet is full of
> misinformation.
>
> 1. What "Microsoft documentation indicates that references to .exe cgi
> files won't work" ? Exact URL would be good starting point.
> 2. "I have found references that say that if I create an intermediate
> file such as CGI.CSX, and add that Service Extension, it should work."
> I do not believe the source of that information understands what
> is going on:
> - Prior to IIS6, running CGI just requires "Scripts and
> Executables" Execute Permissions
> - IIS6 requires a Web Service Extension enabling the specific CGI
> along with the "Scripts and Executables" permissions
> - IIS7 requires the CGI Feature installed in addition to IIS6's
> requirements
>
> Anything else is extraneous. I'm not saying they won't work; I'm
> just saying that it shows a lack of understanding of the basics. And
> the fact that it gets interpreted as "experience" is more frightening.
>
>
> //David
> http://w3-4u.blogspot.com
> http://blogs.msdn.com/David.Wang
> //
>


David...

I now have both Perl and C CGIs working well, and moved back to C#.
I am using the following C# version of the c program.

using System;

namespace HelloWorld_CGI_CS_Demo
{
class Program
{
static void Main()
{
Console.Write("Content-Type: text/html\n\n");
Console.Write("");
Console.Write("

Hello

Re: CGI C# Executables on IIS6

On Apr 23, 12:08=A0pm, Don Bretz
wrote:
> "David Wang" wrote:
> > On Apr 15, 5:42 am, Don Bretz
> > wrote:
> > > "David Wang" wrote:
> > > > On Apr 8, 6:53 am, Don Bretz
> > > > wrote:
> > > > > Hi
>
> > > > > I have read reams of info regarding the ability to use C# for CGI,=
and tried
> > > > > loads of approaches. I am getting a mixed message. Microsoft docum=
entation
> > > > > indicates that references to .exe cgi files won't work. That seems=
to be
> > > > > verified through numerous attempts. But there is always the vague =
inference
> > > > > that it is possible. I have found references that say that if I cr=
eate an
> > > > > intermediate file such as CGI.CSX, and add that Service Extension,=
it should
> > > > > work. So far it doesn't. I hate to say this, but I have been tryin=
g to do
> > > > > this for a week with no success. Should I acknowledge defeat and g=
o back to
> > > > > Perl? Or is there a way?
>
> > > > > Thanks in Advance
> > > > > Don Bretz
>
> > > > Why don't you just use ASP.Net? It is the best approach to use C# to=

> > > > handle web requests.
>
> > > > Managed Code executed as CGI EXE on Windows Platform is about the
> > > > worst possible choice.
>
> > > > Managed Code requires CLR, which takes non-negligible amount of time=

> > > > to load into a process -- and CGI EXE is a process that is spawned o=
n
> > > > demand and immediately terminated -- so every request to the CGI EXE=

> > > > will incur the CLR load time. Furthermore, since CGI is executed
> > > > single-threaded and single-instance, concurrent requests to the
> > > > Managed CGI EXE will load multiple copies of CLR, each taking the CL=
R
> > > > Load time hit. In short, C# for CGI is about the worst possible desi=
gn
> > > > choice.
>
> > > > The references such as CGI.CSX and adding Web Service Extension will=

> > > > also work, but why? IIS is able to launch the CGI EXE directly with
> > > > CreateProcessAsUser() as CGI.EXE -- no need for an Application Mappi=
ng
> > > > that simply changes the request extension and little else.
>
> > > > FYI: Running Perl.exe as CGI on Windows is likewise a poor approach
> > > > for exactly the same reasons as Managed CGI EXE. ISAPI DLL
> > > > implementation is the way to go on Windows -- ASP, ASP.Net Perl ISAP=
I,
> > > > PHP ISAPI.
>
> > > > //David
> > > >http://w3-4u.blogspot.com
> > > >http://blogs.msdn.com/David.Wang
> > > > //
>
> > > Thanks for the reply. I do use your alternatives, but the "Why" is to
> > > satisfy a curiosity and, to add a bit of knowledge to the tool bag. I =
found
> > > so much information (pro and con) on the subject, I wanted to see for =
myself.
> > > A common point made was that C can be used to improve the server side
> > > throughput. I wanted to compare with a set of matching compiled C# met=
hods..
> > > Purely academic. But, sometimes I am supprised by the gems that surfac=
e.
>
> > > Don- Hide quoted text -
>
> > > - Show quoted text -
>
> > I am actually concerned about the validity of the documentation and
> > information you are reading. We all know the Internet is full of
> > misinformation.
>
> > 1. What "Microsoft documentation indicates that references to .exe cgi
> > files won't work" ? Exact URL would be good starting point.
> > 2. "I have found references that say that if I create an intermediate
> > file such as CGI.CSX, and add that Service Extension, it should work."
> > =A0 =A0 I do not believe the source of that information understands what=

> > is going on:
> > =A0 =A0 - Prior to IIS6, running CGI just requires "Scripts and
> > Executables" Execute Permissions
> > =A0 =A0 - IIS6 requires a Web Service Extension enabling the specific CG=
I
> > along with the "Scripts and Executables" permissions
> > =A0 =A0 - IIS7 requires the CGI Feature installed in addition to IIS6's
> > requirements
>
> > =A0 =A0 Anything else is extraneous. I'm not saying they won't work; I'm=

> > just saying that it shows a lack of understanding of the basics. And
> > the fact that it gets interpreted as "experience" is more frightening.
>
> > //David
> >http://w3-4u.blogspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> David...
>
> I now have both Perl and C CGIs working well, and moved back to C#.
> I am using the following C# version of the c program.
>
> using System;
>
> namespace HelloWorld_CGI_CS_Demo
> {
> =A0 class Program
> =A0 {
> =A0 =A0 static void Main()
> =A0 =A0 {
> =A0 =A0 =A0 Console.Write("Content-Type: text/html\n\n");
> =A0 =A0 =A0 Console.Write("")=
;
> =A0 =A0 =A0 Console.Write("

Hello