MFC ISAPI Template and ISAPI Development

Question:

I've read on msdn that for Visual Studio 2005 the MFC ISAPI extension template was discontinued and that for new development "ISAPI entry point functions" should be used instead.

I'm interpreting that as the MFC isapi classes are problematic. Could you give some honest commentary regarding the issues?

I've looked at my mfc isapi that I would like to update and can eliminate the dependency on mfc with own C++ classes.

From a practical standpoint, I was wondering if 2005 Standard Edition would do me any good since MFC is included, but since it isn't being encouraged I thought I would just continue my project using Express and really get to know ISAPI (which has been fun so far and not as hard as I thought).

Answer:

I presume you are referencing the following documents:

• https://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcedit/html/vcgrfVisualCppStandardEditionFeatures.asp
• https://support.microsoft.com/?id=910382

Actually, I do not interpret the removal of MFC ISAPI Template as an indication of it being problematic. Instead, I will phrase its removal as closer to:

• "Low popularity" relative to other project types (i.e. is it really as popular as a CLR Console Application or Windows Forms Application?)
• ISAPI is not intrinsically .NET-anything
• ATL Server actually provides a usable framework on top of ISAPI that connects with .NET, while MFC ISAPI Template offers little

In other words, from a .NET perspective, pure ISAPI development is out-of-date, so the costs of maintaining such a template project does not make sense. Plus, ATL Server has a future while MFC ISAPI Template never offered much... so the choice is pretty clear.

Frankly, I have no problems with the removal of MFC ISAPI Template. If I could roll back time, I actually wish that the Visual C++ team never introduced the MFC ISAPI Template because it simply introduces ISAPI developers to an abstraction and dependency layer on top of ISAPI which offers no benefits to the developer. How so?

The Template attempts to snap a MFC Windows Application-like feel on top of ISAPI, which is a fundamentally incompatible paradigm that never made sense. And it does not help with the tricky parts of HTTP and ISAPI that developers actually need help with.

Why NOT MFC ISAPI Template

For example, the global CMyApp object makes no sense for ISAPI because HTTP is intrinsically stateless - so it is more important to keep per-request state and global "Server functions". But, CMyApp does not provide those useful things that developers want, like configurable per-request state (i.e. custom session state implementation) nor any global "Server functions" (i.e. customizable response caching implementation)... so it really fails to make the ISAPI developer's life easier.

Another example is the PARSE_MAP. It is a wonder abstraction for Windows Applications, but in the HTTP world, all it does is force a certain proprietary querystring parse pattern, and PARSE_MAP is not so good at malformed querystrings nor malformed PARSE_MAPs, either. It is infinitely more useful for PARSE_MAP to provide the standard parse/decoding for HTML Form variables because that is a more likely source of input values - an ISAPI handing a FORM POST or FORM GET - and the ISAPI needs an easy way to parse/retrieve form variables by name and act on them. Once again, opportunity missed.

Then, there is the debacle with its wrapping of ISAPI Filter HTTP_FILTER_CONTEXT or ISAPI Extension EXTENSION_CONTROL_BLACK. Instead of introducing a secure paradigm of request handling and helping developers correctly use ISAPI function calls like GetServerVariable(), WriteClient(), or GetHeader(), it basically thinly wraps those API calls and leaves the developers to fend for themselves. This provides absolutely no value-add to the developer; you are just as likely to misuse the ISAPI function call with or without the framework; so where is the value-add for taking a dependency?

My Take...

MFC makes sense for Windows Application because it introduces a compatible paradigm which removes much of the boiler-plate code you otherwise have to write for Win32. This is not what MFC ISAPI Template offers.

So... I would never recommend anyone use the MFC ISAPI Template. It is useless from my perspective - offers no benefits and adds a complexity and dependency layer into my ISAPI. I always write my ISAPIs as a plain Win32 DLL which exports the required ISAPI function signatures for IIS to load and use. Lean and to the point.

Now, I do not recommend rolling your own C++ classes to handle a lot of the basic ISAPI chores... that's the stuff that a real framework/template SHOULD provide you. So, what ISAPI framework do I recommend people to use? For an example of a good lightweight ISAPI Framework, check out ISAPITools.h from the latest IIS Platform SDK.

