There are two options for assembly location in the .net framework. The first of these is the local application directory. As you surmise in your question, if the same assembly were used in multiple applications then it would be on the disk multiple times. It is a waste of disk space, but disk space is relatively cheap and the reality of this happening in practice is pretty small. For assemblies that are used by multiple applications, like the framework assemblies themselves, you can register them in the Global Assembly Cache (GAC). Assemblies in the GAC are version controlled, so you can have multiple versions of the same assembly being referenced by different applications. According to the theory, this should allow you to upgrade one application and its referenced assemblies without impacting other applications that rely on behaviors of the older versions. I am responsible for the delivery of a commercial system that has over two dozen assemblies. Many of these assemblies are shared between multiple applications in our system. All of our assemblies are copied locally and total disk space usage is actually minimal and of no concern. The only time I would expect it to be a concern is on a limited device such as a handheld, but again, the instance of multiply used assemblies outside the system assemblies is minimal. If you have to, put all your executables in the same directory with all your assemblies.

Hard to answer the question without understanding why you would want to do this? XML files are portable and easily readable and editable, but as an operational data store they are not very functional. The issues that I would see with this are: 1) Consistency. With a database system you are guaranteed data is consistent based on the queries run against it, even through a system crash. With XML files, writing to one file may succeed, writing to the next may fail. What state is your data in at that point? 2) Performance. Database systems are optimized for performance, especially query performance. For large data sets a database system is going to be able to query optimally even if the data set it is querying is to big to fit in memory. In order to get any performance out of XML you are probably going to have to load the whole thing into memory, which may be difficult if your data set gets big. XPath is pretty powerful but nobody claims it is a speed burner. 3) Data Relationship Maintenance. If you want to maintain relationships between data tables that are parts of separate documents, each with a separate schema, how are you going to load the relationship information into the DataSet? 4) Query Capability. You will loose significant query capability and performance using your model. 5) Multiuser Capability. Your system of files is a single user solution at best. If you are building a stand alone, single user application that you expect to have a limited data set size and are dead set on XML files, then I would at least explore putting all the tables into one XML file. Otherwise stick with a database system. XML files are best used for import and export of data and transfer of data between systems. Granted, XML files are cheap, but MySQL and SQL Server 2005 Express are free as well and much better options for a database engine.

I have studied my own way to an advanced degree in computer science and taught a number of programming courses along the way. I would love to help... Go to class on the days that it is taught, engage your professor during office hours and ask for assitance from him. Study the lecture material and ask for clarifications in class. Do your homework when it is assigned to the best of your ability. Don't take classes you have no business taking and hope you can beg your way to a good grade on the Internet. CodeProject is not a site to come to to get professionals to do your school work for you. There is a part of the assignment that you may want to reread: "YOU are required to demonstrate YOUR understanding." I'd do this for you, but I already passed all my classes. -- modified at 20:59 Thursday 12th January, 2006