Please see our important announcement.

From VS2005 to IIS - putting your app on a server

So we have all been dogfooding a bit and creating our own apps with the SDK. I'm still finishing my app - but heres a few things I saw while installing it.

I thought I would have a go at installing a web service on IIS 6, on a Windows 2003 server. A reasonable challenge for me. Whats below is how I finally go stuff working - some of it may be useful in other cases. YMMV. Please add corrections, improvements etc as comments.

Now, my simple Winform App calls a web service on the server, which in turn does the SDK calls. I did it this way because I'm not a fan of using a web site to do stuff a win app does better. The web service, written in VS2005 are a bunch of files with a the 'code behind' defining the service itself in C#, the BT SDK assemblies in the bin, a wse3policyCache.config file, a web.config file and a service.asmx file to tie things together.

Permissions

Most of the problems associated with IIS are permission based. When I'm me, I can see all my files. But the IIS system does not by default have similar privileges. There are various user accounts that IIS appropriates to gets things done. On Windows 2003, process account is called 'Network Services'. I think its 'ASPNET' on XP. That's the one that needs to see files and stuff.

After copying the files across to a suitable share, you can create the web site from within IIS manager. Its best to copy to a network share for convenience. Try to avoid using 'My Documents' as that gets hard for IIS to find.

You should see your site listed in IIS manager. In the properties dialog of your site, in the 'ASP.NET' tab make sure you select the .NET 2 version. Set the home directory and maybe a free port. If you are sharing other web sites and some are .NET 1.0, make a new application pool.

Moving certificates

As IIS is now hosting your application, you need to give it access to your application's certificate and private key - the one you made when you installed. Hopefully you saved the .pfx file somewhere. To give IIS the best chance of finding your certificate, you need to import it into 'LocalMachine' store - not the 'CurrentUser' store. Uptil now, the SDK assumed the opposite.

The best tool to use is the MMC snap-in stuff. Run 'MMC' from the command line, and add a 'Certificates' snap in that targets the Local Machine. Browse to Personal Certificates and from 'All tasks' run 'import'. Follow the nice wizard.

Notice I say 'import' it. If you try moving it by dragging it from the 'CurrentUser' and dropping it into the 'LocalMachine', it won't work. Nasty little gotcha that one.

Private keys

So you have your certificate and key in the store. Thats good, but sadly IIS will not be able to read the keys. Find a Microsoft WSE 3 installation folder, and run the 'WseCertificate3' tool. Select your personal certificae in the Local Machine store and hit 'View private key file properties'. Now you can add the appropriate accounts (see above) in the security account.

Almost there

Within wse3policyCache.config and web.config, change every reference of 'CurrentUser' to 'LocalMachine'. So thats certs sorted.

My last issue was with resolving exceptions. While our apps were working, they only returned one type of exception as opposed to our nice comprehensive ones.

In our setup, its not easy for the server to access the url that hosts the fault codes needed to get nice exceptions. The workaround for this is just to put a cached copy of faultcodes.xml wherever you run your binaries from. Where does IIS run from? Well, try c:\windows\system32\inetsrv. I was hoping there was an elegant way to map a file to the current directory - but I didn't find one.

And then I noticed we were supposed to write a web app. Oh well, no prize for me.