Is it possible to work on the same assembly in different projects in .Net?

Question

I'm interested to know how people work in large teams of developers.

I work on my own, and each time I create a brand new control, I create a new project to keep all the related files together.

I have various common helper assemblies that I import but, for the most part, distinct controls are kept in distinct projects.

I'm wondering whether when developers are working on, say, System.Windows.Forms, they are all working on the same project, or on separate projects that are all merged together at some point.

If they are merged together later;-

(1) How is this done?

(2) Is there a way to mark a class as Public but tell it to switch to Friend once it has been merged?

Also, when you come to ship a particular product, is a great deal of time taken up in the extracting, merging, and internalizing of classes for the finished product?

BTW, I use the express edition.

Answer 1

Sure, In addition, I will often have several different solutions that use the same assemblies, or use different subsets of the assemblies within the same "solution space".

One e.g., is to have one solution that has referenced assembly project included as a project (so I can debug into it) and another solution that just has it as a reference dll, where I am not interested in debugging into it.

Answer 2

I think the problem here is the "creating a new project for each control" - that sounds like a bad idea to me. Having to merge later on is a pain.

Admittedly VS makes things worse by having to list the files in the project - it means there's a frequent merge point in source control - but have hundreds of tiny projects doesn't sound scalable to me.

Working with others on the same project can have its downsides too, but overall I'd say that you should work out where your code logically makes sense, and make that the project structure - don't base your code on your team structure and who happens to be doing the work.

Answer 3

The key to this is source control.

Each project in a solution is independent in source control. When setting up your solution, use your source control system's linking feature so that all of your solutions that use a specific project are committing back to the same place. If you need to make a change to a project that's shared among different solutions, that change is committed back to your repository, and you update it in your other solution before continuing to work.

You never want to put yourself in a situation where you're merging projects. Visual Studio solutions can have many projects. That said, you probably want to group individual controls together so that similar items are in the same project, rather than having only one control per project. If you're worried about keeping related files together, you can use folders inside the project instead.

Answer 4

I agree that this is typically where source control comes in, but if you're truly working separately and want to develop on separate project outside of source control, you can always ILMerge related assemblies.

It's really easy to use and can merge the separate assemblies that people work on together into a single assembly with one command on the command line.