views:

179

answers:

3

I'm new to visual studio, coming from Delphi.

I have a directory tree full of .cs files (root is \Common).
I also have a directory tree full of Applications (root is \Applications)
Finally, I've got a tree full of Assemblies (root is \Assemblies)

I'd like to keep my .cs files in the Common tree and all the environment voodoo (solutions, projects, settings, metadata, debug data, bin, etc.) in the Assmblies tree. So, for a simple example, I've got an assembly called PdMagic.Common.Math.dll. The Solution and project is located in \Assemblies\Common\Math. All of its source (.cs) files are in \Common\Math. (matrix.cs, trig.cs, mathtypes.cs, mathfuncs.cs, stats.cs, etc.)

When I use Add Existing Item to add matrix.cs to my project, a copy of it is added to the \Assemblies\Common\Math folder. I just want to reference it. I don't want multiple copies laying around. I've tried Add Existing Item, and used the drop down to "Add link" rather than just "Add", and that seems to do what I want.

Question: What is the "best practice" for this sort of thing? Do most people just put those .cs files all in the same folder as the project? Why isn't "Add link" the default?

Thanks!

+1  A: 

I think that the 'best practice' is to have those 'common' routines into an assembly that you can reference instead of pulling the source files into a bunch of different projects. You could add it as a pre-built assembly with "Add reference..." or by including a project for that assembly and adding a reference to the project (also done inthe "Add reference..." dialog).

This is one of those things that seems like a bit of work to set up initially (and it may be), but it generally pays off in the long run.

Michael Burr
@MichaelBurr: you beat me to it! Faster keyboard, I guess.
Cyberherbalist
I think he wants to organize his project and files differently than VS thinks he should, and so he is fighting the IDE to make things they way he wants, instead of how MS says he should want. I don't think he's trying to reuse code already available in a different assembly.
NerdFury
@NerdFury: I understand that the .cs files aren't in an assembly currently; however, I think that it might be a good idea to package them in an assembly (or several) for use by multiple projects. That might well be being forced into the IDE's way of doing things, but I think it's the answer to the question posed.
Michael Burr
From what I get out of reading the question, it seems he has a scenario like this: http://screencast.com/t/YzFjY2Ux that he is trying to make work. I think he is fighting the IDE, and will make things harder for himself by trying to maintain this structure.
NerdFury
@NerdFury: oh, I see. Yes, I think you're right that he'll have to keep fighting the IDE to go down this path. It can be done (in the way he's doing it now), but the IDE apparently won't make it easy.
Michael Burr
Yes, you're all right. I am fighting the IDE and when I realized that is when I wrote my original post :) If you have a few extra minutes, please have a look at my comment on NerdFury's answer.
Pete d'Oronzio
A: 

If you want to "reference" matrix.cs in your project, don't use Add Existing Item, create a reference ("Add Reference") to the class library or object that matrix.cs is a part of. If you don't want (or can't use) the library or object that matrix.cs is part of, then the Add Link is how you would get to it, but seriously I've never used that particular feature.

None of the developers I have ever worked with in .NET isolate their .cs files in separate folders. The only kind of segregation like that that I have seen as a practice is in MVC, where the models, views and controllers are in their own folders.

Cyberherbalist
Thanks for that. It was my intent that matrix.cs and the other .cs code was to be put in a PdMagic.Common.Math library so that it could be referenced by other projects. If you don't mind, have a look at my comment on my original post. How do tool vendors handle the case of common .cs for SL and WPF code? These can often be identical .cs, but require different assemblies to be built for each.
Pete d'Oronzio
+1  A: 

The "best practice" in this case, is to not fight the tool. It allows you to do what you want, but you'll get more work done and be able to focus on code if you just let the IDE organize your project for you.

I would create an empty solution project called PdMagic.Common

This will give you a file structure like

PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln

then I generally add a src and libs folder (via the file system, not VS)

inside the libs folder, i would place all my third party dependencies, and the src folder would hold all of my projects

PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln
PdMagic.Common\libs
PdMagic.Common\libs\nunit
PdMagic.Common\src

Next, in Visual Studio, I would right click on the Solution I just created, and click "Add -> New Project", I would specify that I wanted it created in the \src folder and call it PdMagic.Common.Math

Now my folder structure would look like this

PdMagic.Common\
PdMagic.Common\PdMagic.Common.sln
PdMagic.Common\libs
PdMagic.Common\libs\nunit
PdMagic.Common\src
PdMagic.Common\src\PdMagic.Common.Math
PdMagic.Common\src\PdMagic.Common.Math\PdMagic.Common.Math.csproj
PdMagic.Common\src\PdMagic.Common.Math\Class1.cs

Then, as you add classes to your PdMagic.Common.Math project, they will go in the folder with the project file. This is how the IDE has the opinion we should work, and I think most developers go with it because trying to get any other layout on the file system would require too much fighting with the IDE. I know it can be hard to come from a different convention, and you instinctively want the same conventions in the new environment. However, if you stick with the conventions, (right or wrong in your opinion) you'll get more done because you won't be trying to force the IDE to do things the way you think they should be done.

NerdFury
That's exactly the kind of answer I was looking for. While you were writing it, I was doing some experimenting myself and came up with a (common) case that I'm not sure it can handle. I am targeting both Silverlight and WPF. Most of the source (.cs) is the same, but different assemblies must be built for each. So, I need to have PdMagic.Common.Math for SL and PdMagic.Common.Math for WPF. I think this requires two projects that both use the same Class1.cs. Could I trouble you to take this one step further?Thanks again for your answer.
Pete d'Oronzio