Send As SMS

Monday, June 20, 2005

Visual Studio.NET Solution Structure Guide [Articles]

Overview

Goal of solution is to organize all what is related to particular project into single entity. This is really important because of:
  • Source control requirements
  • Simplify compilation
  • Simplify testing
  • Simplify installation/deployment

As we can see, all this is about collaboration. While expecting Visual Studio 2005, we can add some tricks which makes our life more organized even with "old" Visual Studio 2002/2003.
I'm going to describe following topics related to solution:

  • 3rd Party components
  • Project related incoming documents
  • Web Service References

Pre-requirements

I'm suggesting that all projects (including web projects) is in subfolders from solution root.

3rd Party components

It's common to use 3rd parties - Exception management AppBlocks, DataAccess, NUnit.Framework, GUI libraries, etc. Important questions for us will be:

  • Avoid, if possible, manual installation on every development PC
  • Synchronize versions
  • Store correct version in source control

In VS.NET when you add reference to another assembly, this is your problem to distribute it to another PC.

Let's create an empty project in our solution, name it. Copy all necessary .dll files into folder under this project. You could create subfolders if you wish. After this you could add this files to your project. (Files, not references!). You should get something like this:

We got:

  • All developers uses same libraries.
  • Distribution/Upgrading of 3rd party libraries is possible via source control (if it do not require full installation)
  • 3rd party libraries are in source control together with project source

Project related incoming documents

The same idea could be used to bind project documents to a source code. It is good to organize documents by project stages (Inception, Planning, Development, etc) and/or by Internal/External.

Our benefit is versioning - we could always review history of document changes. However, noone source control able to show for us differences between MS word documents.

In case when you need to share this documents with customer which do not has an access to you source database, you could setup web project for this. VS.NET has a relatively good ability to publish web projects. Only thing you need to do - is to create simple index file, or a write .aspx page which generates list of all documents in subfolders. It would not took more than few hours.

Web Service References

I was developing a complex system which used web services technology to exchange data. I would like to share one small hint from my experience.

This is very good practice to use a separate assembly for web references generated by VS.NET. In other words, you need one logical entry point.

After a while, you could find out that many different modules of your system need access to web service. If you place web reference in each of them you will be faced few problems:

  1. You will need to update every of them every time web service changed
  2. You will be not able to cast type from one web service wrapper to another

Such simple solution as one assembly for web services help you to build solid system - especially when you are developing both service and client and something started to change.

Also in solution...

Definetely, there are a lot more things which could be placed in solution, but it seems to be more common experience so I not mentioned it. At lease it should also include database objects if any, unit tests, source code documentation, automatical build scripts, photos from last company party, etc.

Applies to all dotnet languages: C#, VB.NET, C++.NET, J#

posted by Sergey Osypchuk @ 8:32 AM  

0 Comments:

Post a Comment

<< Home