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.
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...
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.
发布评论
评论（5）
您的问题不在于如何使用源代码管理来处理它。
您的问题是您（或管理层）需要让您的团队采用整个团队都遵循的一套标准。
如果你让每个人都遵循自己混杂的想法，而没有在基础上获得团队凝聚力，那么最终只会是泪水......
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...
几乎可以肯定你正在解决错误的问题。如果您分叉 .csproj 文件来满足个人偏好，那么您将承担额外的工作并引入错误的可能性，这正是您所描述的原因 - 每次 Alice 将文件添加到 AlicesX.csproj 时，Bob 都必须了解这一点并将相同的文件添加到 BobsX.csproj。
您确实需要将其视为标准和团队动态问题：就如何在主源中引用 DLL 达成一致，并要求每个人都遵守这一点。如果“失败”一方不喜欢那样工作，当然，他们可以在私人工作副本中使用他们喜欢的风格。但你实际上只想要一个主要来源，并且你希望努力让每个人都接受主要来源的做法。
根据您的编辑：如果您真的、真的无法与您的同事达成一致，那么我仍然建议使用一个大师，但编写一个小实用程序，异议者可以使用该实用程序将项目引用转换为 DLL参考文献（或反之亦然）。 .csproj 文件只是 XML，因此这非常简单。如果您甚至不能就存储库格式达成一致，那么您将需要维护并行的 .csproj 文件，但我仍然会编写实用程序以确保对 DllReferencingProj.csproj 所做的更改复制到 ProjectReferencingProj.csproj。但我仍然说，与发生争吵并解决问题相比，你只是做了更多的工作，为自己积累了更多的痛苦：为了作为一个团队发挥作用，你需要找到某种解决方法争议，这与任何测试用例一样好。
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.
是时候让每个人成长并遵循标准了。如果你们都在处理相同的代码，那么您应该共同决定引用 dll 还是项目是最好的，然后坚持下去。一旦你们弄清楚了这一点，您就可以决定是否缩进 2 个或 4 个空格或一个制表符。然后决定是将大括号放在与函数声明同一行还是放在函数声明之后的下一行。我什至不打算谈论匈牙利表示法的变幻莫测......
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...
我们的配置如下：
您如何使用此配置引用并不重要，将从应用程序文件夹中获取 dll，然后您就可以了。
Our configuration is as follows:
Doesn't much matter how you reference using this configuration, the dlls will be picked up from the application folder and you're golden.
持续集成不应该关心您的 .csproj 文件。我猜它们是 MSBUILD 文件？或者什么？
不要将它们用于 CI。他们是垃圾。他们积累垃圾是因为他们让太多的东西看不见。创建一个独立于它们的干净的构建结构，你会感激你所做的。然后仅在添加内容时签入项目文件，其他人都可以更新/合并。大多数时候您不需要拥有相同甚至相似的项目文件。在我的团队中，我们甚至不会在所有工作站上运行相同版本的 VS。
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.