Introduce PublishSelfContained

[nagilson]

Summary

Adds PublishSelfContained (PSC):

1. You can add

<PublishSelfContained>true</PublishSelfContained>

to publish self-contained by default but not build self-contained by default. You can of course also forward the property.

Examples

dotnet publish --sc=false -p:PublishSelfContained=true -> Not Self Contained
dotnet publish /p:SelfContained=false -p:PublishSelfContained=true -> Not Self Contained
dotnet publish -p:PublishSelfContained=true -> Self Contained
dotnet publish -p:PublishSelfContained=false -> Not Self Contained

In a project file:

<PublishSelfContained>true</PublishSelfContained> 
<SelfContained>false</SelfContained>

dotnet publish -> SelfContained

<PublishSelfContained>false</PublishSelfContained> 
<SelfContained>true</SelfContained>

dotnet publish -> Not SelfContained

dotnet build -p:PublishSelfContained=true -> Not Self Contained

Long Form Explanation of changes

2. If you do dotnet publish --no-sc -p:PublishSelfContained=true, --no-sc will win. Also true if PublishSelfContained is in the properties. Also true for other variants of --no-sc like /p:SelfContained=false. I got it to work the other way where PSC would win but we'd really, really prefer not to do it like that because it could break a lot of stuff.

3. If you do dotnet publish and <SelfContained>false</SC> in the project file but PublishSelfContained is true in the project file or in the CLI, then PSC will win. Likewise, If PSC is false but SC is true in the project file, PSC will win. Like stated above, if SC is stated in the command invocation, SC will win.

Blurbs about the logistical things

4. Had a large group discussion about getting _IsPublishing to work in MSBuild with t:/Publish -- it's not possible. (We may not actually need _IsPublishing to do this one, but we do for PublishRID and PublishRelease, so it's probably better to keep them aligned.) But we are going to do work to get it to align with VS. We'll need to make changes in their repo(s), but it shouldn't affect anything here, I'd hope. Not sure if we want to wait to merge until we can tell folks they can use this in VS.

5. PublishSelfContained will also imply a RID but only if we're publishing, since this property should only do anything if you're publishing. IIRC other publish properties already had a history of failing build without a RID.

[nagilson]

Pipeline failure is due to infrastructure.

##[error].packages/microsoft.dotnet.arcade.sdk/7.0.0-beta.22464.4/tools/Tools.proj(0,0): error NU1301: (NETCORE_ENGINEERING_TELEMETRY=Restore) Failed to retrieve information about 'Microsoft.SymbolUploader.Build.Task' from remote source 'https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/3e04f704-20f0-4deb-929d-a189c3a4dae4/nuget/v3/flat2/microsoft.symboluploader.build.task/index.json'.
  Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/49e5305d-d845-4a14-9d69-6f5dbfb9570c/nuget/v3/flat2/sn/index.json'.
  Response status code does not indicate success: 429 ().

[dsplaisted]

I might be missing something, but I think the logic can be simplified a lot to not need to even check if SelfContained is a global property.

I didn't look at the tests much yet.

[nagilson]

@dsplaisted Responded to the feedback, please take a look again when you have availability. Thanks!
(btw the test code is old so it uses HelloWorld, in the future I plan to use the testproject more)

[nagilson]

@dsplaisted I implemented all of the requested test changes. (Thanks, I should be less sloppy with my tests).

EDIT: About the below content, I saw you said we can change where property values.txt is recorded. Ill go ahead and look into that instead.

I think the one thing you may object to / the only other thing worth looking at is that I added https://github.com/dotnet/sdk/pull/28714/files#diff-95fe3aebd6a9400190035038d2c2976fae64579c63dc1c5d4d912f7bc53790bbR478 this change to TestProject where you can provide the GetPropertyValues function a hard-path instead of a test directory + properties. The alternative I saw was to support automatic RID folders in the original function, or to add back in the RID into the test, but I think this would be useful in a few of the other tests I wrote.

Obvious problems with this solution:
It encourages hardcoding the path which will make the test migration harder if this is used a lot more
it may be the first overload people see instead of the testRoot overload which is what they generally should use, almost always.

[dsplaisted]

The alternative I was thinking of was to not write the file in a RID-specific path. IE update the injected target in TestProject.Create to something like this:

                string injectTargetContents =
    $@"<Project>
  <Target Name=`WritePropertyValues` BeforeTargets=`AfterBuild`>
    <ItemGroup>
{propertiesElements}
    </ItemGroup>
    <WriteLinesToFile
      File=`$(BaseIntermediateOutputPath)\$(Configuration)\$(TargetFramework)\PropertyValues.txt`
      Lines=`@(LinesToWrite)`
      Overwrite=`true`
      Encoding=`Unicode`
      />
  </Target>
</Project>";

[nagilson]

That makes sense. The PublishRuntimeIdentifier tests need this too and I added it there. I think I should retarget both of these to 7.0.2xx. And then merge the publish RID PR. Then merge this with 7.0.2xx and change the test.