project-system
project-system copied to clipboard
dotnet
Please do not put source control concerns in the .csproj (SccProjectName, etc)
If you create a new csproj, source control icons in Solution Explorer and change detection do not function properly, and when you open the project Visual Studio prompts you to select source control configuration. To make the problem go away, it inserts this in your csproj:
<PropertyGroup Label="Globals">
<SccProjectName>%24/TFS/Path</SccProjectName>
<SccProvider>{SOME_GUID}</SccProvider>
<SccAuxPath>http://servername:8080/tfs/ProjectCollectionName</SccAuxPath>
<SccLocalPath>.</SccLocalPath>
</PropertyGroup>
First, this is what the legacy csprojs had, and this also works:
<PropertyGroup>
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>
But as should hopefully be clear from the second snippet, this is not providing any information of value which can't already be determined by looking at the workspace mapping. If this was a project under Git source control, that's exactly what Visual Studio would do. It should do the same for TFS and keep the csproj clean of such concerns.
Since you're improving the .csproj story with this project system, please be consistent and consistently separate concerns cleanly. A csproj should be able to go back and forth between Git and TFS source control without changing. The contents of the entire solution should be independent of its location.
@skrysmanski Thanks for reaching out. As of now we haven't scheduled time to work on this. It is unlikely that we will get to this in the near future.
This is so painful when using branches in TFS VC and causes very unnecessary churn and noise in change sets, and code history. Please fix this.
What is the consequence of checking in a branched project that still references the source branch path for this <SccProjectName /> element?
I think VS complains about the source control bindings when you load the solution, but I have "SAK" in the proj files, which makes vs refer to the solution for the binding info.
This should also include getting rid of the vspscc and vssscc files.
https://github.com/dotnet/project-system/issues/1801
Additionally, Visual Studio does not appear to recognise a project file that imports "SAK" versions of these values. Hence they MUST actually be in the project file.
2024 checking in 😄
2036 checking in (yes, we finally have time travel). Still not fixed. Microsoft now owned by Elon Musk. Elon promises to get it fixed by 2019 which, by happenstance, will cascade into a wonderous chain of events that prevents COVID-19 from being a thing. We'll see. Or maybe we won't?
Mixing source control metadata in the csproj file is a terrible idea. Could the following be the default when not specified?
<PropertyGroup>
<SccProjectName>SAK</SccProjectName>
<SccProvider>SAK</SccProvider>
<SccAuxPath>SAK</SccAuxPath>
<SccLocalPath>SAK</SccLocalPath>
</PropertyGroup>
