I figured that I had a good deal of empathy for a developer who had to write a driver. I have spent nearly 5 years creating and supporting WDF, learning from the community and drawing on my own experience in how drivers are written. Two of the most common questions is "what IDE should I use" and "can I write and build a driver in Visual Studio (VS)"? In terms of an IDE purely for writing code, no one can tell you what to use. Everybody's style and workflow is different. Sometimes you can't even pick, your employer will dictate that you must use program X. In this case, you are still using the WDK build window to build your driver. I understood this type of user pretty well, I am one of them. I use Visual SlickEdit as my editor (in vi mode so my hands never leave the keyboard 😉 ) and use razzle (essentially the internal version of the WDK build window) to compile my code.
Writing and compiling my driver in VS is something I didn't fully grok until recently. I thought I understood the appeal of the integrated compilation results within the editor, that you could double click on an error and have that line be brought up in the editor, etc etc. What I didn't fully understand the appeal of was the actual writing of code in VS. The last time I used VS full time was in 1997 as a college undergrad working on a kiosk software project in C++ (no C# at the time 😉 ). There was some rudimentary intellisense there, but not much to write home about. I just started using VS 2005 for another project and I am very impressed with the intellisense, automatching, refactoring and other features in the product. It is pretty frackin' awesome in terms of productivity and discovery of features. So I now get why a lot of you want to be able to write and build a driver in VS ;), it is a very compelling work environment.
I hope that we wil get WDK integration into VS in the future, but I think that is just the first step. There are so many things that we as Microsoft can integrate with other then getting intellisense and auto completion working. If we are to take the time to integrate into VS, it should be deep and appropriate for the entire development cycle(s), not just the writing of code.