Referenced Microsoft.Net.Http not compatible with Windows Phone 8.1 about mockhttp HOT 6 CLOSED

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.

from mockhttp.

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

from mockhttp.

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:

1. Change the MockHttpHandler ctor argument of AlgoliaClient to be HttpMessageHandler (or HttpClient)
2. 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

from mockhttp.

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

from mockhttp.

Any time, Scott! I'll keep the issue open for now and close it when I release with an updated dependency.

from mockhttp.

The PCL profile was changed in Version 1.2.0 (back in December), but I forgot to close this issue (sorry!)

from mockhttp.