4

I have a UWP app and a bunch of NETStandard 2.0 libraries. The libraries contains a lot of logic and communication interfaces that I am using in ASP.NetCore and Desktop WPF applications, so I am not going to change them.

I use NuGet packages in the libraries so I could reference those in NetCore and NetFramework projects as well. I would like to reference these packages in the UWP project - cause this is the whole point of this standardization concept isn't it?

For the UWP project this does not work. I have the latest Nuget package of System.ServiceModel.Primitives which is 4.5.3 (DLL version 4.5.0.3 - don't ask why) and PublicKeyToken is b03f5f7f11d50a3a - this can be referenced in every project except UWP.

Regardless of every attempt: - I have installed the Nuget package for the project - I have referenced the version explicitly in the CSPROJ file - I have removed every other reference to SDK file version

But still, the UWP project looks for the dll in

C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.netcore.universalwindowsplatform\6.2.8\ref\uap10.0.15138\System.ServiceModel.Primitives.dll

That DLL has version of 4.2.1.1 and the PublicKeyToken is cc7b13ffcd2ddd51

Because the two tokens are different - binding redirects does not work - or maybe I am missing something. Does anyone have a workaround for this?

The whole solution is in VS2019 and I have the latest Win10 SDK installed 10.0.18362.1.

Thank you in advance.

EDIT: I forgot to mention, I have a repro on GitHub

Daniel Leiszen
  • 1,827
  • 20
  • 39
  • 1
    Have a look at this SO [thread](https://stackoverflow.com/questions/50675788/using-assembly-redirection-in-uwp-c-sharp) and this [article](https://michaelscodingspot.com/how-to-resolve-net-reference-and-nuget-package-version-conflicts/) I think, you'll need to incapsulate your logic into separate .NET Standard assembly and setup binding redirects for strongly typed assemblies using `codebase` – Pavel Anikhouski Jul 18 '19 at 13:33
  • 1
    Strange behavior. When I create a uwp blank project, it will fetch the references from `C:\Program Files (x86)\Microsoft SDKs\UWPNuGetPackages\microsoft.netcore.universalwindowsplatform` instead of normal location `C:\Users\xxx\.nuget\packages` I believe that's some default behavior for uwp.(The team may define this rule in an unknown config file). In most of the time it won't affect your app development. – LoLance Jul 19 '19 at 06:41
  • 1
    But since the two System.ServiceModel.Primitives have the same name but different Token, the issue occurs. So I suggest you report this issue by Visual Studio "report a problem" tool to let the related team know about this. – LoLance Jul 19 '19 at 06:41
  • Thank you @LanceLi-MSFT. I have already created a github issue at https://github.com/dotnet/wcf/issues/3743. In the meantime I am trying to reorganize my code as Pavel Anikhouski suggested and see if that works. – Daniel Leiszen Jul 19 '19 at 12:22
  • @PavelAnikhouski thank you for your suggestion. It does seem to be a workaround in my case. It was enough to reorganize my code and put everything that depended on System.ServiceModel into a separate NET Standard project. The executable UWP does not contain anything else than XAML files and some bootstrapping code. Would you please answer my question so I could mark that as a correct answer. Thx – Daniel Leiszen Jul 21 '19 at 13:47
  • @DanielLeiszen I'm glad that can help with this dll hell. I've added the answer – Pavel Anikhouski Jul 21 '19 at 18:54
  • 1
    @DanielLeiszen Hi friend, It seems PA's answer helps to resolve this issue, if so, you can consider marking it as answer. Just a reminder:) – LoLance Jul 31 '19 at 01:38
  • Sure thing :) Thx – Daniel Leiszen Aug 01 '19 at 07:34

1 Answers1

3

You can create a separate .NET Standard project and incapsulate all your logic (and usage of System.ServiceModel.Primitives assembly) into this project. Then you can add it as a reference to the project with UWP executable.

Also you can setup a binding redirect for strongly-named assemblies by specifying codebase according to this article

Pavel Anikhouski
  • 21,776
  • 12
  • 51
  • 66