I’m trying to add a NetStandard class library project (Silver) to UWP app project (Visual C#). Both projects are in the same solution. I changed target of the class library to .NET Standard 2.0 and tried to add the NetStandard.Library nuget package, but Visual Studio wouldn’t install it.
If I add the nuget package reference to the .elements project file manually, and then try to add my library as UWP project reference again, VS 2017 says it can’t add it. If I create a Visual C# NetStandard class library I can add it to the UWP project without any problems.
an Elements Library project, set to build for .NET Standard 2.0 (using Silver, but that’s irrelevant)
an Visual C# UWP project
Is the problem adding a reference to the library project to from the UWP app? or adding an (unrelated) NuGet reference to the .NET Standard library? What are the exact steps you are taking, and what is the error?
That said, I don’t believe the UI for adding package references in VS is up to the new way we handle NuGet packages in EBuild, yet. SO if the issue tis ab out adding a NuGet reference to the library project, can you try doing that in Water instead of VS?
Also, I recon mend updating to the latest .2383, just in case.
It’s not possible to add anything via VS2017 UI (library project reference to UWP project and NetStandard.Library Nuget package to library project).
I can add all references(library -> UWP, Nuget -> library) by editing the .elements file but then the project doesn’t compile.
I haven’t tried Water because I was under the assumption that it can’t handle UWP projects (I see only WPF template). Just compiling the library doesn’t help me much because I have to be able to debug it (i.e. set breakpoints and step through code) in the IDE. I only use C# UWP project as a shell and have all my cross platform Swift/Silver code in the library.
Unfortunately, I can’t download .2383 because I don’t have beta access.
Another thing, if my main project has a shared project reference, NuGet packages won’t install. The installation process starts, everything looks normal, but installation is rolled back at the end. If I temporary remove the shared reference I can install NuGet package without problems. Main project type is Silver WPF.
Ok. to the library compiles fine for me here (that’s all thats my area — the UWP and VS-specific issue, someone else needs to take a look at). What Nuget references (name + version) are you trying to add to it, how did you do it when editing the .elements, and how did it fail?
This is what I get in VS2017 output if I try to use the UI to add NetStandard.Library:
Attempting to gather dependency information for package ‘NETStandard.Library.2.0.3’ with respect to project ‘StraightSync.Library’, targeting ‘.NETFramework,Version=v4.0’
Gathering dependency information took 124,7 ms
Attempting to resolve dependencies for package ‘NETStandard.Library.2.0.3’ with DependencyBehavior ‘Lowest’
Resolving dependency information took 0 ms
Resolving actions to install package ‘NETStandard.Library.2.0.3’
Resolved actions to install package ‘NETStandard.Library.2.0.3’
Retrieving package ‘NETStandard.Library 2.0.3’ from ‘nuget.org’.
Install failed. Rolling back…
Package ‘NETStandard.Library.2.0.3’ does not exist in project ‘StraightSync.Library’
Package ‘NETStandard.Library.2.0.3’ does not exist in folder ‘Y:\StraightSync\Client\UWP\packages’
Executing nuget actions took 1,77 sec
Could not install package ‘NETStandard.Library 2.0.3’. You are trying to install this package into a project that targets ‘.NETFramework,Version=v4.0’, but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
@viktoriad: this seems to be a VS/VC# issue? the Elements project itself compiles fine. We probably need to add the GetPackageOutpits task to the targets file. It seems to be a regular project reference in the VC# project.
Niko, does this only fail if the VC# project references the Elements one, or also if you open there Elements one on its own? Also, as a workaround, can you use a regular .dll reference instead of a project one, to see if that works? ie: