Skip to content
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

PackageRef project opt-in technique #4488

Open
clairernovotny opened this issue Feb 3, 2017 · 44 comments
Open

PackageRef project opt-in technique #4488

clairernovotny opened this issue Feb 3, 2017 · 44 comments

Comments

@clairernovotny
Copy link

@clairernovotny clairernovotny commented Feb 3, 2017

The issue is that transitive refs with PackageRef isn’t working with P2P refs between CPS and Legacy projects. With PackageRefs, this is supposed to be supported. 

So build the attached project. Try to run Net46ConsoleAppLegacy.exe. It throws due to a missing Newtonsoft.json. Look at the bin\debug directory and you’ll see that the json ref is missing from the output.

By contrast, look at the Net46ConsoleAppCPS project and you’ll see that things work correctly.

There are a few issues in the legacy project:

  1. As you can see in the commented out code in Program.cs of Net46ConsoleAppLegacy, I cannot reference the bottom-most class library directly.
  2. I also cannot use a transitive NuGet reference there either.

Both of these work from the CPS version. This is very weird behavior to have a difference like this.

I get that P2P transitive refs are “new” for CPS, but transitive NuGet refs are not new and work today in VS 2015 with csproj+json. At the very least, I expect #2 to work and for the correct binaries to be in the output directory even if I cannot use types from ClassLibraryWithPackage in Net46ConsoleAppLegacy. The better scenario is that P2P should fully work here too and the Program.cs code in the CPS and Legacy version of the net46 exe should be the same.

SampleSolution.zip

@clairernovotny
Copy link
Author

@clairernovotny clairernovotny commented Feb 3, 2017

This is going to be a very common scenario. People are creating new .NET Standard projects and will add p2p refs to them from their existing "legacy" projects. -- Xamarin, Desktop, etc.

The right binaries won't be in the output directory and people will be confused by this broken behavior.

The only workaround is that you have to add <RestoreProjectStyle>PackageReference</RestoreProjectStyle> to the legacy project.

@davkean
Copy link

@davkean davkean commented Feb 3, 2017

This user ran into it also: dotnet/sdk#757 (comment)

@clairernovotny
Copy link
Author

@clairernovotny clairernovotny commented Feb 3, 2017

As another workaround if RestoreProjectStyle goes away is to use the following dummy packageref in the legacy csproj:

<PackageReference Include="Legacy2CPSWorkaround" Version="1.0.0">
  <PrivateAssets>All</PrivateAssets>
</PackageReference>
@dsplaisted
Copy link

@dsplaisted dsplaisted commented Feb 3, 2017

What do you mean if RestoreProjectStyle goes away? How would that happen?

@rrelyea
Copy link
Contributor

@rrelyea rrelyea commented Feb 3, 2017

It isn't going away for NetCore projects.
We had to remove reading it for non-cps scenarios for RTM.

@dsplaisted
Copy link

@dsplaisted dsplaisted commented Feb 3, 2017

@rrelyea Will there be a way to force a .NET Framework (non-CPS) project into PackageReference mode without actually adding a PackageReference item?

@rrelyea
Copy link
Contributor

@rrelyea rrelyea commented Feb 3, 2017

Another current workaround:
<PackageReference Update="PlaceholderToConvinceThisProjectToGetTransitivePackageReferenceFromProjectReferences"/>

@rrelyea rrelyea added this to the 4.0.1 milestone Feb 3, 2017
@clairernovotny
Copy link
Author

@clairernovotny clairernovotny commented Feb 3, 2017

@rrelyea does that placeholder have to exist? will there be restore errors/failures if it's not there?

@rrelyea
Copy link
Contributor

@rrelyea rrelyea commented Feb 3, 2017

I was just trying to find a workaround that involved a
<PackageReference />
When I tried it like above, it said you need include, remove or update.
Your workaround is to use include with a package that is a noop.
You can also do remove or update. I chose update as less confusing than remove, and somewhat self documenting.

Clearly, we want a more elegant solution.

@clairernovotny
Copy link
Author

@clairernovotny clairernovotny commented Feb 3, 2017

Just wasn't sure with Update what happens if it tries to update a package that doesn't exist.

@rrelyea
Copy link
Contributor

@rrelyea rrelyea commented Feb 3, 2017

I think both remove and update are ok to do with package names that don't exist.

@clairernovotny
Copy link
Author

@clairernovotny clairernovotny commented Feb 18, 2017

@rrelyea I tried the suggestion of using <PackageReference Update="Legacy2CpsWorkaroundBogus"/> and also <PackageReference Update="Legacy2CpsWorkaroundBogus" Version="1.0.0"/> but neither worked. Neither made the restore correct.

The only thing that's worked so far is to use:

    <PackageReference Include="Legacy2CPSWorkaround" Version="1.0.0">
      <PrivateAssets>All</PrivateAssets>
    </PackageReference>
@nguerrera
Copy link

@nguerrera nguerrera commented Mar 9, 2017

Another report: dotnet/roslyn#17639

@rrelyea rrelyea modified the milestones: 4.1, Future-0 Mar 10, 2017
@rrelyea
Copy link
Contributor

@rrelyea rrelyea commented Mar 10, 2017

@jainaashish - We've been able to re-enable RestoreProjectStyle, in 4.1 already, right?

@jainaashish
Copy link
Contributor

@jainaashish jainaashish commented Mar 10, 2017

Yes, we've re-enabled RestoreProjectStyle property in 4.1

@anangaur
Copy link
Member

@anangaur anangaur commented Sep 10, 2018

Talked to @jainaashish and got enlightened on the scenario. Though the fix may seem non trivial for this issue this has repercussions on the VS experience where we show a popup dialogue to users to select the package format (PC vs. PR). Just added this to the list of PC --> PR issues @ #6659. We will be scheduling time to improve the PackageReference experiences and this should part of that.

@kopfsick
Copy link

@kopfsick kopfsick commented Apr 17, 2019

Is this really still an issue without a solution?
I'm planning a migration to Core and Standard for a big application suite of 300+ projects, multiple web applications and desktop applications with shared code, but was planning on not migrating one of the WPF-apps.
Are there no workarounds?

Edit:
Got my prototype working with the Legacy2CPSWorkaround method. Is this still the preferred way to solve this?

4uva added a commit to 4uva/SyndicationFeed that referenced this issue Apr 17, 2019
@James-Lester
Copy link

@James-Lester James-Lester commented Jul 8, 2019

Created a new solution with a WPF project and two .NET Standard projects. Getting the same issue where EF Core, System.Configuration.ConfigurationManager, etc. aren't found by the WPF project when used as dependencies in the .NET Standard projects

Edit: Added the <RestoreProjectStyle>PackageReference</RestoreProjectStyle> item directly under the first <PropertyGroup> in my .NET Framework 4.7.2 .csproj file. Solved the runtime error.

@karann-msft
Copy link
Contributor

@karann-msft karann-msft commented Jul 12, 2019

Per @rrelyea (this is rob typing) - let's spend a few hours this sprint (or soon) and discuss possible solutions and all aspects of the related problem - for new projects, old projects, etc...

@gadeweever
Copy link

@gadeweever gadeweever commented Feb 23, 2020

Solved the same issue with the same workaround from @James-Lester with a .net 4.7.1 project referencing a .net standard 2.0 library.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.