The application on which I am working has a web service exposing various methods. Most of these methods use WebOperationContext.Current to set headers up to prevent cacheing. This works fine when the service methods are consumed in AJAX via the generated proxy, but when I attempt to do the same thing from code-behind, WebOperationContext.Current is null.
Can anyone tell me how to confer appropriate call context on the method invocation?
Related
According to the documentation for UseRouting(), we must call UseEndpoints() afterward:
A call to UseRouting(IApplicationBuilder) must be followed by a call to UseEndpoints(IApplicationBuilder, Action) for the same IApplicationBuilder instance.
But in some code samples (e.g. here) I see UseRouting() calls with UseEndpoints() omitted and MapRazorPages() used instead. Is this safe?
I entered this query into ChatGPT:
What is the difference between App.MapRazorPages and App.UseEndpoints(Sub(Routes) Routes.MapRazorPages)?
...and it returned this helpful answer:
App.MapRazorPages is a method that configures the routing for Razor pages in an ASP.NET Core application. It adds a default route for all Razor pages, which is {page}/{handler?}, where page is the name of the Razor page and handler is the name of an optional handler method defined within the page.
App.UseEndpoints is a method that enables you to specify a pipeline of middleware that will be executed when a request is received by the application. Within the lambda expression provided to UseEndpoints, you can call MapRazorPages to add a route for Razor pages to the pipeline.
So, in short, App.MapRazorPages is a specific method that configures routing for razor pages, while App.UseEndpoints is a more general method that allows you to specify a pipeline of middleware and register various types of endpoints, including razor pages, in the application.
All well and good. Very nice. But what about the admonition from the documentation, that we must call UseEndpoints() at some point after we call UseRouting()? Is it safe to rely on only a call to MapRazorPages() to fulfill that requirement?
This answer seems to indicate so, but I'd like to make sure before I go stringing things together that I don't fully understand.
---EDIT---
Well, go figure.
I consulted the almighty ChatGPT on this one (should've done that at first, I guess) and he boomed down:
No, it is not safe to rely on a call to MapRazorPages() as a substitute for the required call to UseEndpoints().
UseRouting() is used to enable routing in an ASP.NET Core application. It sets up the routing system and prepares the app to handle incoming requests.
MapRazorPages() is an extension method that can be used to configure Razor pages in an ASP.NET Core application. It adds a Razor pages endpoint to the application's endpoint routing table, which allows the app to handle requests for Razor pages.
UseEndpoints() is used to define the endpoints for an ASP.NET Core application. It adds a route to the application's endpoint routing table for each endpoint defined within the lambda passed to it.
So, while MapRazorPages() can be used to configure razor pages and add a corresponding endpoint to the application's endpoint routing table, it cannot be used as a substitute for UseEndpoints(). UseEndpoints() is required to properly define the endpoints for an ASP.NET Core application and handle incoming requests.
So there we have it. But should we trust it? I'm a little bit wary, perhaps because I tend to prefer to live on the edge and not allow myself to be lulled into complacency by The Matrix.
Can someone corroborate?
It differs in different .NET versions.
For example, in .NET 5, you have to call app.UseEndpoints() to register routing. However, in .NET 6 you can register routes with a call to app.MapRazorPage() directly, leaving out both app.UseRouting() and app.UseEndpoints(). This is documented here.
Apps typically don't need to call UseRouting or UseEndpoints. WebApplicationBuilder configures a middleware pipeline that wraps middleware added in Program.cs with UseRouting and UseEndpoints. However, apps can change the order in which UseRouting and UseEndpoints run by calling these methods explicitly.
I have a service that is injected and that is being called from specific Pages in my Blazor project.
That service is implementing some methods that need to know in which ASP.NET Blazor context/page they are being called. I want to avoid passing this as a parameter to my methods and was hoping to get access to the name/type of the page that it is being called from.
Something like IHttpContextAccessor but instead of getting access to the HTTP context, I would love to get access to the Page object and perform logic based on that.
Any ideas?
Thanks
IF
all you need to know is the name, you could maybe get it from a CallerFilePath attribute on the method.
Note that is a big IF
Another option would be to inject NavigationManager into your service (your service would need to be registered as scoped or transient) and get the current url from that.
Does MOQ give access to Castle's DynamicProxy generation? Or are there configurable static methods or something in the Castle namespace that would allow me to tune MOQ's proxy gen behavior?
Some Background
I am Mocking a WCF Service endpoint (IWhatever). WCF automatically adds Async call back options for methods (e.g. IWhatever.DoWork() is also realized as IWhatever.DoWorkAsync()).
I'm looking to use the Mock<IWhatever> object while self-hosting this service mock'd; basically spoof this external web service to my system. However, when [self-hosted] WCF tries to create a DoWorkAsync() method; it already exists... which ultimately throws errors when opening the self-hosted/mock'd IWhatever endpoint. ((NOTE: I don't have access to original contract to use directly)).
Sooo.. looks like Castle DynamicProxy allows for one to define which methods should be generated (see: http://kozmic.net/2009/01/17/castle-dynamic-proxy-tutorial-part-iii-selecting-which-methods-to/). I was thinking I would use to not intercept calls on methods ending with "[...]Async". However I don't see where I would add this customization rule in the proxy generation within MOQ; hence my question.
I have a following issue regarding using WCF service from my ASP .NET mvc application. Service requires a callback method to be implemented on the client side. For that I am using wsDualHttpBinding. Callbacks are being invoked and the correct info is recieved (checked using brakepoints multiple times).
The issue lies in the fact that I'm not able to save the data that I recieve when callback "SendComment" is invoked from WCF service. Callback method definition:
public void SendComment(ChatComment cc)
{
Session["Message"] = cc;
}
This is a method that should allow client (in asp .net) to recieve chat messages that are broadcasted to multiple clients from WCF service.
When I try to access Session["Message"] from the controller methods, it's value is null after I have recieved a callback. This is the main problem. I have to find a way to save the value for it to be available in current session context.
Additionally i can't access any of the other session variables I have saved right before the callback is invoked. They are always null.
Besides how do I know when I've recieved the callback? Do I have to use event handlers or somehow call the controller/view from this method?
I've already tried googling for the answer but none of the solutions explicitly state how to access the value after callback has happened.
P.S. Sessions are set to required in WCF Service.
This will not work the way you designed it. A few reasons why not:
You cannot access session from callback.
You cannot call client directly from ASP.Net MVC application.
You have too look for some other solution. I suggest you look into SignalR or if you need something simpler use DB to store data and pool from client.
I have develope a small web application in that i am using wcf service,I have creating a methods like GetData(), When i call this method in Browser it doesn't show any data just it showing blank page please help me how can i resolve this problem.
http://localhost:54421/Service1.svc/GetData
Contrary to SOAP ASMX web services with WCF you can no longer invoke them directly in the browser. You could use the WcfTestClient.exe utility to quickly test a method. You can invoke the method directly in the browser if you are using REST and GET verb is allowed for this method.