I am writing integration testing and came across a requirement to disable to calling adding swagger function in startup. I am using the same startup class without customizing it.
Please suggest some solution to get rid of swagger and it's inner function implementation like adding authentication.
Thanks.
1) You can use a custom startup class for your Integration Testing project. There you can leave out the code to use swagger.
(or)
2) You can add a key in appsettings.json to identify a test run.
In Startup.cs - ConfigureServices() and Configure() methods, you can check the key, and if it is test run, you can avoid calling Swagger code.
Related
I am using the Ardalis Clean Architecture for one of my projects. I am getting the above-mentioned error if I have the same action method (for example: Edit) in more than one controller and I try to call that method from anywhere. But if I add the following line in the controller just above where you declare public class and the controller name then the error disappear.
[Route("[controller]/[action]")]
I don't face the same issue in a normal asp.net core 6.0 project so I guess there is something in the Ardalis Clean Architecture template that is causing this.
Context:
Upgrading an existing aspnet application from core 3.1 to dotnet 6.0.
Issue:
We have registered a IActionInvokerProvider in our web app. This simply adds some information to the context route data.
We also use UseStatusCodePagesWithReExecute
app.UseStatusCodePagesWithReExecute("/somecontroller", "?statusCode={0}");
According to the documentation https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.mvc.abstractions.iactioninvoker?view=aspnetcore-3.1
An IActionInvoker is created for each request the MVC handles by querying the set of IActionInvokerProvider instances. See IActionInvokerProvider for more information.
When running this in netcoreapp3.1 when we return a NotFound() I can observe that 2 calls are made to our action provider OnProvidersExecuting. One for the request to the resource and one for a call expected UseStatusCodePagesWithReExecute to /somecontroller.
When targeting net6.0 and changing no other code this second call to /somecontroller does not get called only the first . If I call the endpoint /somecontroller?statusCode=404 I it does trigger the invoker. I cannot find a reference to a breaking change anywhere. perhaps I missed it.
Does anyone know what the casue might be?
I have tried altering the ordering of the pipeline.
Tried to repro it in https://github.com/csi-lund/core31tonet6issue
In the version the Action provider never gets called at all
The answer was a missed breaking change and documentation.
https://github.com/dotnet/aspnetcore/issues/45589
We skip the IActionInvoker by default as an optimization for
controllers and pages. This is a really heavyweight way to add route
data to the pipeline. You can set EnableActionInvokers to true to
enable this behavior.
builder.Services.AddControllers(o => {
o.EnableActionInvokers = true; }); In your sample it would be AddMvc (since you're using that).
No change in behaviour without documentation to indicate. (There might
be might have missed it)
Yes, it seems like we missed this one. I'll make sure it gets
documented.
PR: #27773 https://github.com/dotnet/aspnetcore/pull/27773
I'm following this example for a queued hosted service to add this to an ASP.NET Core application, and it's not clear to me where StartMonitorLoop should be called. I ended up modifying it to be EnsureMonitorLoop, added a check so that it's the call to Task.Run is only made once, added a MonitorLoop parameter to constructor for my API controller, and called EnsureMonitorLoop from there. It smells kind of funny to me that the API controller constructor should be kicking off monitoring the queue. The example Program.cs seems is very different from the one generated for me by Visual Studio. Mine uses the WebHost.CreateDefaultBuilder(args).UseStartup<Startup> approach. That is where they call StartMonitorLoop.
Where is the correct place to call StartMonitorLoop, and why? Thanks!
The docs aren't super clear here, but MonitorLoop is not actually part of this. It's an example service for use in a console app, simply to demonstrate how the queued background worker works. You can take some inspiration from this class for your app, but the concept of StartMonitorLoop doesn't apply to ASP.NET Core at all.
Just to be a bit more clear: in actual practice you would inject IBackgroundTaskQueue into a controller class, for example, and then add some task to that, just like MonitorLoop does (without all the key input jazz). You wouldn't actually have MonitorLoop or anything like it though.
I have a project that uses Autofac for constructor level injection. For every service instance, repositories are injected to constructor.
Now to start using SpecFlow for the project I am not able to instantiate the service for method calls. I have already added Specflow.Autofac plugin but now I am getting following error. I have checked all referenced assemblies versions and those are correct.
I think you are using SpecFlow.Autofac. Is this correct?
If so, it doesn't work with SpecFlow 2.2 at the moment.
For details have a look at this issue: https://github.com/techtalk/SpecFlow/issues/959
I just started to get into ASP.net Web API (created MVC 4 project, Web API application, in .net 4.5).
I need to make custom handlers in particular. All I know is that we create one (inherit DelegatingHandler), and register it in App_Start/WebApiConfig.cs's Register function.
Where do we save such a handler (MyMessageHandler), though? No tutorial or book I've come tells me this. I tried to save it in the App_Start folder with the same namespace as WebApiConfig, but it says that MyMessageHandler cannot be found:
config.MessageHandlers.Add(new MyMessageHandler()); // MyMessageHandler is not found.
Where you store MyMessageHandler.cs doesn't matter at all, as long as you get your references in WebApiConfig right. I personally store them like project_root/MessageHandlers/MyMessageHandler.cs