Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support AspNet Core 3.0 #499

Closed
Hantse opened this issue May 10, 2019 · 39 comments
Assignees

Comments

@Hantse
Copy link

@Hantse Hantse commented May 10, 2019

Hello,

When trying to use with lastest of AspNet Core, error is throw at application startup

AspnetCore Version : Microsoft.AspNetCore.App 3.0.0-preview5-19227-01

Start new project and add package. In startup just add :

        services.AddApiVersioning();

Exception :

System.AggregateException HResult=0x80131500 Message=Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.) (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcAttributeRouteHandler Lifetime: Transient ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcAttributeRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.) (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Infrastructure.IActionSelector Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Versioning.ApiVersionActionSelector': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.) Source=Microsoft.Extensions.DependencyInjection Arborescence des appels de procédure : at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(IEnumerable1 serviceDescriptors, ServiceProviderOptions options)
at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(IServiceCollection services, ServiceProviderOptions options)
at Microsoft.Extensions.DependencyInjection.DefaultServiceProviderFactory.CreateServiceProvider(IServiceCollection containerBuilder)
at Microsoft.Extensions.Hosting.Internal.ServiceFactoryAdapter`1.CreateServiceProvider(Object containerBuilder)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at WebApplication4.Program.Main(String[] args) in C:\Users\aitbr\source\repos\WebApplication4\WebApplication4\Program.cs:line 16

Exception interne 1 :
InvalidOperationException : Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

Exception interne 2 :
TypeLoadException : Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.`

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented May 10, 2019

ASP.NET Core 3.0 is not supported - yet. The API Versioning package declares Microsoft.AspNetCore.Mvc.Core (>= 2.2.0 && < 3.0.0) so I'm not sure how you able to bypass the NuGet constraints. Regardless, I rarely provide support for prereleases. As a one-man army, I just don't have the capacity to support a moving target. Furthermore, there hasn't been any demand to support 3.0. It will be supported when it's officially released, but until then, all my focus is on existing issues.

I do periodically sync with the ASP.NET team. I'm not aware of any dramatic changes that will require a bunch of new work in 3.0. I'm not aware of a release date, but once it's released, API versioning should have a supported version released that same week.

I hope that helps clear things up. Thanks for your patience.

@Hantse

This comment has been minimized.

Copy link
Author

@Hantse Hantse commented May 10, 2019

I don’t do something to bypass nuget install :p

I can try to fix and share here.

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented May 10, 2019

Hmmm.... Ok. Perhaps the NuGet tooling is failing us here. It should have stated that API Versioning is not compatible with any flavor of ASP.NET Core 3.0.0-*.

@Hantse

This comment has been minimized.

Copy link
Author

@Hantse Hantse commented May 10, 2019

Just incompatible with last version, 3.0.0- < current work (update two days ago, before already in 3.0.0 preview and work)

@Hantse

This comment has been minimized.

Copy link
Author

@Hantse Hantse commented May 10, 2019

For example :
SDK 3.0.100-preview3-010431 -> Work
SDK 3.0.100-preview5-011568 -> Don't work

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented May 10, 2019

Not sure. Running on .NET Core 3.0 should theoretically work, though I haven't tried it. That's completely different from ASP.NET Core 3.0, which is not supported. If you had some version of it working, then I would suggest reverting back to that version.

@Hantse

This comment has been minimized.

Copy link
Author

@Hantse Hantse commented May 10, 2019

I have locate the problems,

In ApiVersionActionSelector,
readonly ActionConstraintCache actionConstraintCache;

But, not injected in last version of AspnetCore, and can't injest herself because in 3.0 it's internal class.

@unaizorrilla

This comment has been minimized.

Copy link

@unaizorrilla unaizorrilla commented May 17, 2019

Hi @commonsensesoftware

For me (and others) have a preview version for asp.net core 3 is a must, because some of us are trying to explore migrations paths on our Solutions and Projects.

Can I help to support preview asp.net core 3 versions ?

Thanks for your work here!
Unai

@NetTecture

This comment has been minimized.

Copy link

@NetTecture NetTecture commented May 19, 2019

Same here. Though I understand yuor issues - at least you are open with them. Any chance to get previews published once RC start?

I am in the problematic position that I need to get odata, versioning working and in efcore 2.2 it just is way too painfull - basically we pull all data into memory because it is the ONLY way to get proper results (thanks to invalid sql being generated way too often). As such, I actively want to move one odata says "beep" -and require versioning because, well, versioning. The broken efcore 2.2 just leaves no alternative.

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented May 20, 2019

It would seem a few people want this, so I'll see what I can do. RC tends to be a better choice; however, I don't expect many changes in the routing system. This project is big enough now that I usually get a heads up from the ASP.NET team if they think it might affect it. I'll see about carving out time this week to take a deeper look. My highest priority is knocking out confirmed, pending bugs, but I'm willing to see what this will take so I can estimate a release.

@NetTecture OData doesn't have a version compatible with ASP.NET Core 3.0 - yet. In fact, it's specifically excluded in the referenced dependency range, which isn't all that surprising. I also confirmed that their nightly feed is only building 7.1.1. They aren't part of the ASP.NET team and I haven't had a whole lot of interaction with them myself. There is a laundry list of things people are asking from them, in particular, supporting Endpoint Routing and I'm sure ASP.NET Core 3.0 support. I can't speak for them, but unless you know something about their schedule that I don't, I wouldn't expect they'll have anything out before ASP.NET Core 3.0 is officially released.

I should also point out that ASP.NET Core 3.0 != .NET Core 3.0. I think most here understand that, but I've had a few people get confused about it. ASP.NET Core is a web technology stack, while .NET Core is a runtime. The Microsoft.AspNetCore.App meta package might also be confusing. This package wraps everything up to run on a particular flavor of .NET Core; however, ASP.NET Core can run on .NET Core or full .NET. It looks like the current preview only supports .NET Core, but I'll be surprised if that doesn't change. Finally, it's worth noting that I don't have a daily/nightly feed to publish prereleases to. This means that consumers of the proposed prerelease package for API Versioning have to know and configure multiple NuGet feeds in order for things to work because the ASP.NET Core packages are not on the public NuGet feed - yet. That's a considerable landmine for the unsavvy developer wanting to try it out. I can certainly add that to the release notes, but history has shown that people often do not read them.

@gpuchtel

This comment has been minimized.

Copy link

@gpuchtel gpuchtel commented May 28, 2019

I apologize in advance if this is the wrong forum; however, I'd like to get Api versioning working in the .Net Core preview5 as well. If this is the wrong forum, could someone kindly point me to the right place. After extensive searching, this post is the only one that expresses the issue I'm having.

Thanks in advance,
glenn

@gingters

This comment has been minimized.

Copy link

@gingters gingters commented Jun 3, 2019

I'm also running into this issue with ASP.NET Core 3.0 preview 5.
Also, I could simply install the NuGet package (in VS 2019 Preview) and it didn't moan about the constraints.

In ASP.NET Core a bit has shifted with the routing / endpoints, and I also had issues with the ApiExplorer and Swashbuckle Swagger, so I assume the ApiExplorer that supports Versioning will also run into some issues.
Sadly I don't have more time in the next few days to investigate further, but it would be awesome to have a rough idea of what would needed to be done here so that API Versioning would work with ASP.NET Core 3.

@alexdresko

This comment has been minimized.

Copy link

@alexdresko alexdresko commented Jun 3, 2019

@gingters for the record, I was able to get Swashbuckle running using the v5.0.0-rc2 package. I figure if .NET Core 3 is still in beta, that I'm willing to accept a beta version of all the nuget packages I need.

@gpuchtel

This comment has been minimized.

Copy link

@gpuchtel gpuchtel commented Jun 19, 2019

Hmm, I've updated to (3.0.0-preview6.19307.2) & included 'Microsoft.AspNetCore.Mvc.Versioning(3.1.2); also, I've added 'ApiVersioning to my 'Services' as follows:

        services.AddApiVersioning(o =>
        {
            o.ReportApiVersions = true;
            o.ApiVersionReader = new HeaderApiVersionReader("x-openrtb-version");
        });):

however, I still get an exception when calling CreateHostBuilder():

System.AggregateException
HResult=0x80131500
Message=Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.) (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcAttributeRouteHandler Lifetime: Transient ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcAttributeRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.) (Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Infrastructure.IActionSelector Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Versioning.ApiVersionActionSelector': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.)
Source=Microsoft.Extensions.DependencyInjection
StackTrace:
at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(IEnumerable1 serviceDescriptors, ServiceProviderOptions options) at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(IServiceCollection services, ServiceProviderOptions options) at Microsoft.Extensions.DependencyInjection.DefaultServiceProviderFactory.CreateServiceProvider(IServiceCollection containerBuilder) at Microsoft.Extensions.Hosting.Internal.ServiceFactoryAdapter1.CreateServiceProvider(Object containerBuilder)
at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
at Microsoft.Extensions.Hosting.HostBuilder.Build()
at WebApiService.Program.Main(String[] args) in D:\winterfell\WebApiService\Program.cs:line 10

Inner Exception 1:
InvalidOperationException: Error while validating the service descriptor 'ServiceType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler Lifetime: Singleton ImplementationType: Microsoft.AspNetCore.Mvc.Routing.MvcRouteHandler': Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

Inner Exception 2:
TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.Internal.ActionConstraintCache' from assembly 'Microsoft.AspNetCore.Mvc.Core, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

@dustinlacewell

This comment has been minimized.

Copy link

@dustinlacewell dustinlacewell commented Jul 8, 2019

Hey just chiming in here to say that I'd love to use this package with preview6.

@commonsensesoftware commonsensesoftware changed the title [BUG] - AspNet Core 3.0 Support AspNet Core 3.0 Jul 8, 2019
@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Jul 8, 2019

As there are a number of people actively following this particular issue, I thought it was prudent to provide an update. First, I've updated the title so that it's hopefully easier for others to follow. This issue isn't really a bug, but rather a feature request to support ASP.NET Core 3.0.

I've done some preliminary investigation and work to get things running on ASP.NET Core 3.0. I guess I had not read that support for the full .NET Framework was being dropped. Since I know that be an issue for some folks and splitting support across package versions is quite painful for me, API Versioning 4.0 will return to multi-targeting in order to continue supporting ASP.NET Core 2.2.x. The TFMs will be:

  • netstandard2.0 = ASP.NET Core (2.2.0 < 3.0.0)
  • netcoreapp3.0 = ASP.NET Core (3.0.0 - 4.0.0)

This will enable existing API Versioning users to continue to get patches and other changes, while others move forward. I don't have an exact time as to when, but support for netstandard2.0 will eventually be dropped. This will likely coincide with ASP.NET Core 4.0.

In terms of getting a build out that can support a preview version of ASP.NET Core 3.0, I'm now in a holding pattern. A couple of key types that were used by API Versioning in all previously versions ASP.NET Core have currently been made internal. The ASP.NET Core team elected to do this in their quest to completely phase out the legacy routing system defined by the IRouter interface. Endpoint Routing will be the de facto routing implementation in 3.0 and beyond. API Versioning continues to support the legacy routing system and without it some capabilities would be lost (ex: OData support). While temporarily removing this support in a preview is technically feasible, it adds a lot of churn since it will come back in the actual release.

I've already been in contact with the ASP.NET Core team and there are not any strong objections to making the bare minimum types API Versioning needs public again. Trying to work against internal types is difficult and requires a lot of complex hacks. I don't know exactly when the types will be made public again, but expect it to be relatively soon. It may not come until preview7, which seems to be in the works. Once that happens, it shouldn't take all that long to get a preview build out for API Versioning.

I appreciate everyone's patience on this issue. An official preview package is finally on the horizon. Thanks.

@Hantse

This comment has been minimized.

Copy link
Author

@Hantse Hantse commented Jul 8, 2019

Thank you very much for the update and the good news :D

@keyhooon

This comment has been minimized.

Copy link

@keyhooon keyhooon commented Jul 10, 2019

Thank you very much, its very good news.

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Jul 22, 2019

The devil is always in the details. There was plenty of setup and other changes required to get things going, but it looks like things finally lined up with the full test suite passing.

You can now get a supported build in the 4.0.0 Preview 8 (19369.1) release. As noted in the release notes, I do not have this put up on NuGet yet because code and package signing are required, but the build I need for ASP.NET Core 3.0 is not available in a channel supported by the .NET Core SDK Installer task in Azure DevOps - yet. There's probably a way I can make it work with some PowerShell scripting, but it would probably take a few more days of trial and error before getting it to work with a new build definition. Since that's going to be throw away work and the next official preview build will remedy this problem, it's not worth my investment.

In the meantime, you can pull the 4.0 branch directly or I've pre-built the packages and attached them to the release for you to add to your private feed of choice.

@MonkSoul

This comment has been minimized.

Copy link

@MonkSoul MonkSoul commented Jul 24, 2019

The devil is always in the details. There was plenty of setup and other changes required to get things going, but it looks like things finally lined up with the full test suite passing.

You can now get a supported build in the 4.0.0 Preview 8 (19369.1) release. As noted in the release notes, I do not have this put up on NuGet yet because code and package signing are required, but the build I need for ASP.NET Core 3.0 is not available in a channel supported by the .NET Core SDK Installer task in Azure DevOps - yet. There's probably a way I can make it work with some PowerShell scripting, but it would probably take a few more days of trial and error before getting it to work with a new build definition. Since that's going to be throw away work and the next official preview build will remedy this problem, it's not worth my investment.

In the meantime, you can pull the 4.0 branch directly or I've pre-built the packages and attached them to the release for you to add to your private feed of choice.

Thanks!The .net core preview7 version is working.

@karincayazilim

This comment has been minimized.

Copy link

@karincayazilim karincayazilim commented Jul 27, 2019

any solution .NET Core 3.0 Preview 7

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Jul 28, 2019

@karincayazilim, I believe you are asking whether the package will work with Preview 7. @MonkSoul seems to have gotten it work. I've only tried with Preview 8 locally from the daily build. I still haven't been able to get a server build working against the Preview 7 SDK build. It's hard to tell amongst all the pieces, but it seems that the required changes came just after the commit used for Preview 7 (but maybe I'm mistaken). The cadence appears to be a preview version per month. I expect Preview 8 next month to enable me to build and publish the necessary packages to NuGet next month. Until then, you'll need to use the unofficial packages provided in the API versioning pre-release.

@grahamehorner

This comment has been minimized.

Copy link

@grahamehorner grahamehorner commented Aug 9, 2019

I'm having issues with preview-7 not sure if anyone has seen this or has a work-around; I see the following exception when calling

**

services.AddApiVersioning(options => options.ReportApiVersions = true);

**

System.TypeLoadException
HResult=0x80131522
Message=Method 'ApplyAsync' in type 'Microsoft.AspNetCore.Mvc.Routing.ApiVersionMatcherPolicy' from assembly 'Microsoft.AspNetCore.Mvc.Versioning, Version=3.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' does not have an implementation.

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Aug 9, 2019

@grahamehorner, it doesn't look like you are using the ASP.NET Core 3.0 package versions, which would have an API Versioning assembly version of 4.0.0.0. These packages are special and currently only available in the Releases for you to use in a private NuGet feed.

I'm not 100% sure, but I'm not completely sure even that build will work against Preview 7 because the changes I had to ask for didn't make the Preview 7 cut. I ended up using the daily build. All of the changes should be aligned in Preview 8, which should then allow me to build and publish the packages to the official NuGet feed as normal.

I hope that helps.

@cyberhck

This comment has been minimized.

Copy link

@cyberhck cyberhck commented Aug 11, 2019

Hello, first thanks a lot for this package, you said you're working on this project alone, I understand the values of your contributions.

