I'm using Portable Class Libraries to build service classes that all our UI technology with use to communicate with our services.
These libraries will support Silverlight, Asp.Net and any other .Net UI technology.
Since Silverlight is supported, all calls must be asynchronous.
With Silverlight, I can call CloseAsync() immediately after client.Method() call to the service.
However, I'm finding that doesn't work with Asp.Net clients.
I don't want to use CloseAync() in the completed code because if multiple async calls are being made you could run into a timing issue.
I'd rather not have to come up with a lot of logic something like putting a while loop in every async method to make sure CloseAsync() hasn't been called and completed.
Right now I'm testing just using Abort in the completed sections and everything appears to be working fine.
Just curious if anybody else out there knows of any problems we may run into Using Abort?
Thanks.
We're using .Net 4.5.
It depends on which binding you're using. If you're using a binding which uses sessions, then calling Close[Async] will attempt to first close that session (e.g., WSHttpBinding with reliable messaging), then close the connection, otherwise it will remain alive in the server side until it times out. If you're using a binding which does not use sessions (i.e., BasicHttpBinding), then they're pretty much equivalent.
Related
I currently have 2 static dictionaries in a wcf restful service. These both hold look up data that's not worth putting in a database. Will these stay in memory until the application restarts or should I put them in HttpContext.Current.Application?
The static data will remain until the process recycles or stops, the same as HttpContext.Current.Application.
If you are looking for a more sophisticated caching option, check out the System.Runtime.Caching namespace introduced in 4.0. It is easy to use, works in any .NET application, and offers features like setting expiration times and creating callback functions to execute on expire.
I was looking into the new WCF 4.5 Websocket services.
Ran into trouble while making calls to the service via browser.
As it turns out (after alot of googling stuff), when you're dealing with web browser as a client for your web-sockets, the only way WCF 4.5 will work is, if you define your OperationContract with 'Action="*"' tag [as there is no explicit way to call a 'specific' function from the browser, you can just call 'ws.send("asd")' to send messages to the server, hence you need to define a single handler for all the incomming calls to the service, similarly there can only be one callback function]
Now, if you use 'Action="*"' you can only use the datatype 'Message' while defining your contracts.
This is well and good, if you want to create an echo server, but lets say, you want to upload/download data, in the default (buffered) mode, the data transfer speeds are not what they are supposed to be (20mb file takes 40-50 secs). The only way to improve the speeds is by setting the mode as 'Streamed' (i tried using 'StreamResponse').
But now the trouble is, since we can only use 'Message' as the datatype while defining the Contracts, and Message uses SOAP type def., it uses the 'Buffered' mode, even if its explicitly defined otherwise. [please correct me if i am wrong here]
So, my question is, is there any way to achieve, 'streamed data transfer' in WCF 4.5 Websockets.
And, yes i am using byteStreamMessageEncoding (latest one provided in 4.5).
And i am using 'custom binding' in the web.config as 'netHttpBinding' doesnt work with browsers.
Ohk....
Since WCF didnt work..found out it can be done using ASP.Net 4.5 handlers.
I have a WCF service which calls an STA Visual Basic 6.0 COM object. Everything works normally if only one client is using the service, but as soon as concurrent users start to call it, I'm in trouble and getting all kinds of random errors when calling one of the methods of the COM object.
At first I fixed this problem by adding support for the STAOperationBehavior attribute with the help of the article Calling an STA COM Object from a WCF Operation.
Well, it helped a lot and for some time everything seemed to work well, but now I started to get System.AccessViolationException errors on a particular server when more than one user is calling the service.
I've read that this is probably a thread problem, and I should use mutex or instancecontext in my web service.
What is the best practice for making sure that concurrent users can use an STA COM object in a WCF service without any problems?
If the object is not designed to be used simultaneously by multiple users, then you simply cannot allow multiple users to use it.
In the app I'm currently working on we are using a couple of WCF services with a lot of methods. Until now, all methods are very short running, often just getting some data. I've just added a method that takes a way longer time to run.
I do not want to raise the timeout in the config, because 1 minute is long enough for all other methods on the service.
What is the best way to deal with 1 longer running method? And how do I provide feedback that it is still running?
A long running task should really be farmed off as an asynchronous call, that could then be polled for status (or an event through a duplex connection). For a really long running task, you might even want to push it into something like Windows Workflow.
Combining WCF with WF (Workflow Foundation) seems like the best option here. Workflow Foundation gives you lots of goodies, including long-term persistence over the lifetime of your long-running process.
In .NET 3.5, it's possible to do so, but clumsy and a lot of work.
Here are a few links for this topic:
http://channel9.msdn.com/posts/mwink/Introduction-to-Workflow-Services-building-WCF-Services-with-WF/
http://code.msdn.microsoft.com/WorkflowServices
http://msdn.microsoft.com/en-us/magazine/cc164251.aspx
With .NET 4.0, these "WorkflowServices" will be a big part of the new WF/WCF 4.0 package. You should basically be able to expose an interface for any workflow as a WCF service. Sounds very promising, haven't had a chance to try it myself.
Some links for the new stuff:
WCF / WF 4.0 and "Dublin"
http://blogs.msdn.com/murrayg/archive/2009/06/23/windows-azure-s-net-workflow-service-to-support-net-4-0-workflows.aspx
http://channel9.msdn.com/shows/10-4/10-4-Episode-24-Monitoring-Workflow-Services/
http://channel9.msdn.com/shows/10-4/10-4-Episode-16-Windows-Workflow-4/
Marc
Just wondering under what circumstances would you prefer to generate a proxy from a WCF service when you can just invoke calls using the ChannelFactory?
This way you won't have to generate a proxy and worry about regenerating a proxy when the server is updated?
Thanks
There are 3 basic ways to create a WCF client:
Let Visual Studio generate your proxy. This auto generates code that connects to the service by reading the WSDL. If the service changes for any reason you have to regenerate it. The big advantage of this is that it is easy to set up - VS has a wizard and it's all automatic. The disadvantage is that you're relying on VS to do all the hard work for you, and so you lose control.
Use ChannelFactory with a known interface. This relies on you having local interfaces that describe the service (the service contract). The big advantage is that can manage change much more easily - you still have to recompile and fix changes, but now you're not regenerating code, you're referencing the new interfaces. Commonly this is used when you control both server and client as both can be much more easily mocked for unit testing. However the interfaces can be written for any service, even REST ones - take a look at this Twitter API.
Write your own proxy - this is fairly easy to do, especially for REST services, using the HttpClient or WebClient. This gives you the most fine grain control, but at the cost of lots of service API being in strings. For instance: var content = new HttpClient().Get("http://yoursite.com/resource/id").Content; - if the details of the API change you won't encounter an error until runtime.
Personally I've never liked option 1 - relying on the auto generated code is messy and loses too much control. Plus it often creates serialisation issues - I end up with two identical classes (one in the server code, one auto generated) which can be tided up but is a pain.
Option 2 should be perfect, but Channels are a little too limiting - for instance they completely lose the content of HTTP errors. That said having interfaces that describe the service is much easier to code with and maintain.
I use ChannelFactory along with MetadataResolver.Resolve method. Client configuration is a bother, so I get my ServiceEndpoint from the server.
When you use ChannelFactory(Of T), T is either the original contract that you can get from a reference in you project or a generated contract instance. In some projects, I generated the code from a Service Reference because I could not add a reference to the contract dll. You can even generate an asynch contract with the service reference and use that contract interface with ChannelFactory.
The main point of using ChannelFactory for me was to get rid of the WCF client config information. In the sample code below, you can see how to achieve a WCF client without config.
Dim fixedAddress = "net.tcp://server/service.svc/mex"
Dim availableBindings = MetadataResolver.Resolve(GetType(ContractAssembly.IContractName), New EndpointAddress(fixedAddress))
factoryService = New ChannelFactory(Of ContractAssembly.IContractName)(availableBindings(0))
accesService = factoryService.CreateChannel()
In my final project, the availableBindings are checked to use net.tcp or net.pipe if available. That way, I can use the best available binding for my needs. I only rely on the fact that a metadata endpoint exist on the server.
I hope this helps
BTW, this is done using .NET 3.5. However it does work also with 4.0.
Well in order to use ChannelFactory<T> you must be willing to share contract assemblies between the service and the client. If this is okay with you then ChannelFactory<T> can save you some time.
The proxy will build async functions for which is kind of nice.
My answer is a kind of summary of Keith's and Andrew Hare's answers.
If you do not control server, but have only WSDL/URL- generate proxy using Visual Studio or svcutil. (Note that Visual Studio sometimes failed, when svcutil works better).
When you control both server and client, share interfaces/contracts and call ChannelFactory
.
It's not just a matter of time saved. Using the WSDL generated proxy is dangerous because if you forget to update the service reference you can leave the solution in an inconsistent state. Everything compiles but the service contract is broken. I definetly suggest to use a ChannelFactory whenever possible, you make your life much easier.
A possible alternative could be to write a prebuild script that calls the SVCUtil utility to create the proxy everytime you build your project, but anyway ChannelFactory is much more neat and elegant.