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
onovotny opened this Issue Feb 3, 2017 · 34 comments

Comments

@onovotny

onovotny 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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

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

onovotny 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

This comment has been minimized.

Show comment
Hide comment
@davkean

davkean Feb 3, 2017

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

davkean commented Feb 3, 2017

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny 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>

onovotny 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

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted Feb 3, 2017

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

dsplaisted commented Feb 3, 2017

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Feb 3, 2017

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@dsplaisted

dsplaisted 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?

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

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Feb 3, 2017

Contributor

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

Contributor

rrelyea commented Feb 3, 2017

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

@rrelyea rrelyea added this to the 4.0.1 milestone Feb 3, 2017

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Feb 3, 2017

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

onovotny commented Feb 3, 2017

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Feb 3, 2017

Contributor

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.

Contributor

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.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Feb 3, 2017

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

onovotny commented Feb 3, 2017

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Feb 3, 2017

Contributor

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

Contributor

rrelyea commented Feb 3, 2017

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

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny 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>

onovotny 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

This comment has been minimized.

Show comment
Hide comment
@nguerrera

nguerrera commented Mar 9, 2017

Another report: dotnet/roslyn#17639

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Mar 10, 2017

Contributor

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

Contributor

rrelyea commented Mar 10, 2017

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

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Mar 10, 2017

Contributor

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

Contributor

jainaashish commented Mar 10, 2017

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

@rrelyea

This comment has been minimized.

Show comment
Hide comment
@rrelyea

rrelyea Mar 15, 2017

Contributor

Reached out to unni to get PM owner for this issue.

Contributor

rrelyea commented Mar 15, 2017

Reached out to unni to get PM owner for this issue.

@ptsoccer

This comment has been minimized.

Show comment
Hide comment
@ptsoccer

ptsoccer Apr 10, 2017

Is there a workaround for VS2015 based solutions, or am I possibly doing something wrong? I used some of the workarounds above but it doesn't seem like my project files supports XML tags such as "RestoreProjectStyle". Currently I'm having to manually add nuget packages to my top-level win32 exe solutions every time I get a runtime error because of the missing dlls in the output directory. This type of error is terrifying to me as I have no good way of knowing if I'm missing a nuget reference in the top-level exe.

ptsoccer commented Apr 10, 2017

Is there a workaround for VS2015 based solutions, or am I possibly doing something wrong? I used some of the workarounds above but it doesn't seem like my project files supports XML tags such as "RestoreProjectStyle". Currently I'm having to manually add nuget packages to my top-level win32 exe solutions every time I get a runtime error because of the missing dlls in the output directory. This type of error is terrifying to me as I have no good way of knowing if I'm missing a nuget reference in the top-level exe.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Apr 23, 2017

@jainaashish Is setting <RestoreProjectStyle>PackageReference</RestoreProjectStyle> the correct manual workaround for this scenario?

Will this be needed in 4.3/15.3 anymore or will it "just work" there?

onovotny commented Apr 23, 2017

@jainaashish Is setting <RestoreProjectStyle>PackageReference</RestoreProjectStyle> the correct manual workaround for this scenario?

Will this be needed in 4.3/15.3 anymore or will it "just work" there?

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish May 17, 2017

Contributor

@onovotny for now, this is the correct manual workaround. We haven't yet finalized the default opt-in experience for PackageReference but I'll let you know as soon as we have something there.

Contributor

jainaashish commented May 17, 2017

@onovotny for now, this is the correct manual workaround. We haven't yet finalized the default opt-in experience for PackageReference but I'll let you know as soon as we have something there.

@Portikus

This comment has been minimized.

Show comment
Hide comment
@Portikus

Portikus May 31, 2017

Is it just me or is this fixed with the newest Visual Studio Update 15.2 (26430.12)? I am able to remove the workaround.

Portikus commented May 31, 2017

Is it just me or is this fixed with the newest Visual Studio Update 15.2 (26430.12)? I am able to remove the workaround.

@Timmitry

This comment has been minimized.

Show comment
Hide comment
@Timmitry

Timmitry Jun 1, 2017

I'd also like to know about possible workarounds or solutions for Visual Studio 2015. It's really bad to have exceptions at runtime because of Nuget-DLLs not found in the output path...

Timmitry commented Jun 1, 2017

I'd also like to know about possible workarounds or solutions for Visual Studio 2015. It's really bad to have exceptions at runtime because of Nuget-DLLs not found in the output path...

@mess285

This comment has been minimized.

Show comment
Hide comment
@mess285

mess285 Jun 6, 2017

@Portikus same for me looks like they fix it.

mess285 commented Jun 6, 2017

@Portikus same for me looks like they fix it.

@onovotny

This comment has been minimized.

Show comment
Hide comment
@onovotny

onovotny Jun 6, 2017

@Portikus @mess285 Using 15.2, with a regular project referencing the CPS ones, it's not working for me without <RestoreProjectStyle>PackageReference</RestoreProjectStyle> being set. Is that what you are referring to?

onovotny commented Jun 6, 2017

@Portikus @mess285 Using 15.2, with a regular project referencing the CPS ones, it's not working for me without <RestoreProjectStyle>PackageReference</RestoreProjectStyle> being set. Is that what you are referring to?

@Portikus

This comment has been minimized.

Show comment
Hide comment
@Portikus

Portikus Jun 12, 2017

@onovotny You are right. I tried your attached solution and it seems that it isn't fixed with the latest update. I'm sorry.

Portikus commented Jun 12, 2017

@onovotny You are right. I tried your attached solution and it seems that it isn't fixed with the latest update. I'm sorry.

@jainaashish jainaashish modified the milestones: 4.4, 4.3 Jun 20, 2017

