Home: NuGet restore fails with .NET452 -> UAP ref (valid for UWP designer)
@dotMorten has been trying to implement designers for the UWP Toolkit controls. The pattern here is that the designer project is .NET Framework project that references a UWP control library project. This seems to fail with PackageReference:
https://github.com/Microsoft/UWPCommunityToolkit/commits/dotMorten/DesignAssembly
This was from the above branch calling msbuild /t:restore on the design project. This is a blocker for the toolkit… any workarounds?
"C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls.Design\Microsoft.Toolkit.Uwp.UI.Controls.Design.csproj" (restore target) (1) ->
(Restore target) ->
C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls.Design\Microsoft.Toolkit.Uwp.UI.Controls.Design.csproj : error NU1201: Project
Microsoft.Toolkit.Uwp.UI.Controls is not compatible with net452 (.NETFramework,Version=v4.5.2). Project Microsoft.Toolkit.Uwp.UI.Controls su
pports: uap10.0 (UAP,Version=v10.0)
C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls.Design\Microsoft.Toolkit.Uwp.UI.Controls.Design.csproj : error NU1201: Project
Microsoft.Toolkit.Uwp.UI.Controls is not compatible with net452 (.NETFramework,Version=v4.5.2) / win. Project Microsoft.Toolkit.Uwp.UI.Contr
ols supports: uap10.0 (UAP,Version=v10.0)
C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls.Design\Microsoft.Toolkit.Uwp.UI.Controls.Design.csproj : error NU1201: Project
Microsoft.Toolkit.Uwp.UI.Controls is not compatible with net452 (.NETFramework,Version=v4.5.2) / win-x64. Project Microsoft.Toolkit.Uwp.UI.C
ontrols supports: uap10.0 (UAP,Version=v10.0)
C:\dev\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls.Design\Microsoft.Toolkit.Uwp.UI.Controls.Design.csproj : error NU1201: Project
Microsoft.Toolkit.Uwp.UI.Controls is not compatible with net452 (.NETFramework,Version=v4.5.2) / win-x86. Project Microsoft.Toolkit.Uwp.UI.C
ontrols supports: uap10.0 (UAP,Version=v10.0)
0 Warning(s)
4 Error(s)
clairernovotny
All 25 comments
@rohit21agrawal is doing some initial investigation here.
rrelyea
on 21 Sep 2017
@dotMorten @onovotny the issue here is that NuGet has never checked for Project Reference compatibility in the packages.config world but it does so in the PackageReference world - which is what you are seeing. a net452 -> uap10.0 reference is incompatible.
Even with the packages.config workaround, are you able to build your project? I would be surprised if you are able to.
rohit21agrawal
on 21 Sep 2017
@rohit21agrawal Yes, this is how the UWP design-time assemblies are built.
clairernovotny
on 21 Sep 2017
not sure what NuGet can do here. if we stop looking at compat between project references, apart from violating package-project duality , we will also not be able to flow dependencies transitively since we won't know what's compatible with what.
rohit21agrawal
on 21 Sep 2017
let me discuss more in detail with @emgarten and @rrelyea and give an update.
rohit21agrawal
on 21 Sep 2017
How about being able to define an explicit opt-out in the package reference?
dotMorten
on 22 Sep 2017
could you elaborate more? are you talking about opting-out of compatibility check for P2P references?
rohit21agrawal
on 22 Sep 2017
Yeah something along the lines of this:
<PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform" CompatibilityCheck="False">
<Version>5.4.0</Version>
</PackageReference>
...or a platform override:
<PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform" ForceTargetPlatform="uap10.0">
<Version>5.4.0</Version>
</PackageReference>
I suggest adding a ValidateFrameworkCompatibility property to disable TFM checks for everything. This would match the ValidateRuntimeIdentifierCompatibility property that exists today for RID checks.
<PropertyGroup>
<ValidateFrameworkCompatibility>false</ValidateFrameworkCompatibility>
</PropertyGroup>
Having this option on a per item basis requires a resolving conflicting settings across the dependency graph. For example if a package has compat turned off it makes sense that the transitive dependencies are also ignored, but if another package has the same dependencies it isn't obvious how those are treated.
The same applies to turning off compat only for projects or only for packages. If compat it ignored for a project then the transitive package dependencies from that project would also need to be ignored since they could be meant for an incompatible TFM, and the same thing as above occurs again.
For that reason I think this should be a simple on/off. If you need to do custom things that require breaking basic compat rules you can disable the checks but need to be very careful to avoid runtime problems that could result.
emgarten
on 22 Sep 2017
I'll absolutely admit this is an edge-case and could/should require some kind of property to override default settings and enable this.
clairernovotny
on 22 Sep 2017
I worked around it by using a good old assembly reference instead of a project reference. Not pretty but it unblocks us
dotMorten
on 22 Sep 2017
I like the <Reference /> solution.
Given that this is a very rare scenario, I'd prefer to minimize investment in this area. When @rohit21agrawal, @emgarten and I are all in the same place at the same time, we'll discuss the options a bit...
rrelyea
on 22 Sep 2017
@onovotny @dotMorten there is one more work around that could potentially make this work if you want to give this a try:
<ProjectReference Include="..\Microsoft.Toolkit.Uwp.UI.Controls\Microsoft.Toolkit.Uwp.UI.Controls.csproj" Condition="'$(ExcludeRestorePackageImports)' != 'true'">
<Project>{e9faabfb-d726-42c1-83c1-cb46a29fea81}</Project>
<Name>Microsoft.Toolkit.Uwp.UI.Controls</Name>
<Private>False</Private>
</ProjectReference>
Let me know if this works for you.
rohit21agrawal
on 23 Sep 2017
Yes, we aren't planning more work here. Using a ProjectReference with Condition="'$(ExcludeRestorePackageImports)' != 'true'" is probably the most elegant way to make project reference be ignored by NuGet restore.
rrelyea
on 25 Sep 2017
@rrelyea @rohit21agrawal @emgarten Thanks for all the suggestions. Just circling back now.
ValidateFrameworkCompatibility works great for getting rid of the reference warnings inside Visual Studio.
The project reference with ExcludeRestorePackageImports didn't work for me, but that's ok - I can use a direct assembly reference.
However, the bad news is none of that works when building from the commandline. I'm still getting compile time errors there.
msbuild /t:build "UWP Community Toolkit.sln" /p:Configuration=Release /p:Platform="Any CPU"
Branch is updated with my changes: https://github.com/Microsoft/UWPCommunityToolkit/compare/dotMorten/DesignAssembly
dotMorten
on 11 Oct 2017
it looks like SDK is doing TFM compatibility check too. @nguerrera @dsplaisted any ideas?
rohit21agrawal
on 11 Oct 2017
Yes, the SDK does TFM compatibility checks, and with https://github.com/Microsoft/msbuild/pull/2595 MSBuild will be doing them instead.
dsplaisted
on 11 Oct 2017
This is a blocker as a .NET -> UWP reference is valid for the purpose of creating designer controls.
clairernovotny
on 11 Oct 2017
@dsplaisted Is there any workaround we can do so the UWP toolkit can get design-time assembly support checked in?
dotMorten
on 11 Oct 2017
also, @dotMorten i am interested in knowing why ProjectReference didn't work for you with ExcludeRestorePackageImports set? can you show the restore errors you got there?
rohit21agrawal
on 11 Oct 2017
@rohit21agrawal The project reference with ExcludeRestorePackageImports wouldn't even allow me to build from within Visual Studio:
1>C:\Program Files\dotnet\sdk\2.0.2\Sdks\Microsoft.NET.Sdk\build\Microsoft.NET.Sdk.Common.targets(87,5): error : Project 'C:\GitHub\Microsoft\UWPCommunityToolkit\Microsoft.Toolkit.Uwp.UI.Controls\Microsoft.Toolkit.Uwp.UI.Controls.csproj' targets 'UAP,Version=v10.0'. It cannot be referenced by a project that targets '.NETFramework,Version=v4.5.2'.
...and that is with ValidateFrameworkCompatibility set to false.
dotMorten
on 11 Oct 2017
CC: @unniravindranathan - the workaround that nuget provided is potentially going to be unusable if SDK (and eventually msbuild) is going to be doing compatibility checks as well.
@dsplaisted is there a way to opt out of compatibility check that SDK (and eventually msbuild ) does?
rohit21agrawal
on 11 Oct 2017
Looking at the MSBuild code, I think you can set the metadata SkipGetTargetFrameworkProperties="true" on the ProjectReference, and I think this will work both before and after the compatibility check moves to MSBuild.
dsplaisted
on 11 Oct 2017
@dsplaisted You're a friggin superhero! It even makes the project reference work!
dotMorten
on 12 Oct 2017
awesome! glad this is resovled! Thanks @dsplaisted
rohit21agrawal
on 12 Oct 2017
Related issues
mrward
·
3Comments
LordMike
·
3Comments
augustoproiete
·
3Comments
livarcocc
·
3Comments
livarcocc
·
3Comments
Most helpful comment
I suggest adding a
ValidateFrameworkCompatibilityproperty to disable TFM checks for everything. This would match theValidateRuntimeIdentifierCompatibilityproperty that exists today for RID checks.Having this option on a per item basis requires a resolving conflicting settings across the dependency graph. For example if a package has compat turned off it makes sense that the transitive dependencies are also ignored, but if another package has the same dependencies it isn't obvious how those are treated.
The same applies to turning off compat only for projects or only for packages. If compat it ignored for a project then the transitive package dependencies from that project would also need to be ignored since they could be meant for an incompatible TFM, and the same thing as above occurs again.
For that reason I think this should be a simple on/off. If you need to do custom things that require breaking basic compat rules you can disable the checks but need to be very careful to avoid runtime problems that could result.