Rex,

While the application blocks are good, with MM.NET you get:

1) For $700 you essentially hire a team of some of the most noted .NET developers available (Kevin and Rick among them). Try finding developers of their caliber to develop all the code and code-glue you would have to write to wire up even the app blocks.

2) Security and access rights administration built in.

3) A simple-to-use means of localizing your application (not just for languages, but for customizing labels to match customer's terminology).

4) A robust data access layer that allows you to support multiple either Oracle or SQL.

5) The framework has extensive UI mods that allow amazingly simple 2-way databinding in ASP.NET. Further, both WinForms and ASP.NET is supported. And add web services to that, too.

6) Good technical support - I know I've more than got my money's worth on that.

7) It is highly extensible. The architecture is not that difficult to grasp and it is relatively easy to subclass and add additional functionality as needed.

I will say this though... the greatest benefit comes to you if you are already intimately familiar with .NET. In my case, I combined two learning curves into one and that was not easy.

From a business perspective (and that IS my primary perspective) it is a no-brainer decision: Do I spend $699 for a robust framework, or do I spend hundreds of thousands of dollars rolling my own?

Further, there really isn't much out there that is comparable except for PDSA's framework (which costs $15,000 and is ASP.NET centric) or CLSA which is free but primarily focuses on the data and business layers and does not have the great UI features, Security, and Localization features that MM.NET has (as far as I know).

Regards,
Carl.
>Jamie,
>
>Thanks for your response. Our supervisors say, "Why do we need an application framework when we have the Microsoft Application Blocks?" I am trying to get the idea across that the blocks are just that, blocks. There is no integrations, no business objects, no validations controls beyond the normal .Net controls, etc.
>
>Thanks again
>
>Rex
>
>>Just because the data layer is hidden doesn't mean it doesn't have a data layer. If you designed a framework yourself, you would have to do the same thing. To me this would be a feature and not a problem. You don't need to worry about the nitty gritty of data access since the framework takes care of it for you.
>>
>>Jamie