I have a .NET Core library with the following project.json:
{
"version": "1.0.0-*",
"dependencies": {
"NETStandard.Library": "1.6.0"
},
"frameworks": {
"netstandard1.6": { }
},
"scripts": {
"postcompile": [
"dotnet pack --no-build --configuration Release",
"xcopy bin\\Release ..\\..\\lib\\ /Y"
]
}
}
where the postcompile script creates a nuget package which I added as a custom feed in VS, following these instructions.
This is because I want to reference it from a Windows Universal App, which cannot be otherwise (yet), according to this question.
But when I try it, I get this message:
Package AEther 1.0.0 is not compatible with uap10.0 (UAP,Version=v10.0).
Package AEther 1.0.0 supports: netstandard1.6 (.NETStandard,Version=v1.6)
One or more packages are incompatible with UAP,Version=v10.0.
This is where it stops making sense to me. According to this, it should work fine for netstandard >=1.6.0, while this official table says I need to target netstandard <=1.4.0, but that doesn't change anything. More confusingly, if I downgrade both versions of netstandard (the dependency and the target framework) to, say, 1.5, I still get this exact same error without specifying 1.6 in any of my files.
Update
The UWP project.json looks like this
{
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.1"
},
"frameworks": {
"uap10.0": {}
},
"runtimes": {
"win10-arm": {},
"win10-arm-aot": {},
"win10-x86": {},
"win10-x86-aot": {},
"win10-x64": {},
"win10-x64-aot": {}
}
}
Can someone clear up either
- How to reference .Net Core libraries from UWP at all or
- What is going on in my specific case?
ANSWER
I solved it adding an import to the UWP app as follows:
{
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.1"
},
"frameworks": {
"uap10.0": { import [ "netstandard1.6" ] }
},
"runtimes": {
"win10-arm": {},
"win10-arm-aot": {},
"win10-x86": {},
"win10-x86-aot": {},
"win10-x64": {},
"win10-x64-aot": {}
}
}
you need to upgrade Microsoft.NETCore.UniversalWindowsPlatform to 5.2.1
Update on July, 15
Ok, here is my result
- create a new UWP
- Upgrade to 5.2.2, which comes out on July, 14
update project.json, import "netstandard1.6"
{
"dependencies": {
"Microsoft.NETCore.UniversalWindowsPlatform": "5.2.2",
"Test": "1.0.0"
},
"frameworks": {
"uap10.0": {
"imports": [
"netstandard1.6"
]
}
},
"runtimes": {
"win10-arm": {},
"win10-arm-aot": {},
"win10-x86": {},
"win10-x86-aot": {},
"win10-x64": {},
"win10-x64-aot": {}
}
}
create a new dotnet core library
- build the library, and generate a nuget package
- I am able to reference the .dll file or the nuget package. And i Do get intelligent while typing code
- UWP is built and deployed successfully, but once i run it, an exception is thrown
This is where it stops making sense to me. According to this, it
should work fine for netstandard >=1.6.0, while this official table
says I need to target netstandard <=1.4.0, but that doesn't change
anything. More confusingly, if I downgrade both versions of
netstandard (the dependency and the target framework) to, say, 1.5, I
still get this exact same error without specifying 1.6 in any of my
files.
Universal Windows Platform maps to netstandard1.4 - neither to 1.6 nor to 1.5. Therefore, your library (called AEther
I assume) has a higher requirement than your UWP app.
- How to reference .Net Core libraries from UWP at all or
As stated in your linked SO question this is not supported yet in Visual Studio.
I can only guess that it is related to the support by the CLI, which is an open issue. As of today, it is expected to be fixed in the version 5.3 of the Microsoft.NETCore.UniversalWindowsPlatform
meta-package - although it was previously expected to be fixed in 5.2.2.
- What is going on in my specific case?
NuGet is telling you that your package supports only the netstandard1.6
target framework but not uap10.0
. Indeed, if you unpack your .nupkg
you'll find your DLL under lib\netstandard1.6
.
Since dotnet pack automatically creates the .nuspec
from your project.json
so you'll need to fix it with the proper framework (eg. netstandard1.4
). It'll probably be easier compiling for different frameworks, for instance Portable profiles compatible with .NET Platform Standard.