Skip to content

Investigate 6.0 SDK diff: unnecessary runtime/ folders #2573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dagood opened this issue Oct 25, 2021 · 3 comments · Fixed by dotnet/installer#16692
Closed

Investigate 6.0 SDK diff: unnecessary runtime/ folders #2573

dagood opened this issue Oct 25, 2021 · 3 comments · Fixed by dotnet/installer#16692
Labels
area-product-experience Improvements in the end-user's product experience

Comments

@dagood
Copy link
Member

dagood commented Oct 25, 2021

Files like ./sdk/6.0.100/DotnetTools/dotnet-format/runtimes/browser/lib/net6.0/System.Text.Encodings.Web.dll show up in the source-built SDK but not the Microsoft-built SDK. They are most likely not interfering with any functionality, but we should figure out why they're showing up, and ideally fix this diff.

dagood#9 (comment)

@dagood dagood added the area-product-experience Improvements in the end-user's product experience label Oct 25, 2021
@ghost ghost added the untriaged label Oct 25, 2021
@MichaelSimons MichaelSimons moved this to 6.0 BackLog in .NET Source Build Feb 1, 2022
@MichaelSimons MichaelSimons moved this from 6.0 BackLog to 7.0 Backlog in .NET Source Build Apr 28, 2022
@MichaelSimons MichaelSimons moved this from 7.0 On Deck to 8.0 On Deck in .NET Source Build Oct 13, 2022
@MichaelSimons MichaelSimons moved this from 8.0 On Deck to 8.0 Backlog in .NET Source Build Dec 12, 2022
@MichaelSimons MichaelSimons moved this from Needs Review to 8.0 Backlog in .NET Source Build Jun 8, 2023
@NikolaMilosavljevic
Copy link
Member

I see the opposite in 8.0 SDK diff. The following files are only present in Microsoft-built SDK:

sdk/8.0.100-preview.6.23309.1/DotnetTools/dotnet-format/runtimes/unix/lib/net6.0/System.Drawing.Common.dll
sdk/8.0.100-preview.6.23309.1/DotnetTools/dotnet-format/runtimes/win/lib/net6.0/Microsoft.Win32.SystemEvents.dll
sdk/8.0.100-preview.6.23309.1/DotnetTools/dotnet-format/runtimes/win/lib/net6.0/System.Drawing.Common.dll
sdk/8.0.100-preview.6.23309.1/DotnetTools/dotnet-format/runtimes/win/lib/net6.0/System.Security.Cryptography.ProtectedData.dll
sdk/8.0.100-preview.6.23309.1/DotnetTools/dotnet-format/runtimes/win/lib/net6.0/System.Windows.Extensions.dll

@MichaelSimons I presume the fix is needed in 8.0 SDK only - or are we considering backporting all changes to older, still-supported source-built SDKs?

@MichaelSimons
Copy link
Member

8.0 only, we are not backporting these changes.

The 8.0 diff is more logical - System.Drawing.Common.dll, Microsoft.Win32.SystemEvents.dll, and System.Windows.Extensions.dll are windows only assemblies. System.Security.Cryptography.ProtectedData.dll is unknown though. Is that a transitive dependency?

@NikolaMilosavljevic
Copy link
Member

8.0 only, we are not backporting these changes.

The 8.0 diff is more logical - System.Drawing.Common.dll, Microsoft.Win32.SystemEvents.dll, and System.Windows.Extensions.dll are windows only assemblies. System.Security.Cryptography.ProtectedData.dll is unknown though. Is that a transitive dependency?

Yes, it is transitive, via System.Configuration.ConfigurationManager. But, also it seems to be used on Windows platforms only - here's the relevant part in deps.json file:

      "System.Security.Cryptography.ProtectedData/6.0.0": {
        "runtime": {
          "lib/net6.0/System.Security.Cryptography.ProtectedData.dll": {
            "assemblyVersion": "6.0.0.0",
            "fileVersion": "6.0.21.52210"
          }
        },
        "runtimeTargets": {
          "runtimes/win/lib/net6.0/System.Security.Cryptography.ProtectedData.dll": {
            "rid": "win",
            "assetType": "runtime",
            "assemblyVersion": "6.0.0.0",
            "fileVersion": "6.0.21.52210"
          }
        }
      },

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-product-experience Improvements in the end-user's product experience
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants