Is it possible to use WCF reliable sessions in Windows Store apps?
I am writing a Windows Store app in Visual Studio 2012 Professional using C#. I am trying to access a WCF service using sessions. I can't use WSHttpBinding because Windows Store apps don't support it. I found that Windows Store apps DO support NetHTTPBinding, which supports reliable sessions, but I can't seem to access the ReliableSession property of the binding, nor can I access the constructor that takes "bool reliableSessionEnabled" as a parameter.
Is there ANY binding that supports sessions for Windows Store apps?
-Joe
As stated in the documentation (Version Information section), ReliableSession property is not available for Windows Store apps, i.e. WCF reliable sessions are not supported.
This article describes the complete subset of WCF functionalities available in Windows Store apps. Although NetHttpBinding is included, ReliableSessionBindingElement is not.
Related
I've gone through some tutorials on creating a WCF service. I'm using Visual Studio 2012. I got a very simple WCF Service Library (vb.net) and Windows Application (vb.net) communicating via WCF. That's a start.
However, my project requires I do the following:
My Windows Service - This is already an application that has it's tasks.
My Application - This is an application that is already developed as well.
I need the service to talk to the application. The service will need to send the following information to the windows application:
Status Updates
Metric Information (mostly integers for counts)
I need the application to send information to the service. It would need to send:
Reload Configuration command
Should be relatively simple, but I've never worked with WCF until today. So I have some questions...
Do I need to re-work my current windows service into a WCF Service?
Since it won't be in IIS, do I also create a WCF Service Library or do I roll this into the windows service somehow?
What is the best way to set up the different types of communication? (i.e., sending over specific metrics and reload commands)
Probably the main question is what components, in addition to my current windows service and application, will I need to make this work?
I hope that was clear :( I think I'm confusing it all... but I hope not
Your Windows service can host the WCF service. Similarly, if you want, your application can host a WCF service. The application could talk to the WCF service in the Windows Service, and the Windows Service's WCF could talk to the one in the application. Depending on the nature of the communication, you could also just use a callback channel to permit the Windows Service's WCF to call back to the application.
I suppose you should configure your WCF windows service to use named pipes. If your windows service is already built then the easiest way to do it would be to build another one as a WCF windows service and wrap the already existing functionality.
Hope I helped!
I'd like to create a document in SharePoint 2013 using a call to a WCF (or any other web service) from my console application.
I've been told that WCF access is deprecated in SP13 and will be removed in future versions. Instead, CSOM is to be used (whatever that is).
My question is about the recommended approach. Is it smart to build a solution based on WCF connection (which I know very well how to do) or should I start reading up on the other approach?
CSOM stands for Client-side Object Model. It comes in three flavors; .NET. JavaScript, and Silverlight. Using CSOM abstracts some of the plumbing that you have to do when using WCF directly but ultimately, CSOM talks to a WCF service called client.svc.
If you know WCF already, you can make RESTful calls using OData to that service from your app.
Here's more info about the different API's, http://msdn.microsoft.com/en-us/library/jj164060.aspx.
Here's more info about REST access: http://msdn.microsoft.com/en-us/library/jj164022.aspx.
I have a Windows 8 app that I want to connect to a WCF Service hosted on Windows Azure - easy.
The tricky part is that I want to allow only Authenticated users (via their windows live account) to access my service, including being able to pass a unique identifier to the service to identify the user on the Azure hosted app.
All of this plumbing is available when you use Azure Mobile Services, but surely there must be a solution for a regular WCF app within azure.
Azure Mobile Services has a MobileServiceClient type that has all of the required functionality, but I need a regular Azure-hosted WCF equivalent
You can try pulling some of the content from the now deprecated Windows Azure Toolkit for Windows 8. For the moment the Release Preview version is available; it won't work as is since it's pre-RTM, but it should help jumpstart your effort.
I'll re-emphasize though that it's not supported and Windows Azure Mobile Services is the plan of record.
Previously we have developed against the ReportServer/ReportService2005.asmx web service.
To access these web services, the MSDN documentation suggests the old .NET 2.0 based web service reference technologies. But we specifically chose to use the WCF (System.ServiceModel) technology to access this service. Regardless of whether you use .NET 2.0 WSDL or WCF Service References, in both cases proxy classes are generated to wrap the web service methods. Noteworthy, the proxy classes themselves will have different (but functionally equal) implementations. Ref: http://msdn.microsoft.com/en-us/library/ms155134.aspx
We have had great success with the WCF based service proxy against the ReportService2005 (for SSRS 2008). Recently, we were asked to do the same but to use the new ReportService2010 web service (for SQL Server 2008 R2) as the old ReportService2005.asmx/ReportService2006.asmx services have been deprecated. Ref: http://msdn.microsoft.com/en-us/library/ms154052.aspx
For context: The ReportService2006.asmx services are intended for using SSRS in a Sharepoint Integrated mode - presumably this has mostly to do with security (authentication/authorisation).
In the most simplest terms the new ReportService2010.asmx services are an almalgamation of the old ReportService2005.asmx and ReportService2006.asmx services, and you are now able to use the ReportService2010.asmx services for either "Native" or "SharePoint Integrated" scanarios.
After all that, my question is what else is different at an API level?
PS: I also found that SSRS2008R2 no longer supports Anonymous usage
For example I noticed that in the old services used to specify that the WCF Client security mode was set for "TransportCredentialOnly" using NTLM and passing your Username from the ClientCredentials. In contrast, the new 2010 services has the WCF Client security mode now set to "None" and the message still contains the UserName, but without any transport security (like NTLM).
OK, so I'm starting to guess that the act of integrating the 2005/2006 services (which likely used different authentication mechanisms) results in this change we see.
This though, has a direct impact on the API code in that previously you would be specifying the credential for the Client proxy as follows:
proxy.ClientCredentials.ClientCredential = yourCredential;
This no longer seems relevant. I also noticed that many of the proxy service methods now expect a TrustedUserHeader instance as the first parameter. For example:
proxy.CreateFolder( yourTrustedUserHeader, folder , ... );
From some documentation it appears to be implemented as a SOAP Header. This TrustedUserHeader object contains properties like UserName, UserToken, AnyAttr, etc. but I'm not sure what the proper usage pattern is. Unfortunately the MSDN documentation is equally useless in that I could not find clear guidance on this issue, nor do the MSDN documentaion use WCF ServiceModel to access the services.
Can anyone please provide some insight as to the appropriate way to now use the new Reporting Services 2010 interface?
Should I no longer set the "ClientCredentials" property, and instead create and instance of the "TrustedUserHeader"
Many thanks!
Jaans
I'm looking for the client side and server side API for Lync 2010. But I found many API that can be able to develop. Anyone what are difference between all of them? Please help
Microsoft Lync Server 2010 SDK http://www.microsoft.com/downloads/en/details.aspx?FamilyID=58ccf6fd-31db-4f15-bafb-c5ef28afc5fc
Microsoft Unified Communications Managed API 3.0 Software Development
Kit
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4493BAAB-6214-4770-8CF9-69C813E8A9FA
Microsoft Unified Communications Client API SDK
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=82c468da-3294-4ca9-bbcc-d455cfd06af2
Lync 2010 SDK is the latest Client-side SDK for Lync 2010 (doesn't work against previous versions). Its a fully managed (i.e. .Net) API, and allows you to build apps that automate the running instance of Lync to perform tasks, e.g. display presence and start a conversation from your LoB app (Automation mode). It also allows you to build your own custom clients to completely replace the Lync UI (UI Supression mode).
Unified Communications Managed API 3.0 (UCMA) is the latest server-side SDK for Lync 2010 (doesn't work against previous versions) - its also a fully managed API, and allows you to build applications that register to Lync as endpoints. This is useful for building bots, for example, a stock ticker bot that IMs people when a stock price goes over a certain threshold. You can also build call routing and IVR (interactive voice response) apps with this, and it can use Windows Workflow Foundation to reduce the amount of code you have to write.
Lync Server 2010 SDK is another server-side SDK, but rather than creating endpoints as per UCMA, this allows you to write filters that plug in to a Front End server. A filter allows you to inspect SIP traffic as it passes through the server, so its useful for building e.g. archiving solutions.
Unified Communications Client API (UCCA) is a client side API that allows you to build custom endpoints - e.g. Lync client replacements. This is best avoided, as it is COM based, so you have a lot more code to write, and need to be very careful about memory leaks. Its recommended to use Lync SDK in UI Supression mode, instead of this API. One benefit it does have though, is it works against Communicator 2007, Communicator 2007 R2 and Lync.
If you're developing against Lync and no previous versions, then Lync SDK (client) and UCMA 3.0 (server) should give you what you need. Otherwise, this article here talks about the previous SDKs in a bit more detail
Edit: I've expanded on this in a blog post
The main difference for me between Unified Communications Client API and UCMA was that UCC supports digest auth and that's why it is possible to build sip/rtp client for linux based asterisk.