Joe,
Very interesting read on your message and I appreciate the input. I have the Framework Design Guidelines book still on my Amazon wish list and some day as my reading progresses to it I will get it. Awesome on FxCop and all that it will reveal. While I have not used it yet I will likely begin using it heavily in the future because I am inheriting code that I did not write and over time would like to ensure that it conforms to the issued standards. Sure, code will still work when not standard compliant, but I like to do good housekeeping as time permits and can relate to your point about eventually getting back to working on getting the Mojo code to pass the FxCop tests.
Regarding the Developing Application Frameworks in .NET book that I have, it is more about how to develop a framework for your application. The first chapter begins defining what an application framework is and why you may want to use them in your development work. Chapter 2 dives into the layers of a framework. Chapter 3 is an overview of a simplified application framwork that the author then expands upon in the remaing chapters of the book. Topics covered in later chapters include class factories, caching service, configuration service, event notification, windows services, message queue services, authorization service, authentication service, cryptography service, transaction service, document layer service, and the workflow service. Each of these services, I believe (have not gotten that deep into the reading yet) are a part of the simplified application framework that is presented in the third chapter.
My purpose in acquring the book was to develop and understanding of what a real application framework was and the types of things that you would/could put into one. For some time I have thought that it was very possible to build applications based in a portal such as Mojo, Rainbow, or PostNuke (for all you PHP folks) and of course I have had some folks tell me that it just did not make sense to do that. For me it made sense (keep in mind I'm talking about pre-.NET2.0 days, because portals already had authorization and authentication in them as well as themeing/skinng engines, and the like. So my mind was thinking along the lines of using the portal as a framework since it had many of the standard functions an application would need and just use the portal API to create modules to deliver the functionality that was missing for the specific need.
With the release of .NET2.0, themeing/skinning engines are not necessary any longer (use master pages instead) in portals and really with things like the membership management may well take care of authenticaion/authorization.
So my thoughts are now along the lines of using a portal for perhaps the application framework so that I don't have to roll my own and build modules to add the user functionality for the application. I may be barking up the wrong tree, however, figure it is worth a shot to see how it all works.
Ira