Now I need to reference a WCF service in a UWP program. However, the address of the WCF service may change frequently in the future.
I don't want to rebuild/republish the project every time when the address change.
So I want to use a LocalSettings to Save/Load the address of WCF service. Every the program begins, it will reload the address from the LocalSettings. And if the address changes, I just only let the customer change the LocalSettings from UI but not need to rebuild/republish the project.
How can I do it? Or there is any other better to do it?
If it's a RESTful service, you could use HttpClient relevant APIs to consume a REST service in UWP.
Please note that REST is a resource that implements a uniform interface using standard HTTP GET, POST, PUT methods that can be located by URI. So, you could use HttpClient to call it in code-behind. You will get response after you send http request, then you could analysis the response result.
The similar thread for your reference: Calling web service asynchronously in page constructor.
Using LocalSettings for such thing is a good solution.
LocalSettings are just a dictionary where you can assign values you want to store and later take out.
ApplicationData.Current.LocalSettings["ServiceAddress"] = "something";
Debug.WriteLine(ApplicationData.Current.LocalSettings["ServiceAddress"]);
Such setting will survive app restart and is stored in applicaton's private storage.
You will probably want to seed this setting with a default value at first startup.
Related
I created a Workflow Foundation workflow which will eventually invoke another Workflow Service. I added the call to this service by dragging the appropriate shape from the toolbox onto the designer. The shape was available because I added the Workflow Service as a service reference as recommended.
How can I specify a specific endpoint address for this web service? I can't find a way to programmatically specify the address.
The workflow always uses the address specified in the web.config. But based on certain conditions I want to use different addresses.
Edit
Here is a picture I created to illustrate the problem:
Look for the place where you make a call to the Workflow Service. Somewhere there you define a client. It should look something like this:
client.InvokeService(); // or whatever method you call;
If you want to change address you should change endpoint address before this call, ideally when you define the client:
client.ChannelFactory.Endpoint.Address = new EndpointAddress("http://something.com/service.wsdl");
But keep in mind that this is not recommended practice. If you intend to change it programmatically it's better to get rid of services section in your web.config completely and set properties programmatically when creating client.
I am using a web application as a client to invoke WCF methods using proxy.
For each request being made by client object, I need to populate few properties (declared inside request class)
Is it possible to hook a method, just before making the actual web service call.
I can't modify service code right now, Can WCF extensibility points could be leveraged in this case?
Thanks for your help.
If you want to change the properties of the method parameters, you can use an IParameterInspector to do that, since at that point you'll get an array with all parameters to be sent to the server.
If you need to change other parts of the request (such as transport or SOAP headers), an IClientMessageInspector may be the best way to go.
For more information on many extensibility points at the client side, you can check the blog series at http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx.
i have an Autocomplete ajax control that calls a WCF service method automatically.
this method gets a string as an input parameter and return a list of strings.
i don't make that call from the client , the control does it, but i write the content of this method.
Can i store some data somewhere in the WCF service when that method is called and extract it later when i use the WCF from the client ?
i mean , i want the control to call the method, in the method i'll store some data and later when i use the WCF client object i'll extract it.
is there such "WCF cache" mechanism?
No, there's no such thing as a 'WCF cache' mechanism. But WCF is .NET, and in a .NET application you can use the Caching Application Block.
Caching has very little if anything to do with WCF. You cache inside your application, but the caching mechanism for a WCF service is fundamentally the same as a Windows Forms application or a managed Windows Service (or an ASMX webservice, or a ASP.NET application, or any .NET application). The only difference is how you use and rely on the cache & how the applicaton's lifecycle is managed.
If your WCF service is hosted in IIS (as is very popular), then when the application pool is recycled (or the website is restarted) you will lose everything in the cache. Will this be a problem?
The typical use case for a cache is when you have a set of data stored (in, say, a database) that will need to retrieved over and over again. Rather than get from the database everytime, you get from the cache. If it's not in the cache, you get from the database and put it in the cache so it's there for next time. It sounds like you want to store some data from the client application in the cache. You can do this, but what will happen if it's not there when you go to retrieve it.
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.
I am using wcf 4 and trying to transparently transfer context information between client and server.
I was looking at behaviors and was able to pass things around. My problem is how to flow the context received in the incoming headers to the other services that might be called by a service.
In the service behavior I intercept the the message and read the headers but don't know where to put that data to be accessible to the next service call that the current service might make.
What I am looking for is something like:
public void DoWork()
{
var someId = MyContext.SomeId;
//do something with it here and call another service
using(var proxy = GetProxy<IAnotherService>())
proxy.CallSomeOtherMethodThatShouldGetAccessTo_ MyContextualObject();
}
If I store the headers in thread local storage I might have problems due to thread agility(not sure this happens outside ASP.NET, aka custom service hosts). How would you implement the MyContext in the code above.
I chose the MyContext instead of accessing the headers directly because the initiator of the service call might not be a service in which case the MyContext is backed by HttpContext for example for storage.
In the service behavior I intercept
the the message and read the headers
but don't know where to put that data
to be accessible to the next service
call.
Typically, you don't have any state between calls. Each call is totally autonomous, each call gets a brand new instance of your service class created from scratch. That's the recommended best practice.
If you need to pass that piece of information (language, settings, whatever) to a second, third, fourth call, do so by passing it in their headers, too. Do not start to put state into the WCF server side! WCF services should always be totally autonomous and not retain any state, if at ever possible.
UPDATE: ok, after your comments: what might be of interest to you is the new RoutingService base class that will be shipped with WCF 4. It allows scenarios like you describe - getting a message from the outside and forwarding it to another service somewhere in the background. Google for "WCF4 RoutingService" - you should find a number of articles. I couldn't find antyhing in specific about headers, but I guess those would be transparently transported along.
There's also a two-part article series Building a WCF Router Part 1 (and part 2 here) in MSDN Magazine that accomplishes more or less the same in WCF 3.5 - again, not sure about headers, but maybe that could give you an idea.