Wednesday, June 24, 2009

NWSGI 2.0: Configuration Changes

One of the two areas to see the most changes in NWSGI 2.0 was its configuration. Some of the options in v1.0 were overloaded in strange ways; even I wasn’t entirely sure what some combinations would produce. There was also the small problem of where to put the configuration section; it varied depending on how NWSGI was installed. For v2.0, both problems needed to be fixed. Doing so required a re-think of how configuration was handled.

Configuring Wildcards

In v1.0, configuring NWSGI to operate in wildcard mode required setting options that were designed for other things in particular ways that made no sense. In v2.0, there is a special <wildcard> element under <wsgi> (replacing the wildcardModule option) that is specifically used for configuring these settings. If the <wildcard> element exists, then NWSGI will ignore the <scriptMappings> element.

The callable option has also been removed from the <wsgi> element as it is no longer necessary (it defaults to “application”). To specify a custom callable name for a script, create a <scriptMapping>.

Where to put it?

The first problem was to put the <wsgi> section in the same place all the time. In v1.0 it could be directly under <configuration> (if you were using xcopy deployment) or under <system.webServer> (if you installed it on IIS7). The two could not necessarily coexist in the same web.config file, either! IIS 7 uses a different configuration assembly (Microsoft.Web.Administration) than ASP.NET (System.Configuration), and they’re no compatible, to boot.

The fix is relatively simple: rather than trying to use the appropriate configuration system from the handler, v2.0 always uses System.Configuration. This means that the <wsgi> section is always directly under <configuration>. The only downside is that the section always has to be declared at the top of web.config:

<configSections>
    <section name="wsgi" type="NWSGI.WsgiSection, NWSGI, Version=1.99.1.0, Culture=neutral, PublicKeyToken=41e64ddc1bf1fc86" />
</configSections>

New Options

There are also two new options: compilation and frames. The compilation option controls how IronPython generates code. The frames option is used to control sys._getframe; as tracking frames incurs a performance hit, it must be explicitly enabled.

Wrapping Up

The changes to configuration (which will break any existing configurations) are the main reason for bumping the version to 2.0. The clean up of the options resulted in much cleaner implementations for the management and especially for the handler itself. As always, if you have any comments, let me know.

Monday, June 22, 2009

NWSGI 2.0: Installation & Usage

There are two ways to use NWSGI: by installing it or by using xcopy deployment. Each method has its advantages and disadvantages, but their functionality is the same.

Installation

The quickest way to get NWSGI up and running is to use the MSI installer. This will add NWSGI to the GAC, making it available for all applications. If you are running IIS 7, it will also install the IIS 7 management components. The installer will also put a copy of the NWSGI assembly along with the README and HelloWorld example in C:\Program Files\NWSGI. This is the preferred approach, unless you do not have administrator rights to the server and cannot convince the server administrator to install it.

xcopy Deployment

The term “xcopy deployment” refers to the Windows xcopy command, which is used to (among other things) copy entire directory trees. Using this method is useful if you can’t (or don’t want to) use the installer package. If this is the case, download the .zip package instead of the MSI installer. To use this method, simply copy NWSGI.dll into your application’s Bin/ directory, and then copy the whole application folder to the server.

Setting Up the Hello World Example

Once you have decided which method you are going to use, the easiest way to check that it is working is to use the HelloWorld example that is included with both packages. I’m only going to describe the most common configuration, and I’m also going to assume you have access to the server; if you have a custom setup (such as a hosted site), just ask.

  1. Copy the HelloWorld sample folder to C:\inetpub\wwwroot.
  2. Mark C:\inetpub\wwwroot\HelloWorld as an application.
    • IIS 6/7: From the IIS management UI, mark the folder as an application.
    • IIS 7: From an elevated command prompt, run: appcmd add app /site.name:"Default Web Site" /path:/HelloWorld /physicalPath:C:\inetput\wwwroot\HelloWorld
  3. Visit http://localhost/HelloWorld/hello.wsgi.

If the browser says “Hello, World!”, you’re good to go! If not, please ask in the forum, and I’ll try to help you out.

Thursday, June 18, 2009

NWSGI 2.0 Beta 1

NWSGI 2.0 Beta 1 is now available. This is a major update to NWSGI that makes it easier to install and use and dramatically improves the management story.

So, what happened to 1.1?

Originally, NWSGI 1.1 was going to be a refresh of v1.0 that supported IronPython 2.6 and fixed a few bugs. NWSGI 2.0 was going to completely overhaul large parts of the management UI and make some deeper changes to the handler itself. However, I got a week off with some rain and v2.0 progressed much quicker than expected; v1.1 was obsolete before it was even released.

So, v1.1 was dropped and v2.0 will be the first IronPython 2.6-compatible release. It’s easy to make breaking changes when you have no customers :).

What’s New

  • Easier configuration. In v1.0 there were different ways to configure NWSGI depending on your configuration. Now there is only one way to do it. Some of the more ambiguous options have also been cleaned up, and new ones added to support IronPython 2.6.
  • Better management UI. IIS 7 includes a rich UI framework for developing management extensions, but doesn’t have much documentation on it. Some spelunking with reflector showed me better ways to do pretty much everything; not much of the v1.0 management code is left.
  • Performance improvements. NWSGI will now cache the WSGI callable instead of reloading it each time.
  • Other misc. fixes. I really need to get into the habit of adding a Codeplex issue for each bug so that I can keep track of what I’ve fixed.

Give it a spin

The Codeplex wiki needs to be updated to reflect the new documentation, but the included readme is up to date. I’ll also be posting a series of blogs posts over the next few weeks that will explain all the features of NWSGI and provide some helpful examples. Remember, this is a Beta release, so please let me know if you encounter any issues.

Saturday, April 25, 2009

Ctypes for IronPython

I've been spending the last little while working ctypes support for IronPython. It's certainly an interesting problem, mapping from Python –> .NET –> C, and I've learned more than I ever wanted to know about extending IronPython. Support isn't anywhere close to complete – it passes a whopping 5/101 tests. IronPython 2.6 is required.

What's complete:

  • Primitive (c_*) types
  • Simple structures, nested structures
  • Loading DLLs
  • Calling functions
  • byref() parameters

What's missing:

  • Unions
  • Subclassed structures
  • POINTERs
  • Arrays
  • Probably lots of other stuff…

It does work for simple functions, like so:

from ctypes import *

libc = cdll.msvcrt

i = c_int()
f = c_float()
libc.sscanf("1 3.14", "%d %f", byref(i), byref(f))

Download the DLL. Drop the DLL in the "DLLs" directory of your IronPython 2.6 installation (create it if it doesn't exist).

Huge thanks to Seo Sanghyeon for the original FePy implementation (written in Python – I'm still not sure rewriting in C# was a good idea) and Curt Hagenlocher for providing me with the code to generate types on the fly. If you want to check out the source, go to my hg repository. As always, the code is under the MS-PL.

UPDATE: It turns out ctypes will be part of IronPython 2.6 (not based on this code, but a completely different implementation).

Sunday, March 29, 2009

NWSGI 1.1 Preview 1

A preview of NWSGI 1.1 is now available on Codeplex. This preview is linked against IronPython 2.6a1 so that I can start testing against 2.6 with enough lead time to actually get any bugs fixed before release :). There are also some enhancements to the configuration that can simplify some common scenarios; see the release notes or changes.txt for more information. I'll write up more detailed instructions on how to take advantage of those changes in the future.