However I wanted to ask a little more from what you've already done if it's okay with you.

You released a preview on github's release, do you mind creating a pre-release on nuget? There are ways to mark a release as pre-release so we can give them a try, I've been using .NET core 3 preview since preview-3 and I've been blessed with pre-release of a lot packages till now.

If you were to release as a pre-release then I think I'll be able to use without any problems, else I'd have to get the release manually, then remember to update it later :(

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Aug 11, 2019

@cyberhck, I don't have a problem with publishing official pre-preleases and I've done so in the past. The reason that the current pre-release is not available on NuGet is a combination of policy and infrastructure blockers.

Since this is an official Microsoft open source project, the libraries and NuGet packages themselves must be code signed. If they're not, they are rejected when published. In order to code sign them, I have to run my builds on agents that support internal Microsoft code signing. In order for me to build on those agents, I have to be able to pull down an appropriate version of the .NET Core SDK to build against. The .NET Core SDK task does not support using the daily builds; it uses a curated list of supported pre-releases. If someone knows how to get the daily build to work without requiring admin privileges on the agent, there is probably a way to make it work.

Other packages get around this because they either do not need to do signing or they publish out of a non-official feed such as MyGet. MyGet isn't free and I have no budget to set up a feed. I love the community, but I'm not about to start spending my own money on a private feed. I think (and hope) most can appreciate that.

The next best thing for me to do was to build the packages, attach them to a release, and let you put them in your own private feed whether it be in Azure DevOps or just a local file folder. Preview 8 is likely only about two weeks away. Once it's out, this problem should go away since the curated pre-release .NET Core SDK packages will finally have what I need to build everything.

I know it's inconvenient for the time being, but I don't really have better options at the moment. I'm open to ideas to make it better, but the issue will self-correct in the not-so-distant future. Thanks for you patience.

@cyberhck

This comment has been minimized.

Copy link

@cyberhck cyberhck commented Aug 11, 2019

Thanks, I wasn't aware of the complications, and of course I don't expect you to setup your own private feed, that'd be very unreasonable for me. I didn't know of code signing policy, sorry about that, I know you've done whatever you could.

I'm quite new to .NET ecosystem, so please don't mind me if I came across as kinda want it all person.

@thomasvehus

This comment has been minimized.

Copy link

@thomasvehus thomasvehus commented Aug 13, 2019

Now that preview 8 is out, has anyone checked if this issue is resolved?

@rajasekarshanmugam

This comment has been minimized.

Copy link

@rajasekarshanmugam rajasekarshanmugam commented Aug 14, 2019

Till the official Microsoft.AspNetCore.Mvc.Versioning beta package is on nuget, dont think this will work. However a work around exists (https://www.koskila.net/how-to-resolve-build-failing-with-net-core-3-and-microsoft-aspnetcore-mvc-versioning/) has details that worked.

TLDR:
Download the packages manually from the location mentioned above -(https://github.com/microsoft/aspnet-api-versioning/releases/tag/4.0.0.preview8.19369.1).

To configure the local nupkg - https://stackoverflow.com/questions/10240029/how-do-i-install-a-nuget-package-nupkg-file-locally

Update the package reference to the beta versions in the projects as above.

NOTE: not clear if this qualifies for production support etc.

@kdcllc

This comment has been minimized.

Copy link

@kdcllc kdcllc commented Aug 14, 2019

@commonsensesoftware what is eta for the official package in the nuget or myget feed?

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Aug 15, 2019

@kdcllc, there will likely never be a MyGet feed. I don't have funding or a budget for such an endeavor. It's pretty rare I even need it, but this is one such case.

@rajasekarshanmugam, if that qualifies for production support, I'll take it. This project definitely has ebbs and flows. I can certainly use the assist during ebbs. 😉

I know folks are champing at the bit for this - evident by pinging the thread 2 hours after Preview 8 was released. 😳 I appreciate the enthusiasm, but it often takes me more than a few hours or even a few days to snap to a new release.

I was finally able to get the build to work on the build agents, but the re-introduction of multi-targeting broke my code signing process. It took me a few hours to iron all the build issues out, but I was - at long last - able to get a packaged and signed version out.

4.0.0-preview8.19405.7 is Now Available on NuGet

😌 :bowtie:

Enjoy!

PS: This package also includes the latest patches to 3.x

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Aug 15, 2019

I'll leave this open for another day or two (or maybe a few hours 😛) to let someone confirm all is well in the universe using Preview 8.

@natelaff

This comment has been minimized.

Copy link

@natelaff natelaff commented Aug 15, 2019

Woooo! Working for me! Thanks for your work on this :)

@damiencap

This comment has been minimized.

Copy link

@damiencap damiencap commented Aug 15, 2019

Works for me also, thanks a lot!

@cyberhck

This comment has been minimized.

Copy link

@cyberhck cyberhck commented Aug 15, 2019

@commonsensesoftware I can't thank you enough, even though it was completely unreasonable of me to ask you to do so, you did it, thanks a lot. :)

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Aug 15, 2019

Thanks for all the verification and patience. Ultimately, I did catch some unexpected changes that I had to have the ASP.NET team refactor, so it was good that you all helped catch that early. It would have been much more difficult later on. The changes needed were more back-compat with the legacy routing system. I don't expect any additional changes; especially, since this project helped influence and verify the design of the new Endpoint Routing mechanics.

I'll keep an eye out for subsequent preview releases. Expect that it may be days before I notice and publish updated packages. If I miss it or you really need it, you can ping this thread as a reminder. The only other changes I have planned for 4.0 is related to OData, which appears to be behind in their .NET Core 3.0 execution plan. Unless something unexpected comes up, the current build is what 4.0 will look like.

Thanks again.

I consider this issue now resolved.

@sanzor

This comment has been minimized.

Copy link

@sanzor sanzor commented Nov 5, 2019

Hello i am still having problems trying to use swagger with asp net core 3.0.
I have only installed Swashbuckle.AspNetCore 4.0.1 and Swashbuckle.AspNetCore.SwaggerUI 4.0.1

System.AggregateException
  HResult=0x80131500
  Message=Some services are not able to be constructed (Error while validating the service descriptor 'ServiceType: Swashbuckle.AspNetCore.Swagger.ISwaggerProvider Lifetime: Transient ImplementationType: Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator': Failed to compare two elements in the array.) (Error while validating the service descriptor 'ServiceType: Swashbuckle.AspNetCore.SwaggerGen.ISchemaRegistryFactory Lifetime: Transient ImplementationType: Swashbuckle.AspNetCore.SwaggerGen.SchemaRegistryFactory': Failed to compare two elements in the array.)
  Source=Microsoft.Extensions.DependencyInjection
  StackTrace:
   at Microsoft.Extensions.DependencyInjection.ServiceProvider..ctor(IEnumerable`1 serviceDescriptors, ServiceProviderOptions options)
   at Microsoft.Extensions.DependencyInjection.ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(IServiceCollection services, ServiceProviderOptions options)
   at Microsoft.Extensions.DependencyInjection.DefaultServiceProviderFactory.CreateServiceProvider(IServiceCollection containerBuilder)
   at Microsoft.Extensions.Hosting.Internal.ServiceFactoryAdapter`1.CreateServiceProvider(Object containerBuilder)
   at Microsoft.Extensions.Hosting.HostBuilder.CreateServiceProvider()
   at Microsoft.Extensions.Hosting.HostBuilder.Build()
   at SXS.Server.Program.Main(String[] args) in C:\Work\SXS\SXS\Core\Server\SXS.Server\Program.cs:line 32

Inner Exception 1:
InvalidOperationException: Error while validating the service descriptor 'ServiceType: Swashbuckle.AspNetCore.Swagger.ISwaggerProvider Lifetime: Transient ImplementationType: Swashbuckle.AspNetCore.SwaggerGen.SwaggerGenerator': Failed to compare two elements in the array.

Inner Exception 2:
InvalidOperationException: Failed to compare two elements in the array.

Inner Exception 3:
TypeLoadException: Could not load type 'Microsoft.AspNetCore.Mvc.MvcJsonOptions' from assembly 'Microsoft.AspNetCore.Mvc.Formatters.Json, Version=3.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.

@natelaff

This comment has been minimized.

Copy link

@natelaff natelaff commented Nov 5, 2019

I think you need to update to Swagger 5.0 RC for .NET Core 3.0 support.

@commonsensesoftware

This comment has been minimized.

Copy link
Member

@commonsensesoftware commonsensesoftware commented Nov 5, 2019

Thanks @natelaff . Yes, I believe you are correct. The sample applications have been updated to use Swashbuckle 5.0.0-* as well. I recommend reviewing the latest source for a complete end-to-end working example

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.