|
|
|
date: Mon, 26 Feb 2007 22:27:53 -0500,
group: microsoft.public.platformsdk.internet.server.isapi-dev
back
Re: managed code 2nd class citizen
For me, when I say "managed code is 2nd class citizen on IIS6", I mean
that Managed code is not able to fully participate in the request
processing pipeline.
This fact is not obvious if you are just writing ASP.Net pages, but as
soon as you try to write custom authentication modules in ASP.Net and
have it apply to a non-ASP.Net resource, like an ASP page, you quickly
run into complications ultimately caused by the 2nd class nature of
managed code extensibility of IIS.
This is specifically addressed in IIS7, where both native and managed
modules are first-class citizens in the request processing pipeline
(ok, a little white lie. managed code modules are closer to 1.5 class
citizen able to do 95% of what native code modules can do, but most
people won't miss the 5%).
> Also can someone explain to me why deploying ISAPI
> extensions (maybe even filters) is usually tedious?
I do not understand the question because there is nothing
intrinsically difficult nor tedious with deploying ISAPI extensions
and filters. I think the tediousness is more an expression of
frustration resulting from users' irrational expectation that it
should be easy to do without experience.
I mean, the first time you fill up gas in a new car, it sure is
tedious because:
- is the fuel door in the driver side, passenger side, under the rear
license plate, etc
- is there a lever to pull or button to push, or manually open the
fuel door
- do I fill diesel or unleaded
- do I have to pre-pay, use a debit or credit card, or swipe a RFID
key
- etc...
I think the difficulty with deployment is not with ISAPI but rather
with understanding the deployment itself -- replicating the
dependencies and configurations specific to each application. And that
issue exists for all applications, not just ISAPI.
For example, you compile a debug ISAPI DLL on your dev box and it
works, but it fails when you copy it to the live server. You forget
that debug DLLs are linked against debug MSVCRT DLLs intentionally
placed on your dev box by the Dev environment but NOT present on live
servers. Hence, the DLL is missing dependencies on the live server and
fails to load. Oops. Darn the system for not reading my mind and
closing all my dependencies for me, automatically!
//David
http://w3-4u.logspot.com
http://blogs.msdn.com/David.Wang
//
On Feb 26, 7:27 pm, "dogface" wrote:
> First of all, I'm not a developer (reading this post you'll quickly see
> that). I'm trying to understand IIS and the world it lives in better. I'm
> a networking guy learning an entirely different language. Anyhow here is my
> question:
>
> What is it meant by when someone says that in IIS 6.0 managed code is
> treated as a 2nd classcitizen?
>
> Also can someone explain to me why deploying ISAPI extensions (maybe even
> filters) is usually tedious?
>
> I know these are probably questions that everyone in this newsgroup knows.
>
> Thanks for your help.
date: 27 Feb 2007 01:20:15 -0800
author: David Wang
Re: managed code 2nd class citizen
thank you David, that opens my eyes up.
I appreciate it.
"David Wang" wrote in message
news:1172568015.891775.147710@v33g2000cwv.googlegroups.com...
> For me, when I say "managed code is 2nd class citizen on IIS6", I mean
> that Managed code is not able to fully participate in the request
> processing pipeline.
>
> This fact is not obvious if you are just writing ASP.Net pages, but as
> soon as you try to write custom authentication modules in ASP.Net and
> have it apply to a non-ASP.Net resource, like an ASP page, you quickly
> run into complications ultimately caused by the 2nd class nature of
> managed code extensibility of IIS.
>
> This is specifically addressed in IIS7, where both native and managed
> modules are first-class citizens in the request processing pipeline
> (ok, a little white lie. managed code modules are closer to 1.5 class
> citizen able to do 95% of what native code modules can do, but most
> people won't miss the 5%).
>
>> Also can someone explain to me why deploying ISAPI
>> extensions (maybe even filters) is usually tedious?
>
> I do not understand the question because there is nothing
> intrinsically difficult nor tedious with deploying ISAPI extensions
> and filters. I think the tediousness is more an expression of
> frustration resulting from users' irrational expectation that it
> should be easy to do without experience.
>
> I mean, the first time you fill up gas in a new car, it sure is
> tedious because:
> - is the fuel door in the driver side, passenger side, under the rear
> license plate, etc
> - is there a lever to pull or button to push, or manually open the
> fuel door
> - do I fill diesel or unleaded
> - do I have to pre-pay, use a debit or credit card, or swipe a RFID
> key
> - etc...
>
> I think the difficulty with deployment is not with ISAPI but rather
> with understanding the deployment itself -- replicating the
> dependencies and configurations specific to each application. And that
> issue exists for all applications, not just ISAPI.
>
> For example, you compile a debug ISAPI DLL on your dev box and it
> works, but it fails when you copy it to the live server. You forget
> that debug DLLs are linked against debug MSVCRT DLLs intentionally
> placed on your dev box by the Dev environment but NOT present on live
> servers. Hence, the DLL is missing dependencies on the live server and
> fails to load. Oops. Darn the system for not reading my mind and
> closing all my dependencies for me, automatically!
>
>
>
> //David
> http://w3-4u.logspot.com
> http://blogs.msdn.com/David.Wang
> //
>
>
>
>
>
> On Feb 26, 7:27 pm, "dogface" wrote:
>> First of all, I'm not a developer (reading this post you'll quickly see
>> that). I'm trying to understand IIS and the world it lives in better.
>> I'm
>> a networking guy learning an entirely different language. Anyhow here is
>> my
>> question:
>>
>> What is it meant by when someone says that in IIS 6.0 managed code is
>> treated as a 2nd classcitizen?
>>
>> Also can someone explain to me why deploying ISAPI extensions (maybe even
>> filters) is usually tedious?
>>
>> I know these are probably questions that everyone in this newsgroup
>> knows.
>>
>> Thanks for your help.
>
>
date: Tue, 27 Feb 2007 09:35:22 -0500
author: dogface
Re: managed code 2nd class citizen
You're welcome.
You can browse my blogs.msdn.com blog for more info on IIS7 and IIS6
Request Pipeline. Some are in links along the side dealing with the
IIS6 Request Pipeline and you can search the blog for "IIS7" to find
the IIS7 related ones, such as on global modules, PreConditions, etc.
//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang
//
On Feb 27, 6:35 am, "dogface" wrote:
> thank you David, that opens my eyes up.
>
> I appreciate it.
>
> "David Wang" wrote in message
>
> news:1172568015.891775.147710@v33g2000cwv.googlegroups.com...
>
>
>
> > For me, when I say "managed code is 2nd class citizen on IIS6", I mean
> > that Managed code is not able to fully participate in the request
> > processing pipeline.
>
> > This fact is not obvious if you are just writing ASP.Net pages, but as
> > soon as you try to write custom authentication modules in ASP.Net and
> > have it apply to a non-ASP.Net resource, like an ASP page, you quickly
> > run into complications ultimately caused by the 2nd class nature of
> > managed code extensibility of IIS.
>
> > This is specifically addressed in IIS7, where both native and managed
> > modules are first-class citizens in the request processing pipeline
> > (ok, a little white lie. managed code modules are closer to 1.5 class
> > citizen able to do 95% of what native code modules can do, but most
> > people won't miss the 5%).
>
> >> Also can someone explain to me why deploying ISAPI
> >> extensions (maybe even filters) is usually tedious?
>
> > I do not understand the question because there is nothing
> > intrinsically difficult nor tedious with deploying ISAPI extensions
> > and filters. I think the tediousness is more an expression of
> > frustration resulting from users' irrational expectation that it
> > should be easy to do without experience.
>
> > I mean, the first time you fill up gas in a new car, it sure is
> > tedious because:
> > - is the fuel door in the driver side, passenger side, under the rear
> > license plate, etc
> > - is there a lever to pull or button to push, or manually open the
> > fuel door
> > - do I fill diesel or unleaded
> > - do I have to pre-pay, use a debit or credit card, or swipe a RFID
> > key
> > - etc...
>
> > I think the difficulty with deployment is not with ISAPI but rather
> > with understanding the deployment itself -- replicating the
> > dependencies and configurations specific to each application. And that
> > issue exists for all applications, not just ISAPI.
>
> > For example, you compile a debug ISAPI DLL on your dev box and it
> > works, but it fails when you copy it to the live server. You forget
> > that debug DLLs are linked against debug MSVCRT DLLs intentionally
> > placed on your dev box by the Dev environment but NOT present on live
> > servers. Hence, the DLL is missing dependencies on the live server and
> > fails to load. Oops. Darn the system for not reading my mind and
> > closing all my dependencies for me, automatically!
>
> > //David
> >http://w3-4u.logspot.com
> >http://blogs.msdn.com/David.Wang
> > //
>
> > On Feb 26, 7:27 pm, "dogface" wrote:
> >> First of all, I'm not a developer (reading this post you'll quickly see
> >> that). I'm trying to understand IIS and the world it lives in better.
> >> I'm
> >> a networking guy learning an entirely different language. Anyhow here is
> >> my
> >> question:
>
> >> What is it meant by when someone says that in IIS 6.0 managed code is
> >> treated as a 2nd classcitizen?
>
> >> Also can someone explain to me why deploying ISAPI extensions (maybe even
> >> filters) is usually tedious?
>
> >> I know these are probably questions that everyone in this newsgroup
> >> knows.
>
> >> Thanks for your help.- Hide quoted text -
>
> - Show quoted text -
date: 27 Feb 2007 17:50:17 -0800
author: David Wang
|
|
