Consume new Microsoft.AspNet.WebApi.Client.5.2.4 package
dougbu opened this issue · 54 comments
Our Microsoft.AspNetCore.Mvc.WebApiCompatShim package currently has an indirect dependency on the Microsoft.Net.Http package. Building the shim project requires imports when targeting .NET Standard for the same reason. Both issues could be avoided if we moved to the latest Microsoft.AspNet.WebApi.Client package.
See also
- #5562, an older report of related problems
- aspnet/AspNetWebStack#45, tracking publishing the Microsoft.AspNet.WebApi.Client v5.2.4 package for realsies
- aspnet/AspNetWebStack#4, which covered adding .NET Standard 1.1. support to the Microsoft.AspNet.WebApi.Client package
- the current Microsoft.AspNetCore.Mvc.WebApiCompatShim package
- the current Microsoft.AspNet.WebApi.Client package
- the new Microsoft.AspNet.WebApi.Client package
This is approved, but let's figure out the plan to actually ship the 5.2.4 wave of packages.
Should I go ahead with this in the meantime i.e. with the nightly ASP.NET feed in MVC's NuGet.config?
We should talk about how to do the release and see if we can just do that.
Side note: Fix here should include removing the last couple of $(PackageTargetFallback) aka "imports" from the MVC repo.
Any plans for a public aspnet/AspNetWebStack?
Just asking as aspnet/AspNetKatana ist already public and some issues in aspnet link the private repo
The first priority is to publish 3.2.4 / 5.2.4 packages from aspnet/AspNetWebStack or at least the Microsoft.AspNet.WebApi.Client.5.2.4 package on NuGet. But, yes, work to make that repo public is in progress.
Oops forgot to log an issue. I'll start a thread first. I'll actually go do that now.
@dougbu How is Microsoft.AspNet.WebApi.Client 5.2.4 coming along?
I would really like to see it on NuGet.
@vanillajonathan the 5.2.4 package release is not yet available on NuGet. We've been consumed with 2.0.0-preview1 items and this is slated for 2.0.0-preview3.
It would be really nice with a small intermediate NuGet release of Microsoft.AspNet.WebApi.Client with just support for netstandard asap so we can write against APIs on .NET Core using PostAsJsonAsync.
@anurse please remind me what additional change needs to happen in aspnet/AspNetWebStack for the Microsoft.AspNet.WebApi.Client.5.2.4 package to work in the new .NET 4.6.1 world. Was it just the one item?
- add a .NET 4.6.1-specific
<FrameworkReference>mscorlib</FrameworkReference>
That should do it. The goal is to ensure that there is a Framework Assembly Reference to mscorlib in the .NETFramework, Version=4.6.1 target framework in the final NuSpec, in order to suppress the System.Net.Http one that appears in the 4.5.1 target.
Hi,
Just wondering if there's a rough TTL on this (early/late 2018?). My .NET Standard library needs to use HttpMessageContent for deserialisation of HttpResponseMessage.
@joakimskoog naah 2017 we'll get this out.
@Eilon: That's great! I would much rather utilise this solution than have to re-target my library for .NET Standard 2.0 to be able to use the compatibility shim.
@Eilon any updates? 1 months since last post.
@gregsdennis sorry no specific update at this time, but I assure you we did not forget, and this is still on our list.
@dougbu why is this blocked? Is it pending the resolution of some other functionality?
@gregsdennis it's blocked because we haven't published an official version of the "new Microsoft.AspNet.WebApi.Client.5.2.4 package" i.e. the package isn't on http://nuget.org yet.
I've tried to update my project to .net core 2.0 and i'm having some issues with the 5.2.3 (it builds but fails on execution due to dependencies of System.Net.Http.Primitives ...)
Hope the 5.2.4 will come out soon so i can migrate my project
Did a quick check of the current status because a lot has changed in MVC -- .NET Standard 2.0, lineups, …
- Took a bit of work to switch MVC build's approach to grab the latest Microsoft.AspNet.WebApi.Client package. But, lineups world would not make that too difficult if starting from scratch.
- Probably need the workaround first mentioned above. But, the build didn't get far enough to compile or run any of the full-framework tests and confirm.
- Hitting issues due to
FormDataCollectionbeinginternalwhen compiled for .NET Standard. Appears some of the workarounds in the Microsoft.AspNet.WebApi.Client for .NET Standard are getting in the way. Or, perhaps, need to remove more duplicate classes from the shim.
Question for @Eilon: When we push on this again, should Microsoft.AspNet.WebApi.Client target .NET Standard 2.0 instead of the current 1.1? That'll impact how many NETFX_CORE special cases we can remove e.g. what we do about 3. above.
@Vinhaman Did you figure out the issue with System.Net.Http.Primitives? I can't seem to run my unit tests which use 5.2.3 and .NET Core 2.0.
Also, the milestone says 2.1, so looks like 5.2.4 has been pushed back.
Should this still be in the Microsoft.AspNet.WebApi.Client namespace or should it be moved to the Microsoft.AspNetCore.WebApi.Client namespace?
@RehanSaeed
I had to remove the dependency completely as a workaround for it to work...
Upgrading to version 2.0 is not top priority for us and we are having other issues so for now we're still keeping the 1.1
A System.Net.Http.Primitives package does not seem to exist. StackOverflow pointed me at installing <PackageReference Include="Microsoft.Net.Http" Version="2.2.29" /> which seems to work for now.
Hello again. Any updates? ETA?
@gregsdennis we are having some infrastructure issues right now that we are working through.
@Eilon
I have just realized that im discussing missed FormUrlEncodedMediaTypeFormatter from Microsoft.AspNet.WebApi.Client.5.2.4 pre-release in closed issue aspnet/AspNetWebStack#4 .
Long story short: FormUrlEncodedMediaTypeFormatter class is missing from .netstandard pre-release package. Here is aspnet/AspNetWebStack#76 pull request to bring it back.
Hope this will be merged at the time of 5.2.4 release, otherwise this release will introduce unnecessary breaking changes for many consumers.
Any updates?
We expect to have preview ASP.NET Core 2.1 MVC packages early next year.
Hi there. Any updates folks?
https://github.com/aspnet/Home/wiki/Roadmap shows we'll release ASP.NET Core 2.1 in "Q1-Q2 2018".
In the meantime, ASP.NET (not ASP.NET Core) packages named *-5.2.4-alpha1-171202 or *-3.2.4-alpha1-171202 are available in the https://dotnet.myget.org/gallery/aspnetwebstack-dev feed. The symbol server https://dotnet.myget.org/F/aspnetwebstack-dev/symbols/ is also populated.
The https://dotnet.myget.org/feed/aspnetwebstack-dev/package/nuget/Microsoft.AspNet.WebApi.Client package includes the .NET Standard 2.0 assembly we plan to include in the next release and then will use in Microsoft.AspNetCore.Mvc.WebApiCompatShim. But, even nightly builds of Microsoft.AspNetCore.Mvc.WebApiCompatShim won't use the newer Microsoft.AspNet.WebApi.Client until we do a public "preview1" release of that package.
What is going on with HttpMessageContent so we were told .NET Standard 2.0 has everything... I am supposed to migrate CacheCow to support .NET Core and I need HttpMessageContent.
@aliostad please file questions about ASP.NET in the https://github.com/aspnet/AspNetWebStack repo.
In any case, HttpMessageContent is present in the .NET Standard 2.0 assembly in https://dotnet.myget.org/feed/aspnetwebstack-dev/package/nuget/Microsoft.AspNet.WebApi.Client We have no reason to remove it prior to an official 5.2.4 Preview1 release.
@dougbu sorry do I need to do anything to get it working?
I am trying to target both net452 and netstandard2.0 but it cannot find HttpMessageContent
You're referencing 5.2.3 - I assume from the NuGet Gallery - not 5.2.4 (prerelease).
@yaakov-h yes but that is for the benefit of net452 and not netstandard2.0.
If I remove netstandard2.0 from target, it stops complaining. Do you mean 5.2.4 has net standard bindings?
What is the ETA on 5.2.4? Having the same issue Vinhaman stated 8/21 --- I've tried to update my project to .net core 2.0 and i'm having some issues with the 5.2.3 (it builds but fails on execution due to dependencies of System.Net.Http.Primitives ...)
Hi @dscarmoz
My workaround for this and many other problems was to change the target framework in all my projects to framework 4.6.1 (everything .net core 2 still works just fine).
Took me a few days to change everything we had but now is running smooth
I don't think that will work for me. I'm running on a linux stack in PCF and the available buildpacks do not support it.
@dougbu should we log another bug to update to 5.2.4 RTM? Though it's not likely we'll forget to do that, it's good to have an item tracking stuff we know we have to do.
Well, if you weren't OOF, I would have asked you just that 😺 I'll file one…
The other thing I would have asked an in-person @Eilon: bab520f requires users to remove a previously-required <PackageTargetFallback> element or similar "must use PCL assembly" workaround from their projects. Should we document that as a full-blown breaking change? (I lean toward marking this bug with the label and adding a few words about the lines that should go but going no further.)
Or leave the bug as-is, but post a breaking-change announcement about it. THat'll be especially helpful for release notes, etc.
@anurse I have upgraded a .NET4.6 library to .NET 4.6.1 and it is complaining about missingSystem.Net.Http.HttpClientFactory.Create in some tests of mine. Is this something that can be fixed by adding a <FrameworkReference>mscorlib</FrameworkReference> to the Nuspec? Seems a bit odd as this will only affect consumers of my library, not making my tests green.
@asjafjell please open a new issue for the problem you're seeing. Also, what is necessary to reproduce the problem and what are the details of the "complaining"?
@dougbu it seems to be automatic binding redirects that was my problem. I did not know that this would be an issue between 4.6.0 and 4.6.1, so by adding
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
as indicated in dotnet/standard#481, the problem was fixed. The complaining, was that the method was missing runtime.
New announcement (aspnet/Announcements#286) and discussion (#7229) issues are now live. I couldn't find a major break but the recommendation stands.