We Keep Coding

Call a versioned webapi controller path ending with a number

Why does adding versioning to a webApi project removes number from the controller path name?
Replication steps :
Create a fresh .net6 project. And rename WeatherForecastController to WeatherForecast2Controller.
Run app and call https://localhost:x/WeatherForecast2 (where x is your port)
Observe valid/expected results
Add the below code in program.cs/startup
services.AddApiVersioning(config =>
{
config.AssumeDefaultVersionWhenUnspecified = true;
config.DefaultApiVersion = new ApiVersion(1, 0);
config.ReportApiVersions = true;
config.ApiVersionReader = ApiVersionReader.Combine(
new QueryStringApiVersionReader("version"),
new HeaderApiVersionReader("x-version"));
config.UseApiBehavior = false;
});
Run app and call https://localhost:x/WeatherForecast2 (where x is your port).
Step 5 will return a 404 not found error.
However if you call https://localhost:x/WeatherForecast. It will work.
So why does adding versioning, change the url path?

It's not entirely clear if you are using <= 5.0 or 6.0+.
History
The reason this behavior happens is because the only logical way to group controllers together is by their names. A controller name, therefore, becomes very important. This is problematic in code because two or more controllers in the same namespace cannot have the same type name. The assumption and long-defined convention has been to allow ASP.NET to remove the Controller suffix and then remove any remaining numbers. This allows ValuesController, Values2Controller and Values3Controller to all map to the logical controller name Values by default. In most cases, that's probably want someone wants. If API Versioning doesn't do this, then there is no way to collate all API versions together for an API.
Contrary to popular belief, route templates are not considered for grouping controllers (e.g. APIs). There is too much ambiguity as to how a template can map to code. Take the simplest example of two different versions of the same API with different route templates: V1 = values/{id}, V2 = values/{id:int}. These are semantically equivalent, but not the same. API Versioning does not try to understand what the route template means nor compare their equivalence. It can easily get a lot more complicated; especially, for overlapping route templates. For example, should order/{oid}/customer/{cid} be part of the Orders API or the Customer API? Only the service author knows for sure.
Regression
In the 5.0 release, a regression was accidentally introduced due to an over-optimization. The controller name is used in two places: the actual name of the controller and the name used to group controllers. It seems reasonable they'd be the same and why normalize (e.g. trim suffixes) more than necessary? It seemed like a good idea, but it caused unexpected behavior - such as this one. There are also legitimate reasons to have a number in the name of a controller; for example, S3Controller.
Fix
In library versions <= 5.0, developers had no control over the behavior of how names were normalized. In 5.1 and 6.0+, this is now exposed via the IControllerNameConvention service, which has two methods: one for normalizing the controller name and one for normalizing the group name. The following implementations are provided out of the box as properties on ControllerNameConvention:
Default: The default, out-of-the-box conventions
Original: The original names without any normalization (could result in the wrong behavior)
Grouped: The group name is normalized, but the controller name is unmodified
If none of those work for you, then you can create your own custom convention. In 5.1 this is wired up via ApiVersioningOptions.ControllerNameConvention, while in 6.0+ IControllerNameConvention is a transient service in the DI container.
Workaround
There are two ways you can workaround the problem using the current version you are leveraging:
Explicit Route Template
If you omit using the [controller] token, the routing problem will be resolved; for example, api/weatherforecast. You appear to have already discovered this.
Explicit Controller Name
The controller name is derived from a convention, even without API Versioning. It was understood this behavior could be a problem so API Versioning provides a way to explicit set it with the ControllerNameAttribute.
[ControllerName("WeatherForecast")]
[Route("api/[controller]")] // ← expands to 'api/WeatherForecast'
public class WeatherForecast2Controller : ControllerBase { }
Edge Case
This will solve the routing issues, but it will not fix the controller name issue. That should only matter if you are planning on documenting your API with OpenAPI (formerly Swagger). For example, S3Controller will simply show up as S, even though the route might be api/s3.

