When I use the following RoutePrefix, it works
[RoutePrefix("api/v1/Home")]
But following doesn't
[RoutePrefix("api/v1.0/Home")]
Can't we use Versions with decimal?
Related
I have a WEB API application written in C# with .NET Core 3.1 that uses Windows Authentication. It builds and runs fine locally, but fails when it is deployed. The error is:
No authenticationScheme was specified, and there was no DefaultChallengeScheme
The error also tells me that I should define it in startup.cs in services.AddAuthenication. This is the line from my startup.cs:
services.AddAuthentication(IISDefaults.AuthenticationScheme)
I tried adding the nuget for Microsoft.AspNetCore.Server.IISIntegration but that made no difference.
Any ideas?
I am 'migrating' a MVC WebApplication to a Raspberry Pi 2. The original Web Application uses SignalR 2.x. After googling for weeks, I believe that the lastest Mono 4.0.1 only supports self-hosted SignalR server due to OWIN issue (ref here). So I tried to revert back to SignalR 1.x to avoid using OWIN middleware approach.
I followed the SignalR 1.x tutorial here and was able to run the sample, except that when $.connection.hub.start() is called in the client's browser, the xsp4 server throws the following exception:
Missing method System.Web.Security.MachineKey::Protect(byte[],string[]) in assembly /usr/lib/mono/gac/System.Web/4.0.0.0__b03f5f7f11d50a3a/System.Web.dll, referenced in assembly /tmp/pi-temp-aspnet-0/1543474b/assembly/shadow/c3a92c68/a3f2fa86_605bd6ee_00000001/Microsoft.AspNet.SignalR.SystemWeb.dll
The RouteTable.Routes.MapHubs() in Application_Start() seems to work OK as I can get the generated /signalr/hubs script without problem.
It seems that this function System.Web.Security.MachineKey::Protect() is not implemented in mono. I wonder if anyone has any workaround to this error.
Thank you very much in advance.
I'm attempting to use Swashbuckle to generate a swagger inteface for our API, we're returning HttpResponseMessage in our controller methods.
The docs indicate to use the [ResponseType(…)] attribute to indicate the actual return type. But that attribute is restricted to .net 4.5 (I believe, will gladly be proven wrong), and won't work in a .net4 project.
There are the XML comments, however I couldn't see how to use them the generate the schema information (I've taken a look through the unit tests in the project, but couldn't figure out if it's supported)
I use swagger-springmvc in a spring-boot project and everything works fine but when I add the swagger-spring-mvc-ui dependency to my project, swagger-ui overloads my request mapping for the base url. I'm pretty shure there's a way to point the UI to another url. Does anybody know how to change the default-path of swagger-ui?
You are using old version 0.8.8 which from com.mangofactory
I recommend you to use version 2.3.1 from io.springfox
Note: If you follow the tutorial you can access swagger without having to download Swagger-UI manually
http://localhost:8080/your-app-root/swagger-ui.html
Document Url is now available at
http://localhost:8080/your-app-root/v2/api-docs
You can change document url by specifying a property source in appication.properties file using
springfox.documentation.swagger.v2.path
reference to the changes
spring boot demo
tutorial
I want to use OData in Web Api for few Action methods in a Controller. What is happening is that once i enable OData in Web Api, the error message format is getting changes for all error .
Is there any way to configure Odata only for specific controller/action routes.
Error Message before Enabling OData looks like:
{"Message":"User Name/Password are invalid ."}
Error Message after Enabling OData looks like:
{
"odata.error":{
"message":{
"lang":"en-US","value":"User Name/Password are invalid ."
}
}
}
I would like to configure OData to handle only specific controllers so that rest of the APIs have no impact of OData setting. Your help is appreciated.
One of the big changes we made between RC and RTM is that we've completely removed the EnableOData extension method. We realized that registering OData formatters globally was a bad idea because it impacts controllers regardless of whether they're meant to be OData controllers.
So, in our v1 release for OData and in our current nightly builds, we've added a new base class called ODataController. If you derive from ODataController (or EntitySetController), you will automatically get support for OData just for that controller. It shouldn't affect the rest of your controllers the way it does now. You should also use config.Routes.MapODataRoute instead of EnableOData.
You can install our latest nightly build using these instructions:
http://blogs.msdn.com/b/henrikn/archive/2012/06/01/using-nightly-asp-net-web-stack-nuget-packages-with-vs-2012-rc.aspx
It should be pretty stable at this point.