Thank you for the quick response! I wasn’t sure if something like that would work for my project since the one in that post is .net core and mine is .net, but I will give it a shot!

Ok, so it took a little tinkering but I was able to make the solution in the post that you provided work for my test project, thank you so much!

For anyone who has this same issue in the future, what worked for me was:

• V1 Controller: add the Route[()] attribute:

namespace ApiVersioning.Examples.V1.Controllers;

using ApiVersioning.Examples.V1.Models;
using Asp.Versioning;
using System.Web.Http;

[Route( "api/v{version:apiVersion}/[controller]" )]
[Route( "api/[controller]" )]
[ApiVersion( "1.0" )]
public class AgreementsController : ApiController

{
.
.
.
}

• Startup.cs:
  configuration.AddApiVersioning(
  options =>
  {
  options.ReportApiVersions = true;
  options.Conventions.Add( new VersionByNamespaceConvention() );
  options.AssumeDefaultVersionWhenUnspecified = true;
  options.DefaultApiVersion = new ApiVersion( 1, 0 );
  } );

    configuration.Routes.MapHttpRoute(
        "Versioned2Url",
        "api/v{apiVersion}/{controller}/{action}",
        defaults: null,
        constraints: new { apiVersion = new ApiVersionRouteConstraint() } );
  
    configuration.Routes.MapHttpRoute( 
        "ActionApi", 
        "api/{controller}/{action}/{id}", new { id = RouteParameter.Optional });
  
    builder.UseWebApi( httpServer );
  

My V1 controller is still in the /V1/Controller folder - I'm going to do some testing to see if this also lets me use a controller that isn't in a "V#" folder so it can more easily be integrated into my existing project.

Thanks for the help @xavierjohn! I've been looking for a solution like this for what feels like weeks, turns out I just hadn't found the right post lol.

This information and the correct configuration is in the wiki topic Known Limitations: URL Path Segment Routing. This includes the correct configuration for ASP.NET Core and ASP.NET Web API.

A few clarifying points:

• be very careful changing the HttpControllerSelector service
  • this service is replaced by API Versioning
  • if it's not changed properly, things are very likely to break or not behave as expected
  • you should not need to customize or extend that service
• you don't need to specify DefaultApiVersion; the default is already 1.0. it's not wrong, it's just unnecessary
• if you're using VersionByNamespaceConvention, you shouldn't need [ApiVersion] on your controllers
  • the whole point is that the API version is derived by convention from the containing .NET namespace
  • if you have My.Api.V1.Controllers and [ApiVersion(1.0)], the same version is defined in 2 places
  • the API versions have to be distinct; the results are unioned and duplicates are ignored
  • if a controller has no API version applied by attribute or convention (including .NET namespace or folder), then the associated API version will be DefaultApiVersion with a default value of 1.0
• it is strongly recommended that you do not mix and match direct routing (aka attribute-based routing) with convention-based routing; there be 🐉🐉🐉
  • there are route combinations that will not work; specifically for the same logical API
  • this is a limitation of the ASP.NET Web API routing system
  • it's recommended that you choose one routing method and stick to it
  • direct routing is typically easier to understand, debug, and will be closer to ASP.NET Core if/when you ever migrate
  • it was not mentioned, but if you are using OData, that is the one case where it's recommend that you stick with convention-based routing and only use that approach
    • OData only supports convention-based routing on ASP.NET Web API