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.
Related
I need to calling our C# Methods from another server to perform some Action. I use C# in both servers. One is our Service Application, another one is a WPF application where I consume my Service.
Prefer I use a WCF or WebAPI service for Service Application?
Most People prefer to use Web Api, but web doesn't expose metadata for creating proxy by service.
which one is simple and better choose?
You may use either WCF or WebAPI, if multiple platforms (Mobile, Web, Other Service) are going to interact with your service, then I would recommend Web API, otherwise you may use WCF. Similar discussion has already happened in another question, please refer this link, hope this will be useful
Getting a web service and using android to consume them?
I am very basic in VB6 so sorry if I am asking an obvious question!
We have an old VB6 application and currently we need to do some re-enhancements in it. I want to somehow connect it to a WCF webservice to send and get files (WCF will take care of loading and storing them in DB).
Based on my researches, it is possible based on This article and some others, Now I am wondering if is it required to have .NetFramework installed on systems to do this?
You can use RESTFUL WCF Service and set the UriTemplate attribute for the method(OperationContract).
Full article for creating REST service
The article you have linked suggests that the VB6 code should call a .Net wrapper for the WCF service.
If you do that, then yes, certainly you will require the .Net framework to be installed on the machine that runs the VB6, because that machine will also have to run the .Net wrapper.
I have built a web service (WCF) as part of our company product, to support mobile devicies. The service is exposed via SOAP and is consumed by Android and Windows Phone 7 clients. Now we are spreading and need to add support for iPhone clients and those lazy iPhone developers are complaing, that they won't use SOAP, because its terrible, microsoftish, bloatware and there is no sufficient framework for that, etc etc and JSON ftw!
As it is WCF it was easy to create json api for this web service (new interface and little changes in web.config, love WCF!), the only problem is that I am using the built-in WCF Authentication service for authorization and this service is of course exposed via SOAP and I didn´t find a way to make it REST with json. So is there a way to somehow make it RESTful and consume/respond json?
My actual plan is to make another auth service, that will internally just call the existing WCF one via SOAP, but I don't like this workaround. I assume that, if there is not a way to make the WCF one RESTfull, later or sooner, I end up writing the auth service, which in my opinon will not be that hard.
I want to make use of some of the ASP.NET 3.5 capability within SharePoint 2007. In particular, I want to do the following:
Provide REST and maybe JSON through HTTP so that another product can consume SharePoint content.
Provide AJAX web parts within SharePoint. These will probably have little to no server side controls. Most content will be loaded using Javascript and hitting an external system (primarily not SharePoint) over HTTP that provides REST or JSON.
Provide this capability as a product. This is not a one-off solution for a single implementation.
My main concern is push-back from IT groups not wanting to change their SharePoint environment to allow for the product to work. So, I'd prefer to be able to say that what I'm doing is "supported by Microsoft", but I'm not sure that will be the case.
I realize that I could create a separate (non-SharePoint) web site on the SharePoint server(s) for WCF endpoints that provide SharePoint data to an external application. I would rather not do this because that won't help my web parts (if they need help) and that makes deployment harder. Proper SharePoint deployment will automatically have SharePoint update all necessary files (e.g., web.config) on any new web front end added to the farm and this wouldn't follow that pattern. In addition, I'd lose the ability to use SPContext.Current.
I have read much of Daniel Larson's book on Developing Service-Oriented AJAX Applications on the Microsoft Platform (good read, BTW), esp. Chapter 11 on extending SharePoint. He outlines WCF, ASMX, and HTTP Handler options and for the most part recommends the HTTP Handler option. It appears that the HTTP Handler option has minimal changes to web.config.
I have also seen a blogs on SharePoint as a WCF Host, SharePoint 2007 and the Thin .NET 3.5 Development Model, How to: Get up and running with .NET 3.5 in your SharePoint environment, and Enabling .NET 3.5 in SharePoint 2007 Sites, the Lazy Way. As well as the "Silverlight (.NET 3.5) Config Feature" (and maybe even the "Ajax.Config Feature") in the SharePoint 2007 Features CodePlex Project. It seems that all of these options do some fairly drastic changes to the web.config and may not be acceptable to potential customers.
What are the opinions out there on this? What about if I want to use the AJAX Control Toolkit (I've used this before in SharePoint, but it has been a while)?
Note that we probably could require SharePoint SP2 if that helps, but I don't think it does.
Note also that Silverlight is not a requirement for the SharePoint web parts, but allowing for it might be nice.
Your first point could be solved by a custom wrapper to the SharePoint web services, presenting the API that you want to present, rather than the generic web service.
Your second point, AJAX enabled pages and web parts, is already possible - how to enable AJAX in SharePoint.
.NET 3.5 Is supported in SharePoint (as of SP1 I believe), However you will not be able to get away from making web.config changes and installing .NET 3.5 on the servers - it will likely only be there if there are already AJAX web parts in use.
Aside from that what you are looking at is largely independent of SharePoint - If you can build something as an aspx page or asmx web service you should be able to deploy it to a SharePoint site.
If you want to avoid 3.5 installation issues altogether you should be able to build something totally separate - jQuery for the web parts (no server side components needed) and for getting data out of sharepoint build something that translates calls to the standard web services into a friendlier interface.
I'm looking to understand when to use a WCF services instead of just using webclient or httpwebrequest. I guess I'm also looking to understand the difference between the design patterns that would be appropriate for both.
Are you talking about when to create a WCF service yourself (over web service), or when to consume an existing web service using WCF instead of .NET 2.0 ASMX clients?
As for creating a WCF service yourself:
Gives you a lot more options in terms of hosting (in an app, Windows Service, IIS, WAS)
Gives you a lot more security options
Gives you a lot more protocol options (besides just HTTP, you can also use WS-*, TCP, Named Pipes, MSMQ and more)
Allows you to write your service once, and expose it on multiple end-points with different protocols at the same time
As for using WCF to talk to an existing HTTP (ASMX) web service - I don't see a whole lot of massive benefits, except WCF uses more configuration over code, and it can be good to standardize on one way of doing things, if you already use other WCF services, anyway.
Marc
I'm currently using WCF for most of the things that I would use WebClient or HttpWebRequest/HttpWebResponse in the past. While there definitely is overhead for learing how to make calls to web methods using WCF, the extensibility of WCF and the abstraction it provides makes it a MUCH better candidate for these types of calls.
I've already used it to make calls to Akismet and RPX pretty easily.
To get started, I'd look at the section of the MSDN documentation titled "WCF Web Programming Object Model", located at:
http://msdn.microsoft.com/en-us/library/bb412204.aspx