I am struggling to find a way to simply use a OData v3.0 service in any way from within Visual Studio 2017, so I can use the Client library to help develop my app/service to consume the data.
According to the Microsoft OData Stack page, they seem to have all of the tools and support to consume an OData v4.0 service. Not knowing I was in fact dealing with a v3.0 service, I followed these instructions and as the page describes, there are two tooling options to get you started. One is the OData Client Code Generator, and the other is the OData Connected Service extensions
After having to go thru some hoops to even get either one to work (see GitHub Issue for actually finding a version of the Client Code Generator that actually works with VS2017, and and trying a work around to get the OData Connected Service to work with a service that requires authentication, I finally realized I was working with an OData v3.0 response. So these tools couldn't help.
Now contradictory to what is actually mentioned on the OData Connected Service marketplace page, where is says "OData Connected Service for V1-V4", this did not work. If the OData service requires authentication, then I get this error dialog from trying to add a Connected Service via the extension:
So then I read in a GitHub issue (can't find it), is that a potential work around is to download the XML that is returned from hitting the /$metadata endpoint, rename it to whatever.edmx and try to use that for the extension by providing a file:// URI to that file. That didn't work with the following error dialog:
So then I ditched that approach and tried to instead use the Client Code Generator, and providing the edmx file to that in the TT config (to solve the auth issues, and that didn't work because it was OData v3.0 and not 4.0.
So then, it seems for v3.0, the approach is to use Add Service Reference, but when I do that, I get the following error:
..but that tool doesn't support v3.0.. so now I have no idea how to proceed!?
Any help would be greatly appreciated!
Just in case someone else stumbles on this particular combination and can't seem to proceed with consuming an OData v3.0 service with current VS2017, (and specifically on how to use it in an Azure Function), here is what I did to get around this:
Reinstall VS2015 and create a new library project
Add a new Service Reference and point to your OData v3 (or earlier) service. if the service requires authentication, this dialog will allow you to enter the creds. I was prompted to enter them 2x.
Create a class / service / interface that will expose all of the relevant tables / queries that you are interested in consuming from that OData service
Save the project and close VS2015
Copy this project to your VS2017 solution. In my case, I had a solution containing an Azure Function.
Now call upon this new project/library to obtain the data.
This is the only way I could get this to work after many many hours of troubleshooting various limitations and workarounds of the current versions. Needless to say, I am quite disappointed in the current state of the tooling + VS2017's support for consuming older versions of OData.
Related
I'm calling Dynamics 365 through it's OData Web Api and I'm wondering which client library I could use to make programming easier.
My use case is that I mainly have to work with one entity: contact. I would like to retrieve some data, edit data and create new contacts. The other entity type I'm working with in a similar way is address. A contact can have multiple addresses.
Currenlty I'm using plain HTTP Client class for the communication to Dynamics.
I am developing a .NET Core application for Linux hosts, because of this I can't use the Dynamics CRM SDK (SOAP Endpoint).
My question would be what your advice is: should I use Microsoft.OData.Client or Simple.OData.Client? Or any other library?
I tried to use Microsoft.OData.Client and generated a client (proxy/wrapper) according to this article: https://blogs.msdn.microsoft.com/odatateam/2014/03/11/tutorial-sample-how-to-use-odata-client-code-generator-to-generate-client-side-proxy-class/
The problem with this is that it generates a .cs filewith 86 MB file size. Maybe it could be a solution to use this client afterwards, but it just seems so wrong to have such a big source file in our project. I would like to avoid it, but I didn't find an option to generate this If I accidentally open it, Visual Studio crashes, intellisense get's slow some times, if ReSharper is turned on VS is slowed down enourmously, etc...
I checked Simple.OData.Client and seems to have nice documentation and API. For instance: https://github.com/object/Simple.OData.Client/wiki/Retrieving-data
For Microsoft.OData.Client I didn't find documentation how to use it in a typed manner without generating the whole client. Is that possible? I only found this, where the generated context is used: http://odata.github.io/odata.net/v6/#04-01-basic-crud-operations
I think going with Simple.OData.Client seems to be a better option, but I would prefer to use a Microsoft library.
Do you have any reccomendations?
I have just implemented integration from .Net Core Web App running in Azure App services to Dynamics 365 Web API as a POC.
This included reading reference data ( joining different entities ) and modifying entities with referential data columns.
Full OData interface generation is problematic I found:
Could not find tooling that supports OAuth2 authorization and VS2019
Full interface definition inclusive of navigational properties / functions / actions and all entities with all fields becomes unwieldy to navigate and VS navigation is sluggish.
Depending on OData client you are going to use it will be sending much more information over the wire than needed and add complexity that is not in the spirit of the underlying REST OData service.
Generated code tools violated C# coding rules ( using reserved keywords like event, abstract and also generating members with same name as enclosing type ) requiring manual correction.
After much research I started using Simple.OData.Client as this allowed me
VS2019 / .Net core compatible toolset / runtime
Connect to Dynamics 365 OData Web API with OAuth2 bearer token
Write typed code in VS
Create only the entity models / navigational properties etc that I needed
Can select only the entity attributes you need to return instead of 200 ( smaller payloads )
You have to create the entity classes used in the typed fluent API yourself
Use DataContract attributes in case you want the CRM entity names to be different between CRM / C# code.
Simple.OData will then use the DataContract attributes when making up the Http call.
Unfortunately I didn't find the documentation all that insightful when I started looking deeper on issues like OAuth2 authorization and navigational properties but did find all my answers in secondary sources like github issues and some advanced tutorials for example
https://www.odata.org/blog/advanced-odata-tutorial-with-simple-odata-client/
Also using Fiddler to see the communications going back and forth is unbelievably useful in understanding what is going on.
Microsoft has introduced a Web API, a RESTful web service you can use to interact with data in Dynamics 365 using a wide variety of platforms, programming languages, and devices.
https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/perform-operations-web-api
This is a new way of communicating with Dynamics 365 programmatically.
There are several libraries available that you can use. From below article, you can find those.
https://community.dynamics.com/crm/b/briteglobalsolutions/archive/2017/10/22/webapi-library-comparison-in-dynamics-365
I have personally used David Yack's library.
https://github.com/davidyack
Hope this helps.
I ventured to create an ASP.NET Core web application to access my WCF service and realized that the option to add a service reference has been replaced with "Connected Services".
Per Microsoft documentation, "the WCF Connected Service for .NET Core and ASP.NET Core, a VS extension providing an experience similar to the “Add Service Reference” functionality. This tool retrieves metadata from a WCF service in the current solution, locally or on a network, and generates a .NET Core compatible source code file for a WCF client proxy that you can use to access the service."
While this sounds great, I found the simplicity of adding my service reference to become just a bit more cumbersome and convoluted. Of course, this is my opinion of the change. Not to mention, I still haven't figured it out.
Exactly how do you add a WCF service reference to the project now?
Right-click offers only one option, "Add Connected Service". After which, I am provided options of:
Monitoring with Application Insights
Cloud Storage with Azure Storage
Find more services...
If I select "Find more services...", then I'm presented with a dialog of Extensions and Updates.
All I want to do is add my existing service reference! Why all the convolution of what was previously such a simple procedure? But I digress for the moment, maybe I'm getting taking things out of proportion due to my lack of understanding of the "new" Core framework.
My question was going to be simply, "How do you add a service reference to a .NET Core Web application?" but after realizing it would be a duplicate question and the fact that none of the answers I've seen provided "when provided" were not actually straight forward responses to the question.
So before I conclude that this new model seems to be a subtle nudge for integration into Azure based cloud computing and etc.
Simple question is, "Has the Simplicity of adding a Service Reference been removed in .NET Core App?"
I don't want to know the alternative methods of connecting to a WCF service using proxy utils and etc. I already know that.
You just need to update to the 15.5.x version. From the release notes you will find the entry:
Release Date: December 4, 2017 - Visual Studio 2017 version 15.5
...
The WCF Web Service Reference for .Net Core is now part of Visual
Studio 15.5.
...
as the date of this answer, 15.5.3 is the latest version
I am using Microsoft.TeamFoundation.TestManagement.WebApi 14.0 and trying to get a list of test results for an iteration.
I can get some of the information from the WebApi but I still have to revisit the old Tfs Api to get other bits.
Does anyone have a full example using WebApi that does not need to use ITestManagementService and TfsTeamProjectCollection, or is the new WebApi deficient.
Must to say, actually there are some difference between the library Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.WebApi.Client. The mainly is that Client libraries (SOAP API) use Legacy Client Object Model while WebApi libraries calls the New Rest API to achieve the functions. In some area, the WebApi library is providing only a limited functionality - for instance: check in changes with Version Control
And there are also some limitation with these two APIs:
Client libraries cannot work well with the new vNext build system.
WebApi cannot perform update action with Version Control, it can only read information for now.
More related info please refer this blog: NuGet packages for TFS and Visual Studio Online .NET client object model
And to get test results for a specific test suite you need to use the old API, a sample link：Show Test result Form test suites using TFS api
I am a Java developer who has created a rather big Web service that works nice with Java clients or other tools (Soap UI).
One of our clients wants to write a .NET client for the web service and uses the "add service reference" feature of VS2010. According to the client this does not work since our WSDL and XSD files use "Forbidden XML constructs" as defined in this article:
The problem is that we have made heavy usage of xsd:attribute data in WSDL.
So the question is:
Is there a workaround to make .NET stub generation code compliant with WSDL/XSD files that contain xsd:attribute? Is there another .NET library for webservices that supports this feature?
Another question of mine would be why does Microsoft impose these limitations in the first place? Why xsd:attribute is a forbidden costruct in a web service??? Any clues on that?
Probably related: C#.NET Generating web service reference using WSDL (from XML schema) problem
If you have access to a machine with the .NET Framework on it why don't you use svcutil to generate a proxy/config settings for him and send it to him?
See www.svcutil.com for the list of switches and options that are available to you
I have found that if the customer cannot do it one way and you provide a documented (possibly automated) way of doing things then that will generally suffice.
I have tested the HelloWorld.wsdl supplied in the link with the .NET version of Remobjects (http://www.remobjects.com) and it seemed to work fine. I don't have an actual service to test this with but I would suggest that you (or the client :) ) download it and give it a try.
The .NET version can be found here:
http://www.remobjects.com/ro/net.aspx
Apparently the answer is that you should NOT use the modern way of generating stubs with svcutil.exe and instead use the legacy way with wsdl.exe
Creating stubs from the command line with wsdl.exe works fine. The resulting code works as expected and the .NET client connects to the Axis2 Web service.
Can anyone help or direct me to a guide for using Amazon Web Service in Visual Studio 2010? I tried downloading the .Net SDK from the amazon website but it wouldn't let me add the reference to the .dll because it said that it wasn't build for Windows Phone 7.
Thank you
It seems there's no library for WP7 yet. This is because AWS does not allow cross domain requests (although there are some workarounds like this one), and therefore there's not much from the Silverlight world.
Your options here are:
Create a proxy service that talks with AWS through the .NET api. You will need to publish this service when you go live with your app though.
Build your own library based on REST (AWS will stop supporting SOAP next month). You can find the complete documentation of each web service here. Note that this would take much more time and effort, but you could make it open source so other developers can benefit and contribute to it too.