Please do not put source control concerns in the .csproj (SccProjectName, etc)

jnm2 commented 7 years ago

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.

fe-c commented 7 years ago

I am fully encourage.

abpiskunov commented 7 years ago

skrysmanski commented 4 years ago

@jjmew @davkean Is there any progress on this issue?

jjmew commented 4 years ago

@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.

StingyJack commented 4 years ago

This should also include getting rid of the vspscc and vssscc files.

Jaans commented 3 years ago

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?

StingyJack commented 3 years ago

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.

jnm2 commented 3 years ago

This should also include getting rid of the vspscc and vssscc files.

https://github.com/dotnet/project-system/issues/1801

RachelDavids commented 3 years ago

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.

sk0va commented 3 years ago

2021... any updates?

nthornton2010 commented 2 years ago

2022 here wondering if there are any updates

TrabacchinLuigi commented 1 year ago

2023 let's hope!

rkaltenbach-wis commented 8 months ago

2024 checking in 😄

Mythran101 commented 6 months ago

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?

Wdestroier commented 2 months ago

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>

dotnet / project-system

Please do not put source control concerns in the .csproj (SccProjectName, etc) #1802