Referenced Microsoft.Net.Http not compatible with Windows Phone 8.1
Closed this issue · 6 comments
Hi,
We released our PCL NuGet package that is using your Mock library. We are seeing an issue where it cannot be installed in Windows Phone 8.1 projects because the Microsoft.Net.Http client referenced is version 2.1.10 which does not support Windows Phone 8.1.
Pretty sure it needs to be targeting the latest version 2.2.28
You can see the referenced version here
Any chance this could be updated?
Thanks,
Scott
I'm happy to upgrade it if necessary, but MockHttp is using the default NuGet version syntax which specifies a minimum version. There should be no reason you can't use MockHttp and target HttpClient 2.2.28, as long as an assembly redirect is in place.
Let me look into it further.
You are correct it should work. Here is what happens.
Our package uses Microsoft.Net.Http version 2.2.28. We are able to include your Mock package just fine.
I then try to install our package in a Windows Phone 8.1 project and I get the following error:
Install failed. Rolling back...
Install-Package : Could not install package 'Microsoft.Net.Http 2.1.10'. You are trying to install this package into a project that targets 'WindowsPhoneApp,Version=v8.1', 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.
If I install Microsoft.Net.Http 2.2.28 first, it all works. We unfortunately cannot have our users do that.
Could there be something we are doing incorrectly that is causing this?
Thanks for all your help
Hi Scott,
The issue appears to be that Windows Phone / Windows Store do not support assembly binding redirects, which means they cannot reconcile the difference of dependant versions at runtime. I'll look at updating the minimum version for the next release to avoid this in the future.
Having said that, I think your design is running into this problem unnecessarily. Your AlgoliaClient appears to take an optional MockHttpHandler, presumably to allow it to be mocked. However, the intention of MockHttp is that it is only used by your test project, with services accepting a HttpMessageHandler or HttpClient (MockHttpMessageHandler extends HttpMessageHandler and is intended as a runtime replacement). It is analogous to Moq, which you wouldn't reference from your application code.
I'd recommend the following:
- Change the MockHttpHandler ctor argument of AlgoliaClient to be HttpMessageHandler (or HttpClient)
- Remove the dependency on MockHttp from Algolia.Search (but leave it on Algolia.Search.Test)
Your tests should continue to work since they will be running in an environment which supports assembly binding redirects (and I can see that it is already redirecting correctly) and users will no longer have the problem since your NuGet package won't depend on MockHttp.
Hope that helps!
Richard
Thanks for the tip on how best to design our code. I inherited this so will do some digging to see why the choice was made to pass in MockHttpMessageHandler instead of just an HttpMessageHandler.
Really appreciate all your help.
Scott
Any time, Scott! I'll keep the issue open for now and close it when I release with an updated dependency.
The PCL profile was changed in Version 1.2.0 (back in December), but I forgot to close this issue (sorry!)