Skip to content

Port projects from pkgproj to dotnet pack  #53202

Closed

Description

@Anipik

steps to port projects

Steps to start porting projects

  • Remove PkgProj folder
  • set <IsPackable>true</IsPackable> for src proj
  • Move the PackageDescription from the project's Directory.Build.props file into the csproj.
  • Run the pack command

Examine the package

  • use /p:GenerateCompatibilitySuppressionFile=true to generate suppressions file. Examine the suppresions before automatically suppressing them.
  • https://github.com/Anipik/PackagePortTester to validate the new and old packages are same
  • if there are any extra dependencies, see if the dependency is actuall needed. If not, remove it or add a condition so that it doesn't apply to the TargetFramework. If the ProjectReference is to an inbox framework assembly that does not have a package add PrivateAssets="all" to the ProjectReference.
  • if there are missing references for a compatible framework, add the project reference and a comment explaining why.
  • Removing placeholder frameworks is fine. Do not remove placeholder files though (ie Xamarin).
  • For any extra files compaterror, analyserfiles you will have to hook up to the new pack command (support added for analyzers, & compat errors)
  • Add git diffs to the pr for reviewers.

eg
#55134
#54250

Following is the list of packages that need to be ported to dotnet pack task

cc @ericstj @ViktorHofer @safern

Activity

  1. ghost added
    untriagedNew issue has not been triaged by the area owner
    on May 24, 2021
  2. modified the milestones: Future, 5.0.x, 6.0.0 on May 24, 2021
  3. removed
    untriagedNew issue has not been triaged by the area owner
    on May 24, 2021
  4. ViktorHofer commented on Jun 23, 2021

    @ViktorHofer
    Member

    The System.Composition* projects should already be portable today as they neither have reference assemblies nor runtime assets.

  5. ViktorHofer commented on Jun 23, 2021

    @ViktorHofer
    Member

    Also I just removed the few packages from the list that were dead-ended with 663c40d

  6. ericstj commented on Jun 23, 2021

    @ericstj
    Member

    Is there any ordering requirement for these, or can we just port them at will?

  7. ViktorHofer commented on Jun 23, 2021

    @ViktorHofer
    Member

    nit: this list is incomplete, it's missing the Microsoft.Private.CoreFx.OOB, the Microsoft.Windows.Compatibility and the runtime.native.System.IO.Ports libraries on the libraries side.

    Apart from that, we should also try to get the runtime and host pkgprojs migrated to be able to remove our usage of Microsoft.DotNet.Build.Tasks.Packaging entirely. Those are simple "here are files, please pack them up" projects and could be worked on in parallel to the libraries packages.

  8. Anipik commented on Jul 4, 2021

    @Anipik
    ContributorAuthor

    Is there any ordering requirement for these, or can we just port them at will?

    we have added the required infra and we have some example prs as well. we can start trimming this list down.

  9. ghost added
    in-prThere is an active PR which will close this issue when it is merged
    on Aug 4, 2021
  10. ghost removed
    in-prThere is an active PR which will close this issue when it is merged
    on Aug 5, 2021
  11. ghost locked as resolved and limited conversation to collaborators on Sep 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions