>I see two issues really.
>(a) Whether hungarian notation is really a good idea or not.
>(b) Whether, even if you decide that it is, you should use it.
>
>On (a):
>Hungarian notation is arguably useful in a non-strongly typed language. But .NET *is* strongly typed.
>Within .NET, AFAICS, it could be argued that hungarian notation *might* make your code more readable if it is in print (a book or on the web).
>If you are looking at it in the IDE then hungarian notation just gets in the way. Intellisense will tell you the exact type unambiguously and accurately.

I am not sure I follow the last line. But, I never had any problem with that, nor any warning in the designer with that kind of naming convention.

>On (b):
>Your definition of 'everyone' appears to be 'everyone in the team' not 'everyone using VB.NET'. If you are not following the MS guidelines (whether you like them or not) it is likely that any new members to your team are going to spend a lot of time learning your team specific conventions.

It is all fine with that. Doing framework level stuff is more targeting at generic and making it more easy to migrate to a new development environment if I ever had to do it. Most of my clients want to have something that is portable. So, when we moved from VFP to .NET, all the properties and variables remained the same. If was easy to follow. In two years, if I have to convert it to whatever would be the new standard, then, we can continue to use what we have set up since years.

I try to use most of the stuff from the .NET framework but try to avoid proprietary stuff. As, this is when, when moving into a new plateform that it is a real puzzle to migrate. Not too many persons or organizations have made two frameworks in this world. One of the reason is that it costs a lot of money, lots of R & D, lots of time, etc. I spent the last years in the '90s building my VFP framework. Then, a few more years to built a .NET version of it in the 21st century.

One of the thing I learned is to avoid, if possible, all use of 3rd parties. Because, when comes time to move, you are stuck waiting for the vendor to provide a new version of their tool for the new environment. It saves time and money on licensing as well. But, having reached such a mature level of that product, I have to say it was worth it. I did get some awesome help from you and many other members on the site since several years. And, whenever I want to verify an architecture or have an issue, I can continue to use this site and share my issues.

The beauty of it now is that having about 25 Web sites using it, 20 robots, 4 Web Services and such, whenever comes time to adjust something, I can only change something in the Framework.dll and send a new copy to the client. It is just a drop of one file in the Bin directory, assuming an ASP.NET Web site and that's it. If I would have to restart all over, I would have to rethink about all of it now. As, this takes a lot of years in a lifetime. So, it is a choice to make. But, having it now in my hand, I wouldn't switch it for anything else.