Skip to the content Back to Top

Further to my post called Webpublisher on Windows Vista, here is how to install Inmagic Webpublisher on IIS 7 in a 64-bit environment such as Windows Vista x64 or Windows Server 2008 x64.

These instructions are valid for DB/Text Webpublisher as well as CS/Webpublisher. Steps 1 - 5 are valid for 32-bit IIS 7 as well.

1. Ensure IIS is enabled

This screenshot shows which IIS features are enabled on my Vista x64 machine. The highlighted one is particularly important (IIS metabase and IIS 6 configuration compatibility).

iis7_vista_features_on

2. Install Inmagic Webpublisher

Follow the usual Inmagic install instructions.

3. Enable ISAPI-dll handler mapping on dbtw-wpd or ics-wpd virtual directory

Open the IIS Manager.

Open the Handler Mappings for the dbtw-wpd or ics-wpd virtual directory. (Figure below shows dbtw-wpd.)

dbtw-wpd

The ISAPI-dll handler is disabled by default.

isapi-dll_disabled

Enable the ISAPI-dll handler: right-click it, choose "Edit Feature Permissions", and check the "Execute" box. Click OK.

isapi-dll_enabled

4. Set the Webpublisher dll as an allowed restriction

In the IIS Manager, click on the machine root - this is the top level of the tree in the left column, which shows the machine name. You should see a number of machine-level features, including "ISAPI and CGI Restrictions", as below. If you do not see "ISAPI and CGI Restrictions", you have not properly enabled IIS settings in step 1.

machine_root

Open ISAPI and CGI Restrictions.

You may see Inmagic Webpublisher as an allowed restriction already. The path will point to the install location of dbtwpub.dll or icswppro.dll, depending on which version of Webpublisher you installed.

If you do not see Inmagic Webpublisher as an allowed restriction, you must add it. (Figure below shows DB/Text Webpublisher.)

add_restriction

5. Create an application pool for Webpublisher

Open Application Pools from the IIS Manager.

Add a new application pool to be used with Webpublisher, called "WebpublisherAppPool".

wpp_apppool

Go to the dbtw-wpd or ics-wpd virtual directory and open its Advanced Settings. Set the Application Pool to the new WebpublisherAppPool just created.

6. Enable 32-bit applications on the Webpublisher application pool

Open Application Pools from the IIS Manager.

Right-click on WebpublisherAppPool and select Advanced Settings.

Set "Enable 32-Bit Applications" to true. Click OK.

apppool_enable32bit

7. Get a drink. You're done.

Whatever drink you like. I like red wine, or on a hot day, gin and tonic.

Some more explanation

Whereas in IIS 6 you could run worker processes in either 32-bit or 64-bit mode, but not both, IIS 7 can run 32-bit and 64-bit worker processes simultaneously. And, as the above instructions make implicitly clear, you can set this behaviour on individual application pools.

 

Many of the ASP.NET web applications we build use SMTP to send email for one reason or another. Order confirmations, mostly, or selected search results.

Testing code that sends email has always been a pain. We have servers with SMTP service that I could point at from my development workstation, but their various restrictions have been, well, restricting. Nor did I ever like the idea of letting SMTP run openly on my local machine in XP. Not that I had much choice, because a) I had to ensure that the code I wrote followed through with the email send, and b) I wanted to view the email as email to ensure it looked the way it ought.

So along comes Vista with IIS 7. And SMTP is not included. It is included with Longhorn Server 2008 with IIS 7 (apparently), but not Vista. I now no longer have the choice of running SMTP locally. Disaster!

Well, as it happens, I'm fine. I'm better than fine, because I stumbled across a better solution all around. I use a pickup directory location.

Using a pickup directory location lets me specify a folder on my local machine for the email generated by System.Net.Mail. It's not sent anywhere, it's just dumped in that location as a *.eml file which can be viewed by Vista's built-in Windows Mail.

The best thing is, I don't have to change my code in any way to make this happen. I only need to add a snippet to the web.config as follows, identifying the (absolute) directory for pickup:

<system.net>
  <mailSettings>
    <smtp deliveryMethod="SpecifiedPickupDirectory">
      <specifiedPickupDirectory 
pickupDirectoryLocation="v:\inetpub\mailroot\pickup"/>
    </smtp>
  </mailSettings>
</system.net>

I did have to make sure that the ASP.NET worker account, NETWORK SERVICE, had read/write access to that location.
And here's the result. One double-click and I get to see it as it would appear in my inbox:
CropperCapture[17]
Probably other developers are like, well *duh*, but this was a new and very pleasant discovery for me.

Peter beat me to the post already, but instead of just leaving these thoughts in the comments, I figured I should add my two cents in a dedicated post as there a couple other things to take note of if a) you're not running as an Admin in Vista and/or b) you want to debug easily with Vista and IIS7.

First off, before hitting Peter's post, go to ScottGu's post. It tells you the essential step of making sure you've installed the "IIS 6 Management Compatibility" option within IIS7 (as ScottGu states, it "installs an API for the new configuration system that is compatible with the old Metabase APIs (which is what VS 2005 uses)").

As well, it'll help you if you've continued to run as a non-Admin on Vista with UAC enabled (both Peter and I have given up on this and are running as Admins with UAC off - the horror). I attempted for a month or so to use Vista with UAC etc., but the deal breaker was when I discovered that I couldn't drag and drop files into Visual Studio; nor could I open a project using the sln file. I'll hold off on UAC until stuff like Visual Studio is upped to use it reasonably (however, for those that want to use this as another reason to slam Vista, my love-hate relationship continues, but whenever I have to do something on my WinXP machine, I cringe...thus, there's a whole lot more love right now than hate).

In addition, I've found that in order to enable debugging, I need to add the following two steps:

  1. Set your application pool for the site to the Classic .NET AppPool.
  2. Enable Windows Authentication so that you can debug the site (haven't taken the time to figure out why this particular combination works, but suffice it to say, out of all the posts out there explaining how to get going with debugging with IIS7, this is the only thing that really matters). You'll get a "Challenge-based and login redirect-based authentication cannot be used simultaneously" alert, but ignorantly ignore this and you'll be fine.

UPDATE: I just found out in the writing of this post, that there is now a Visual Studio patch that fixes the Visual Studio F5 debugging of IIS7Applications on Vista.

NOTE: I LOVE being able to run multiple sites at one time. Bliss!

Inmagic WebPublisher PRO depends on classic ASP for its out-of-the-box web data entry. Vista does not, by default, enable ASP. You must enable it through the Control Panel:

Control Panel > Programs and Features > Turn Windows Features on or off > Internet Information Services > World Wide Web Services > ASP - Check!

Once you've done this, the IIS Manager will add ASP as an allowed ISAPI and CGI Restriction at the machine level, and add a new feature called ASP at the machine level. 

Of course, this does not absolve you of the necessity to set up the right permissions for WebPublisher to update the textbase via the web, but at least you can follow WebPublisher's setup instructions knowing your IIS 7 webserver is ready to handle ASP.

Let Us Help You!

We're Librarians - We Love to Help People