Your configuration looks correct to me. I configured a similar setup using theOpenAPI example with the following changes:

Added:

[ApiVersion(1.0)][Route("api/[controller]")]publicclassValuesController:ControllerBase{[HttpGet]publicIActionResultGet()=>Ok();}

Changed:

[ApiVersion(1.0)][ApiVersion(0.9,Deprecated=true)][ApiExplorerSettings(GroupName="Orders")][Route("api/[controller]")]publicclassOrdersController:ControllerBase{// omitted for brevity}

[ApiVersion(1.0)][ApiVersion(0.9,Deprecated=true)][ApiExplorerSettings(GroupName="People")][Route("api/v{version:apiVersion}/[controller]")]publicclassPeopleController:ControllerBase{// omitted for brevity}

.AddApiExplorer(    options=>{options.GroupNameFormat="'v'VVV";options.SubstituteApiVersionInUrl=true;options.FormatGroupName=(group,version)=>$"{group}-{version}";});

which produces the following:

• ORDERS-V1 only contains the1.0 version of theOrdersController
• PEOPLE-V1 only contains the1.0 version of thePeopleController
• V1 only contains the1.0 version of theValuesController

Everything else is unchanged. That is what I would expect.

I see that you're still using the olderStartup.cs approach, but I don'tthink it should matter in this case. You will have gone through the full DI cycle at this point andIApiVersionDescriptionProvider should produce the correct results. Are you sure there are any APIs inv1? In theory, it shouldn't be possible for that to happen. I may need a little more context or the world's simplest repro will help. Perhaps the repro steps I used will be helpful to you.

Sidebar

ApiVersioningOptions.AssumeDefaultVersionWhenUnspecified = true willnot what you think it will unless you have more configuration that I'm not seeing. This is a highly abused feature that is only meant for backward compatibility. When you chose to version by URL segment, it virtually has no effect. The only way it can work is if you useDouble Route Registration (ex:api/v{ver:apiVersion}/accountsandapi/accounts). In this case, there is no API version derived from the URL so it will beassumed since it has been configured as allowable. The only other exception would be if you have mixed styles and are moving away from versioning by URL segment (🤞🏽). I'd recommend explicit versions should that be the case. This is the same problem asorder/{id}/items. There is no way toassume or otherwise route to that path without{id}. The ASP.NET routing system doesn't support that.