MFC ISAPI Template and ISAPI Development

  • Article

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:

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