Wade wrote it to make ISAPI easier to use, providing useful abstractions like an efficient and resizable buffer, functions for logical ISAPI tasks like retrieving server variables, reading entity body, decoding common HTTP encodings, avoiding all the classic ISAPI mistakes, and generally illustrating the Right Way (TM) to do things in ISAPI.

Conclusion

In other words, the MFC ISAPI Template is not a deciding factior between Visual C++ 2005 Express or Standard. I am actually pretty happy with Visual C++ 6.0 for ISAPI development; Visual C++ 2005 Express does the job as well, but it does not improve the ISAPI development experience. I use it because Visual Studio Express Editions are powerful, functional, and free.

MFC ISAPI Template looks like someone's attempt to make writing an ISAPI like writing an MFC Windows Application for the Web... without understanding how the Web works.

Now, we are planning to fix this for IIS7 where the IIS team (not Visual C++ team) is going to come up with the Application Wizards, Framework, and Templates for native and managed modules extending IIS7 behavior. And we'll get an UI designer to make it look nice, too. :-) In fact, I am authoring some of those pieces right now...

//David

Comments

• Anonymous
  March 26, 2006
  Well, good alternative is ATL Server ISAPI Extension classes ... They offer quite nice object model and I found them to be more robust than those classes that come with IIS SDK

• Anonymous
  March 27, 2006
  PrzemekW - yeah, ATL Server provides a real substantive model which actually tries to layer away the raw ISAPI interactions with more higher-order functionality. It does not make ISAPI easier to use; it makes building higher-order applications on top of ISAPI easier.
  
  On the other hand, the ISAPITools classes that come with IIS SDK are targetted at making raw HTTP/ISAPI interactions more friendly. It doesn't try to provide a model; it just makes ISAPI easier to use.
  
  They target different needs and both have their place. The MFC Templates, on the other hand, add no real value.
  
  //David

• Anonymous
  April 13, 2006
  IIS has always had an identity crisis. Is it a platform for hosting and building web applications, or...

• Anonymous
  June 19, 2008
  The comment has been removed

• Anonymous
  June 21, 2008
  Mario - there is no language requirement for ISAPI - anything that can create a Win32 DLL with the necessary exports will work. I do not know what you mean by "chain some extensions together" - are you saying that you have the binary DLL of several ISAPI DLLs which you'd like to compose into a single action? If so, you cannot chain ISAPI Extensions unless the ISAPI itself is written to support chaining. ISAPI Extensions are supposed to handle and terminate request processing. //David

• Anonymous
  June 22, 2008
  Wow, awesome did not know that about ISAPI. All examples in the SDK were C based. So VB.Net or C# could be used? I am a little confused about the exporting you mentioned.what do you mean when you say exports? Ok, I see about the ISAPI chaining. Basically I was hoping to save some time and build a Parent ISAPI that would call other dll's ( ssiinc.dll is an example ) then receive the processed request back from this dll and then process before handing back to the client. Thoughts? Thank for you prompt and informative response. //Mario

• Anonymous
  June 23, 2008
  mario - Managed code do not have syntax to export signatures on managed assemblies, so they cannot be used. Conceptually, it is like adding "public" access modifier on a method in managed code, but the two technologies are different and incompatible. Even with chaining, you cannot achieve what you want because it requires buffering of output (so that the chained ISAPI can see the response of the processed request to perform additional processing). //David

• Anonymous
  June 26, 2008
  The comment has been removed

• Anonymous
  June 27, 2008
  Mario - sorry, I do not know of any good books on ISAPI. I suspect you should be able to find all the useful information you need between my blog and the public Microsoft ISAPI-DEV newsgroup - microsoft.­public.­platformsdk.­internet.­server.­isapi-dev //David

• Anonymous
  December 05, 2008
  How to run  dll ( developed  using  ISAPI Program) in a webbrowser using IIS.

• Anonymous
  December 07, 2008
  JAG - it is not possible to run a dll (developed using ISAPI Program) in a web browser using IIS. It is possible to run an ISAPI DLL on the IIS web server to generate a HTTP response for a web browser to display. How to set this up is standard. Please look up documentation on microsoft.com for assistance. //David