It's just me, I never remember to do the <g> thing! I actually agree with what you said this time. It's bad if a programmer ONLY know MM.NET Framework but never spend the time to learn .NET Framework. However, if you have used MM.NET Framework you would know that you have to know .NET Framework in order to use MM.NET. MM.NET is just a helper and do not in any way shield you from the REAL stuff.

If you do have a system architect with as much experience as Kevin, by all mean make your own framework. It will probably be more efficient and suitable for your system. However, smaller development shop can't afford the six figure salary of an experienced system architect. Their best bet is to use a framework so they can get their first .NET version out and gain the experience to make their own framework later.

I also agree with you that once you use a framework, you are married to it. That's why one should be real careful selecting a framework just like selecting the platform and language to use. At the beginning, I opposed to the idea of a framework but after spending a day to attend Kevin's training class, I saw how it can help us without limiting us.

Stephen

>See, now is that a <g> or what? I mean... don't be ridiculous. I don't think people should re-invent the wheel. If people will just read. I think a framework is ideal for small projects, where time constraints are factory. If you have luxury of time, the benefits of writing your own framework are worth it.

>I think the knowledge the team gains from developing their own framework is priceless, and more then worthwhile to dedicate a month or two to doing it. Not only does give them the knowledge, the performance, customizability, and the simpler your own framework will probably be.

>I think it outweighs it. If you already have the knowledge of a framework, and you are comfortable that a commerical framework would totally fit into your large scale application then it may be worth it. You are then somewhat married to it. Like Jason said, it is like hiring another employee. If the employee turns out to work well and everything is smooth, it was worth it. If you have problems with the employee, but rely heavy on them for your application and business, it is more difficult to get rid of them.

>That was the point, I'm not trying to tell everyone to go back to punch-cards, COBOL and VFP .. all of those ancient, pre-industrial languages.. <g>

Morgan