How to Handle Different csproj

Question

I am working in a team of 5. We are working on a C# application with 5 csprojects.

The problem is that for each csproject, each of my colleagues has their own ideas on how to reference a dll; some would like to link in by Project reference, other would like to link in the DLL only. So each and everyone of us will have our own csproject.

I want all of them to check in their csproject; but given that every copy of csproject is different, there isn't really a feasible mechanism to do that, is there? But if I don't ask them to check in their csproject, then everytime they add a new file, I would have to manually edit my csproject and that's very tedious, not to mention that it beats the purpose of continuous integration.

Any strategy to handle this? I know it would be best to enforce a standard, but is there any other option leaving this aside?

Edit: There is a reason why the csproject content is different for everyone; not everyone has all of the 5 csprojects, and not everyone can have all of the 5 csprojects. So invariably some will have to end up having to reference dlls instead of projects, and some want to reference by projects for the ease of debugging. If I were to enforce a standard, as the answers here suggest, I would have to solve this issue.

Edit 2: As to why we need to split into a few csproject, that's because we want to reuse some parts of the code for other application, and because not everyone can have all access to the source code. It's more political than technological.

Answer 1

Your problem is not how to handle it with Source Control.

Your problem is that you (or management) needs to get your team to adopt a set of standards the entire team follows.

If you let everyone follow their own mish-mash of ideas and do not get team cohesion on the basics it will only end in tears...

Answer 2

You're almost certainly solving the wrong problem. If you fork the .csproj files to cater to invididual preferences, you are incurring additional work and introducing the likelihood of errors, for exactly the reason you describe -- every time Alice adds a file to AlicesX.csproj, Bob has to learn about this and add the same file to BobsX.csproj.

You really need to consider this as a problem of standards and team dynamics: agree on how DLLs will be referenced in the master sources, and require everyone to stick to that. If the "losing" side don't like to work that way, sure, they can use their preferred style in their private working copies. But you really only want one master source, and you want to work towards getting everybody to buy into the way the master source does it.

Per your edit: If you really, really cannot come to an agreement with your colleagues, then I would still suggest a single master, but write a little utility that the dissenters can use that converts project references to DLL references (or vice versa). .csproj files are just XML so this is pretty trivial to do. If you cannot even agree on what is going to be the repository format, then you will need to maintain parallel .csproj files, but I'd still write the utility to ensure that changes made to DllReferencingProj.csproj get copied to ProjectReferencingProj.csproj. But I still say you're just making more work and storing up more pain for yourself than if you had the squabble and got it over with: in order to function as a team, you're going to need to find some way of resolving disputes, and this is as good as test case as any.

Answer 3

Time to make everyone grow up and follow a standard. If you're all working on the same code you should decide together whether referencing the dll or the project is best and then stick to it. Once you guys figure this one out you can decide whether to indent 2 or 4 spaces or a tab. Then decide whether to put your curly braces on the same line as or the next line after your function declarations. I'm not even going to speak to the vagaries of Hungarian notation...

Answer 4

Continuous integration shouldn't care about your .csproj files. I guess they're MSBUILD files? Or something?

Don't use them for CI. They're junk. They accrue garbage because they make too many things invisible. Create a clean build structure that is independent of them, you'll be thankful you did. And then only check in a project file when you're adding something, and everyone else can update/merge. You don't need to have the same or even similar project files most of the time. On my team we don't even run the same version of VS across all workstations.

Answer 5

Our configuration is as follows:

• Project -> copy dll to common folder
• Project -> copy dll to common folder
• Main Project -> Copy exe to common folder, run application from common folder

Doesn't much matter how you reference using this configuration, the dlls will be picked up from the application folder and you're golden.