As a VFP developer, you have a leg up on VB developers learning .NET, since they have no experience with inheritance. The skills you have aquired will translate over to developing your directory and library structures in .NET. In .NET you don't have the options like you do in VFP (SCX vs. VCX vs. PRG). I have found that my directory structures and libraries work very well within .NET. I separate code into small reusable components that can be called from numerious business objects or methods. You have a organization if libraries that works well for you with VFP, do you have concerns of how a similar structure will work in .NET? In the past with VB, you had to reorganize how you laid out your project since inheritance was not in the picture. Now with .NET, there is much more similarities to VFP. The biggest difference between the two is in the case of working with data. However, your business objects and data objects can abstract the differences.

>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.