Project Organization in .NET

[sburleson]

I am in the process of converting a very large application to .Net. When it is done, it will probably have over 800 source modules. I am having difficulty deciding about how to organize the project with regard to DLLs, Namespaces, etc. Is there a good reference that can give advice and techniques on how to best accomplish this? I need more than just "this will work", because my project is starting to get unwieldly as far as how long it takes to rebuild, etc.

One item that I have never been able to find is some technical information on what exactly is necessary to debug within the Visual Studio IDE. For instance, if I make a project that has a debug build and reference that project's debug dll (not the project itself, just the completed dll), is it possible to debug the files within that project somehow. This is kind of my main stumbling block. I might seperate the application into 30 or 40 DLLs, but I do not want to create a solution that involves all of those (because of build times), but might want to be able to debug any module within any of those. I know I would give up the ability to have my "toplevel" solution to know that the "lowlevel" DLL needs to be rebuilt if a change occurs, or that my toplevel application may need to be rebuilt because of a change in that DLL, but I can deal with that manually fairly easily.

 

[TipGiver]

Suggestion: Keep your project in the language that was originally written with. If it was in vb5-6 then you will have to move from a event driven to a fully object oriented language, which means that you will get many errors (.. many many!) during the upgrate process.

It is generally suggested that projects would be better (only way some times) stayed in their starting language. In case it is small, the the Visual Studio's up.wizard can really help. If it is big then developers should consider of re-programming from scratch.


___________________
Some info:

You can use even nested namespaces, multiple classes within the same file. If you want to create dll's then add class library projects. The compilation will result in a dll. As the .NET platform is OO, you will have to create an instance for almost everything you need to use. To avoid this, have a search on Shared subs/functions/properties

 

[chrissie1]

What do you want more from use the "this will work". Even a framework like CSLA.net from Lhotka isn't perfect and isn't always what you need but it can be a great example. Large projects like yours, well lets say medium-sized(I have more test classes then that.), will need logical layering and/or physical tiers. It is up to you to decide how far you want and need to go we can only advise you. Like tipgiver says, you need to goo OO if you haven't already. But the information you gave us is really not enough. We can only guess.

If you make your projects then design them so that they will upscale easily. The CSLA.net framework does that, but like I said it's not perfect androckford is the first to admit that.

Christiaan Baes
Belgium

"My new site" - Me

 

[ThatRickGuy]

Here's a slightly out dated image of how we organize our namespace:

http://www.ringdev.com/code/GFCNamespace.gif

I'm not sure how 2005 hold up, but I have heard (second hand, I've never attempted this) that VS.Net 2k3 starts having issues when you have more than 20 projects in a single solution.

So if you want to get all 30+ into one solution, you'll probably want to get any stable projects compiled and use file references.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
I believe in killer coding ninja monkeys.

 

[chrissie1]

30+ in 2005 is no problem.

Christiaan Baes
Belgium

"My new site" - Me