Thanks for the info. I looked at it and it helped a little.

It looks like I may not have asked the questions properly. I am trying to see how this all works from a physical technical standspoint. For Example I understand how Active X works under the hood. How I that when I merely do a create object on a word the system finds the actual OCX via the registry etc. How that If I drop the Active X control on a form that certain meta data is stored in the VCX that gets in the way of OCX updates if the GUID was changed by the OCX developer. I know how to work around this and I know how to move an OCX. What my options are for deployment to production which may be a different disk layout than my development.

In VFP I understand how the VCX/SCX format works and what my choices are for packaging design time components. When to use a VCX and when to use a prg. What happens if I move a VCX and then how to correct that if need be. The furthermore when I compile these design time components how they are packaged into an EXE or App or DLL.

I have the book you mentioned we discussed that in another thread. The book is excellent but from what I have read so far (less than a week) it deals more with describing how to work the language not the physical layout on disk of your hierarchy. There is a chapter at the end of the book that begins to deal with this but I am missing some things in my head. (I will read the chapter over many times in the next few weeks)

I have followed up on a lot of programmers work where the directory strucuture is very shallow and more often than not very disorganized. It works but I subscribe to the idea that one big key to managing multiple customers with multiple projects or multiple projects in an organization is organizing things in such a way that I can easily find the pieces of a large app that I need to work on this minute and everything else is sort of out of the way (combination of docs and disk organization).

When I am eating one bite of the elephant I don't really want to have to deal too much with the rest of the elephant.

My company Ix.sys is a customer to this development area. I have about 10 different ideas for some software. A couple are pretty big commercial apps. One of the reasons I have so many books is that for several years I have been reading reading reading trying to see if there is a jump off point from VFP. 20 in VB alone. I don't really know how to program in VB but I know why I am not interested. At this point I am completely convinced that .net is the jump off point and I am ready to get started....but I need to understand more of the under the hood stuff first.