>Please see my comments, follow up questions below your answers.
>
>>
>>I like putting them in the same assembly and folder as the other forms but naming the base forms beginning with 'base' like 'baseMySolutionMaint' for a base maintenance form in 'MySolution' (replacing MySolution with an abbreviation for the solution)
>>
>
>Do I understand correctly that by assembly you mean the application project/DLL, right? I am still not very comfortable with this terminology.

Yes, each dll is an assembly.

>
>>because a base maintenance form for one solution may not be the same as a base maintenance form for another solution unless you are fortunate to share some basic functionality between all solutions then it could just be 'baseMaintForm' or 'baseSearchForm' etc.
>>
>
>If the same 'baseMaintForm' would be applicable to more than one application, you can just copy the 'baseMaintForm' files to a new application?

Don't copy it. Just add a reference to the project (assembly or dll) it is in to the solution. Try to stop thinking 'application' and think 'solution' broken up into different assemblies. Sort-of like if your business logic in your vfp app was in a separate app and you called prgs or classes in it from your main app. Two separate pieces. I like to create a separate project for each layer and then add those projects to the solution so that each compiles into its own dll and I distribute those dlls separately or in different locations (server or local machine), etc.

Your namespace is important. Think company, layer, app:

Assume your App name is IPOS (made it up for example of a point of sales app name):

SmithCo.Entities.dll (all of Smith Co's solutions use these entity classes)
SmithCo.Entities.IPOS.dll (these are based on the one above but are specific for this app. This project has a reference to the one above)
SmithCo.Business.dll (all of Smith Co's solutions use these business classes this project has a reference to SmithCo.Entities)
SmithCo.Business.IPOS.dll (these are based on the one above but are customized for the IPOS business rules, this project has a reference to SmithCo.Business, SmithCo.Entities.IPOS, and SmithCo.Entities)
SmithCo.UI.dll (base form classes and controls)
SmithCo.UI.IPOS.dll (these forms are based on the ones in the project above)

You might just have a dataAccess project, an entity project (if you use entities), a business layer, and a UI (forms, controls) layer. You might have more layers or assemblies like contracts and presentation and reports.

etc.

Others probably do it differently. That is just one example and I tried to make it simple (not as many layers just to demonstrate the concept). Start out simple though. Don't worry about separate layers yet. When learning, don't break it all up until you are comfortable with the language and the framework (how to make a form display and edit data using different methods like L2S, ado.net, etc)

>
>>Sometimes common forms go into a separate COMMON folder in the forms UI assembly. The UI assembly only has forms in it, bmps, controls, skins, etc.
>>
>>I like separating assemblies by layer. (UI, DATA, ENTITIES, BUSINESS, PRESENTATION, REPORTS, etc)
>
>Do I understand correctly that you would have several projects, one for each layer, and then corresponding DLLs?


Yes. Each project compiles into it's own dll (assembly). That way, if another solution can use your business layer, you just add a reference to those assemblies in that solution and you can physically move them around if necessary. If it will be reused and you don't want to code it again - separate it out and just reference it (within reason, you don't want 50 assemblies :o)


>
>Thank you for your help.

I just found this. I didn't use this, but I just skimmed it and it looks pretty helpful:
http://doctools.codeplex.com/Wiki/View.aspx?title=PAG-ArchGuide20_cdec98ba-d480-4eb7-85e5-cca80f36726c.txt

But again, don't worry about patterns yet unless you are already comfortable with the language and the framework and working with data, etc.

Hope I explained this all ok. I tried to put into context of coming from the VFP world....maybe that wasn't such a good idea :o)