I’m currently working on an extremely cool project for the ASP.NET team: building an ASP.NET 2.0 provider toolkit. The provider architecture is one of ASP.NET 2.0’s most important new features, IMHO. The team decided that if the architecture wasn’t documented well, developers would shy away from writing custom providers or, worse, produce buggy providers. So they decided to build a toolkit that includes all the information you need to build robust providers plus lots of sample code to serve as a guide.
I’ve been heads down for the past couple of weeks working on it. I’m having a blast, (staying at home, writing code, avoiding airports–what could be better?) and I’m documenting the facets of the provider model that are most likely to trip developers up. Did you know, for example, that unlike almost anything else you write for ASP.NET, providers must be thread-safe? There are also some interesting issues surrounding what you can and cannot do at initialization time. Call the wrong API, for example, and you’ll cause a deadly reentrancy. (I ran headlong into this when porting some beta 1 providers I had written to beta 2.)
I’ll post more information as I go along. When the project is complete, I’ll also be sure to post a URL where you can download the toolkit from Microsoft’s site.
BTW, some of you may have run into issues with ASP.NET 2.0 when the membership service refuses to encrypt passwords if <machineKey’s> decryptionKey is autogenerated. At first this puzzled me. Then a gentleman on the team cleared it up for me. Seems that during the alpha, devs who work on multiple boxes were encrypting passwords on one box and then discovering that they couldn’t decrypt them (in other words, that the entire membership database was worthless) on another box. The culprit was those autogenerated encryption/decryption keys. If you want ASP.NET 2.0 to encrypt passwords for you, you have to specify an explicit decryptionKey. By setting that attribute to the same value on every box, you can move a membership database from one server to another and it will work–even if the database contains encrypted passwords.
Know that I know the answer, it makes a LOT of sense.