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.
On May 12 2005 3:02 PMBy jprosise
Hi Jeff, i just heard about the 'provider toolkit' from Microsoft, this is excellent news. I've just completed an extranet project using 2.0 beta 2 and had to roll all my own providers. This would have made my life so much easier... i had to rely on reflector when i got stuck. this is going to help so many people get over the fear factor of extending the model, i'd be interested to know your are implementing the toolkit Good luck with the project Regards
Jeff, that's great. For those of us trying to figure out how to dive in on custom providers, do you have any projection when the toolkit would be out? That will help me decide if I need to roll up my sleeves now or wait a bit for the toolkit. Thanks.
I don't know when Microsoft plans to roll the toolkit out. I'll finish most of the work in a couple of weeks. I'm guessing it'll be available shortly after that--probably early July or so. But that's just my guess.
Jeff, ain't you going to tell us why is it that BuildSiteMap is called twice? This is happening in my own custom SiteMap privider, but I don't find any clues in the realeased Toolkit.
I assume if SiteMapProvider was left out of the first realease, it is because it is still in flux. Implementing a SiteMapProvider left me with the feeling that it can be improved.