Hi Christof,
I'll need some time to think about the implications of what you are saying, and possible scenarios that could work better for us.

We have a set of 5 class libs that are the same for all our apps, and all of them are included in every project. So, all objects created in an app are based on classes included in that project... Still, we get the error.

On the other hand, under the current setting (i.e. libraries included in projects) when we make changes to a class, the libraries included in the EXEs that are rebuilt will be different than the ones in the EXEs that were not rebuilt after the change. This is probably why, sometimes, we do see garbage in the trace window.

The specific of our production-development, is that the system runs 24x7, and we are expected to make changes to our applications all the time, including changes to our classes, and users will pick the new versions every time they start the MIS Apps.
If we exclude class libs from projects, then we cannot change them because they will always be in use.
Creating a new set of libs for each app seems a huge maintenance work increase.
I don't know if I have this straight, but I thought that each EXE (with included class libraries) would execute in its own memory space and that the problems we are experiencing should not happen. We would really appreciate some input from the MS development team members about how this whole memory/class thing actually is supposed to work. Most of the advice that we have received about this issue in the past seem to paint VFP into the corner of a minor application development tool and something that is perhaps just not designed to work in a department/enterprise workspace.

>Hi Doru,
>
>Internally, VFP maintains some sort of application session/context information. Each line of code that is executed is executed in the context of a particular application or not application at all. When VFP accesses a file, it first searches for a file with the same name in the current application. If it finds one, this is used, otherwise VFP searches the hard disk. Usually, before it accesses the application, it checks the internal caches which are not application specific. When resolving the class hierarchy in a VCX, these caches are not always used, but sometimes are.
>
>What happens if you have classes with the same name in various applications is that an object does not always use the class from this application, rather one from another application if that class has been loaded before. This is especially hard to nail down in a real application, because you only get the error if you do certain actions in a specifc order. Since the other class operates in a different application, code that tries to load classes suddenly fail. Even worse, if those classes differ somehow, the debugger might only display trash in the trace window.
>
>The so far most reliable solution I found is to base all classes in one application only on classes that are also stored in the application, give each class in each application a unique name and do not add dynamically objects from one application to an object from a different application. Or to keep all VCXes externally. You can use a tool like Cryptor to make it harder to decompile them in this case.
>
>Christof