As a newbie to .NET, coming from VFP, I can say that I have spent hours rading and re-reading the MM Dev Guide, and it has been painful, but mostly becuase I didn't know a thing about .NET, ADO.NET, Winforms, C# or any of that stuff!

However, to address your original post, I can say that I did do the Test Bench example in C# (in MM ver 2.4 and VS 2005) and it did work perfectly by the Dev Guide steps.

Slowly, I have some to get my brain around the basics of the BO and Entity stuff, but it is a totally different way of thinking that will take me a long time to master. It's hard for me to shed 15 years of VFP old-school programming techniques and move to .NET, regardless of what framework I might choose.


Try comparing Kevin's MM package to some others, and see how it compares. There are tons of options to choose from: StrataFrame, IdeaBlade DevForce, Milos Solution Platform, and DevExpress eXpressApp Framework for complete frameworks, and for strictly the ORM tools, check out: LLBLGen, CSLA, and DevExpress XPO.






>Kevin,
>I understand that this is a best practice, but the jump start is not a guild to best practices. In fact the winforms jumpstart's is a terrible example of client server practices (returning every column in the list's recordset when only two columns are required) but I understand that it is simply demonstrating how to bind the Business Objects. There is a great deal of documentation available on best practices that have a large scope than the jumpstart.
>
>If this renaming causes a single developer to have a problem in the jumpstart than it just isn’t worth it. Ask yourself what the jump starts job is. If the answer comes back to teach .Net best practices than modify the winforms portion to demonstrate good client / server practices. If the answer comes back to teach users how to use the Business Objects then remove this point of failure.
>
>Thanks