barnstee added a commit to OPCFoundation/UA-.NETStandard that referenced this issue Jun 28, 2017

@Code-ScottLe

This comment has been minimized.

Show comment
Hide comment
@Code-ScottLe

Code-ScottLe Sep 22, 2017

Do we have a roadmap on when this thing gets fixed? On the latest Preview Build of VS 2017 (Nuget 4.4.0.4453) , I am still seeing this problem.

Code-ScottLe commented Sep 22, 2017

Do we have a roadmap on when this thing gets fixed? On the latest Preview Build of VS 2017 (Nuget 4.4.0.4453) , I am still seeing this problem.

@zhili1208 zhili1208 modified the milestones: 4.4, Backlog Nov 10, 2017

@michael-hawker

This comment has been minimized.

Show comment
Hide comment
@michael-hawker

michael-hawker Dec 5, 2017

Is this the same issue I'm seeing with Windows Runtime Components as well? Trying to reference Json.NET in a Windows Runtime Component used by a JavaScript based UWP project is throwing this error:

0x80070002 - JavaScript runtime error: The system cannot find the file specified.

System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.

If I copy the dll into the AppX output though it works fine.

JSJSONTest.zip

michael-hawker commented Dec 5, 2017

Is this the same issue I'm seeing with Windows Runtime Components as well? Trying to reference Json.NET in a Windows Runtime Component used by a JavaScript based UWP project is throwing this error:

0x80070002 - JavaScript runtime error: The system cannot find the file specified.

System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.

If I copy the dll into the AppX output though it works fine.

JSJSONTest.zip

@Huqin-China

This comment has been minimized.

Show comment
Hide comment
@Huqin-China

Huqin-China Dec 8, 2017

Desktop project still having this problem in VS15.5

Huqin-China commented Dec 8, 2017

Desktop project still having this problem in VS15.5

@esencu

This comment has been minimized.

Show comment
Hide comment
@esencu

esencu Feb 20, 2018

Have this issue with UWP project in VS15.5.6

esencu commented Feb 20, 2018

Have this issue with UWP project in VS15.5.6

@joozek78

This comment has been minimized.

Show comment
Hide comment
@joozek78

joozek78 Apr 13, 2018

I have the same problem in VS2017 with old csproj format. Does that mean that I can't use .NET Standard libraries (that has references) in .NET Framework projects? I thought that was the whole idea of .NET Standard :(

joozek78 commented Apr 13, 2018

I have the same problem in VS2017 with old csproj format. Does that mean that I can't use .NET Standard libraries (that has references) in .NET Framework projects? I thought that was the whole idea of .NET Standard :(

@NetTecture

This comment has been minimized.

Show comment
Hide comment
@NetTecture

NetTecture Jun 8, 2018

It is even worse -you do not even need an old style project.

I am writing a netstandard library that contains a powershell core module.

I can not debug or easily package it because it misses all references, among them entity framework core (and yes, this particular one needs db access).

What is the workaround in this case? I do not ahve an old style project - I only have one project, which is a nestandard 2.0 class library. I need all referenced assemblies in the folder.

NetTecture commented Jun 8, 2018

It is even worse -you do not even need an old style project.

I am writing a netstandard library that contains a powershell core module.

I can not debug or easily package it because it misses all references, among them entity framework core (and yes, this particular one needs db access).

What is the workaround in this case? I do not ahve an old style project - I only have one project, which is a nestandard 2.0 class library. I need all referenced assemblies in the folder.

@gusmanb

This comment has been minimized.

Show comment
Hide comment
@gusmanb

gusmanb Jun 26, 2018

I'm on the same boat as NetTecture, any solution?

gusmanb commented Jun 26, 2018

I'm on the same boat as NetTecture, any solution?

@jamescrowley

This comment has been minimized.

Show comment
Hide comment
@jamescrowley

jamescrowley Jul 22, 2018

I'm figuring out how to migrate a large MVC app. Right now, the plan had been to migrate all class libraries to .NET standard whilst leaving the MVC project in place in the old project format as an interim step. This issue appears to completely block us, unless anyone has a suggested workaround?

jamescrowley commented Jul 22, 2018

I'm figuring out how to migrate a large MVC app. Right now, the plan had been to migrate all class libraries to .NET standard whilst leaving the MVC project in place in the old project format as an interim step. This issue appears to completely block us, unless anyone has a suggested workaround?

@jainaashish

This comment has been minimized.

Show comment
Hide comment
@jainaashish

jainaashish Jul 23, 2018

Contributor

@jamescrowley this issue is more about file new project by default is old project format until you add a nuget package dependency which allows you to choose between new format vs old. And the workaround for that is to set RestoreProjectStyle to new format.

But your issue is different, you already have a bunch of old styled projects, and you're moving some of those to new format. Although partial migration might not give you all the advantages of new format but this should still work. What is failing for you in this case?

Contributor

jainaashish commented Jul 23, 2018

@jamescrowley this issue is more about file new project by default is old project format until you add a nuget package dependency which allows you to choose between new format vs old. And the workaround for that is to set RestoreProjectStyle to new format.

But your issue is different, you already have a bunch of old styled projects, and you're moving some of those to new format. Although partial migration might not give you all the advantages of new format but this should still work. What is failing for you in this case?

@jamescrowley

This comment has been minimized.

Show comment
Hide comment
@jamescrowley

jamescrowley Jul 24, 2018

@jainaashish thanks for chiming in. Let me double check this again - may have been thrown off the scent by one of the other issues linking here.

jamescrowley commented Jul 24, 2018

@jainaashish thanks for chiming in. Let me double check this again - may have been thrown off the scent by one of the other issues linking here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment