By default, Json.NET ignores the Serializable attribute. However, according to a comment to this answer by Maggie Ying (quoted below because comments are not meant to last), WebAPI overrides that behavior, which causes your output. Json.NET serializer by default set the IgnoreSerializableAttribute to true. In WebAPI, we set that to false. The reason why you … Read more
You could read from the underlying request: using (var stream = new MemoryStream()) { var context = (HttpContextBase)Request.Properties[“MS_HttpContext”]; context.Request.InputStream.Seek(0, SeekOrigin.Begin); context.Request.InputStream.CopyTo(stream); string requestBody = Encoding.UTF8.GetString(stream.ToArray()); }
Thanks but getting 405 error,after the above config changes. Finally it works after adding below code in web api Global.asax file protected void Application_BeginRequest(Object sender, EventArgs e) { //HttpContext.Current.Response.AddHeader(“Access-Control-Allow-Origin”, “*”); if (HttpContext.Current.Request.HttpMethod == “OPTIONS”) { HttpContext.Current.Response.AddHeader(“Cache-Control”, “no-cache”); HttpContext.Current.Response.AddHeader(“Access-Control-Allow-Methods”, “GET, POST”); HttpContext.Current.Response.AddHeader(“Access-Control-Allow-Headers”, “Content-Type, Accept”); HttpContext.Current.Response.AddHeader(“Access-Control-Max-Age”, “1728000”); HttpContext.Current.Response.End(); } }
Since OAuth is not an authentication protocol, there is no notion of signout. Delete the access token on the client – that’s all you can do. If you want to invalidate the token on the server side, add a unique id to it and keep track in your service – you would need to manually … Read more
The static stuff is going away. If your not using a Service Locator of some type you’re going to have implement your own “ObjectFactory” as referenced here: public static class ObjectFactory { private static readonly Lazy<Container> _containerBuilder = new Lazy<Container>(defaultContainer, LazyThreadSafetyMode.ExecutionAndPublication); public static IContainer Container { get { return _containerBuilder.Value; } } private static Container … Read more
How interesting! It appears that Thread.CurrentPrincipal is based on the logical call context, not the per-thread call context. IMO this is quite unintuitive and I’d be curious to hear why it was implemented this way. In .NET 4.5., async methods interact with the logical call context so that it will more properly flow with async … Read more
Prevent mixing MVC and Web API in the same project. Microsoft seems to suggest this, because the Visual Studio template for Web API mixes the project automatically with MVC, but this is a bad idea. From an architectural point of view, MVC and Web API are completely different. MVC is a UI technology aimed to … Read more
I ran into something similar in .NET 4.0 (no async/await). Using the debugger’s Thread stack I could tell that ReadAsMultipartAsync was launching the task onto the same thread, so it would deadlock. I did something like this: IEnumerable<HttpContent> parts = null; Task.Factory .StartNew(() => parts = Request.Content.ReadAsMultipartAsync().Result.Contents, CancellationToken.None, TaskCreationOptions.LongRunning, // guarantees separate thread TaskScheduler.Default) .Wait(); … Read more
Unfortunately, caching is not built into ASP.NET Web API. Check this out to get you on track: http://www.strathweb.com/2012/05/output-caching-in-asp-net-web-api/ An updated resource here: https://github.com/filipw/AspNetWebApi-OutputCache EDIT: As of 2020-02-03, even though this answer is quite old, it’s still valid. Both of the URL’s above lead to the same project, ASP.NET Web API CacheOutput by Filip W
You shouldn’t return a System.Drawing.Image, unless you also add a formatter which knows how to convert that into the appropriate bytes doesn’t serialize itself as the image bytes as you’d expect. One possible solution is to return an HttpResponseMessage with the image stored in its content (as shown below). Remember that if you want the … Read more