I think that your controller may have issues, as I used your AddApiVersioning code and it works for me. To avoid the conflicting action names, you can two different controllers.
ApiController
namespace WebApiVersioningApp.Controllers;
[ApiVersion("1.0")]
[ApiVersion("2.0")]
[ApiController]
[Route("api/Version2")]
public class Version2Controller : ControllerBase
{
[MapToApiVersion("1.0")]
[HttpGet(Name = "GetWeatherForecastV1")]
public string GetV1()
{
return "Version 1";
}
[MapToApiVersion("2.0")]
[HttpGet(Name = "GetWeatherForecastV2")]
public string GetV2()
{
return "Version 2";
}
}
Program:
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddControllers();
// Learn more about configuring Swagger/OpenAPI at https://aka.ms/aspnetcore/swashbuckle
builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen(c =>
c.ResolveConflictingActions(apiDescriptions => apiDescriptions.First())
);
// Versioning setup
builder.Services.AddApiVersioning(o =>
{
o.ReportApiVersions = true;
o.AssumeDefaultVersionWhenUnspecified = true;
o.DefaultApiVersion = new ApiVersion(1, 0);
o.ApiVersionReader = ApiVersionReader.Combine(
new QueryStringApiVersionReader("version"),
new HeaderApiVersionReader("x-version"));
o.UseApiBehavior = false;
});
var app = builder.Build();
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseSwagger();
app.UseSwaggerUI();
}
app.UseHttpsRedirection();
app.UseAuthorization();
app.MapControllers();
app.Run();
Hope this works for you.

Where does custom IRouteConstraint get discovered by ASP.NET Core

I'm digging the source code to see how asp.net core discovery custom IRouteConstraint.
We know that when we define a custom IRouteConstraint, we add it to RouteOptions as
public void ConfigureServices(IServiceCollection services)
{
services.Configure<RouteOptions>(opts => {
opts.ConstraintMap.Add("countryName", typeof(CountryRouteConstraint));
});
}
public class CountryRouteConstraint: IRouteConstraint
{
public bool Match(...) { ... }
}
where IOptions<RouteOptions> is registered.
So I check the source code of
EndpointRoutingMiddleware (https://source.dot.net/#Microsoft.AspNetCore.Routing/EndpointRoutingMiddleware.cs,e91e5febd7b6da29)
DfaMatcher
(https://source.dot.net/#Microsoft.AspNetCore.Routing/Matching/DfaMatcher.cs,0b08e610bec2cfbc)
and so on, I didn't find any part of the source code that tries to read from RouteOptions to discovery custom IRouteConstraint.
This is the place I think most likely https://source.dot.net/#Microsoft.AspNetCore.Routing/Matching/DfaMatcher.cs,197
but still doesn't find anything.
Can anybody show me the section of the source code that ASP.NET Core read from RouteOptions to discovery custom IRouteConstraint?

Navigate to that ConstraintMap property of RouteOptions, to which you are adding your CountryRouteConstraint constraint.
Look for its references.
The ones of most interest for you are
DefaultInlineConstraintResolver
DefaultParameterPolicyFactory
Both make use of the ParameterPolicyActivator for the instantation of the constraints, passing in that ConstraintMap.
E.g. DefaultParameterPolicyFactory shows below
var parameterPolicy = ParameterPolicyActivator.ResolveParameterPolicy<IParameterPolicy>(
_options.ConstraintMap,
_serviceProvider,
inlineText,
out var parameterPolicyKey);

Register a service during ASP.NET Core MVC AddControllers configuration

I am making an injectable service (i.e. added using IServiceCollection.AddSingleton...) which works with a custom global action filter. In other words, I need to add the filter:
services.AddControllers(mvcOptions =>
{
mvcOptions.Filters.Add<MyActionFilter>();
});
But I also need to register my component:
services.AddSingleton<IMyService, MyService>();
This all works great. However, now I need to package this registration up for re-use in multiple projects. To do this I would like to produce a little helper which can perform all my registration, such as:
services.AddControllers(mvcOptions =>
{
mvcOptions.AddMyService(services);
});
// or
services.AddMyService();
Basically, the consumer of this registration need not be concerned about the relationship of the action filter and my service -- only that my service can be resolved via dependency injection.
The problem is, the callback in AddControllers gets called after the graph has been built, so adding my service in that context is not helpful. But also I am unable to add my action filter outside of the AddControllers callback scope (as far as I can tell).
Instead of having to author two registration methods my consumers will be required to call, is there a way to accomplish what I am trying to do?
Thanks!

Option 1:
AddControllers supports being called multiple times, so your IServiceCollection extension could be as simple as this:
services.AddSingleton<IMyService, MyService>();
services.AddControllers(mvcOptions =>
{
mvcOptions.Filters.Add<MyActionFilter>();
});
Option 2:
If you just want to register the filter and service with the assumption that the consumer calls AddControllers, your IServiceCollection extension method could look like this:
services.AddSingleton<IMyService, MyService>();
services.Configure<MvcOptions>(mvcOptions =>
{
mvcOptions.Filters.Add<MyActionFilter>();
});
Option 3:
You could create an extension for IMvcBuilder that would allow the consumer to write something like this:
services.AddControllers()
.AddMyService();
To support this, use the following extension method:
public static class MvcBuilderExtensions
{
public static IMvcBuilder AddMyService(this IMvcBuilder mvcBuilder)
{
mvcBuilder.Services.AddSingleton<IMyService, MyService>();
mvcBuilder.AddMvcOptions(mvcOptions =>
{
mvcOptions.Filters.Add<MyActionFilter>();
});
return mvcBuilder;
}
}

Routes in AspNetCore.TestHost depend on Startup.cs location?

I am trying to test my ASP.NET Core Web Application with Microsoft.AspNetCore.TestHost. It works fine this way (result has status 200):
var server = new TestServer(new WebHostBuilder().UseStartup<Startup>());
var client = server.CreateClient();
var result = await client.GetAsync(someRequestUrl);
In this case the real Startup class from the API project is used.
However, I don't want to use the real Startup class in my integration test. The main reason is the need to mock some stuff that gets wired during application startup. For example, the database server to be used. It can be done in a very elegant way by defining a virtual method in Startup.cs:
public virtual void SetupDbContext(IServiceCollection services)
{
services.AddDbContext<TbsDb>(options =>
options.UseSqlServer("someConnectionString"));
}
Then I create a new class, which inherits from the original Startup class and overrides this method to use Sqlite, in-memory database or whatever:
public override void SetupDbContext(IServiceCollection services)
{
services.AddDbContext<TbsDb>(
options => options.UseSqlite("someConnectionString"));
}
This also works well with TestHost if the new class is in the same API project.
Obviously, I don't want this class which is used for testing to be there. But if I move it to integration tests project and create a TestServer there, the same test fails because the result has status 404. Why is it happening? It still inherits from the Startup class, which is in the API project. Thus I expect all the routes to work the same no matter where the TestStartup class is. Can it be solved somehow?

ASP.NET MVC 4 WebApi Conditional MessageHandlers

In previous version of the WebApi you could do the following:
RouteTable.Routes.MapServiceRoute<UserService>("1.0/User/", defaultWebApiConfiguration);
RouteTable.Routes.MapServiceRoute<SomeOtherService>("1.0/SomeOtherService/", largeFilesConfig);
This would allow you to have different message handlers on different services. This is apparently not possible in the new framework: ASP.NET MVC 4 WebApi Support For Multiple HttpConfigurations
Alternatively I had projects where I edited the RequestHandlers in the WebApiConfiguration to add handlers if certain attributes existed like this:
public static void AppendAuthorizationRequestHandlers(
this WebApiConfiguration config)
{
var requestHandlers = config.RequestHandlers;
config.RequestHandlers = (c, e, od) =>
{
if (requestHandlers != null)
{
requestHandlers(c, e, od); // Original request handler
}
var authorizeAttribute = od.Attributes.OfType<RequireAuthorizationAttribute>()
.FirstOrDefault();
if (authorizeAttribute != null)
{
c.Add(new AuthOperationHandler(authorizeAttribute));
}
};
}
That code is based on: http://haacked.com/archive/2011/10/19/implementing-an-authorization-attribute-for-wcf-web-api.aspx. This is no longer possible as MessageHandlers on the HttpConfiguration is not settable.
To summarize, my question is how can I specify certain message-handlers to only apply to certain ApiController services instead of all of them. It seems that ASP.NET MVC 4 WebApi framework has over simplified the power and configurability of the Web Api Beta.

The recomended way to achieve this in the new Web API is with action filter attributes. They work pretty much the same way as in MVC, though you use a new set of base classes to implement them. The easiest way to get started is to derive from ActionFilterAttribute.