We will soon upgrade to CRM 2011 so I'm doing some tests. The problem is that when I change my web service reference to the 2011 one, my application stops compiling. It just won't find any entity (example of line that stops working: Account acc = new Account() -> It says that I must miss a reference).
When I compare the web services of the CRM 4 to the one of the CRM 2011, I see that it's true. The CrmService of CRM 4 contains the definition of every entity of the CRM, but they do not appear in the CRM 2011!
Why is that? Am I missing something? Do I need to activate something?
Just to make sure, here are the URLs I'm using:
http://myserver/mscrmservices/2006/CrmServiceWsdl.aspx -> Works perfectly
http://myserver/mscrmservices/2007/CrmService.asmx?WSDL -> Does not contain entity definition
http://myserver/mscrmservices/2007/CrmService.asmx?WSDL&uniquename=MyOrg -> Does not contain entity definition
http://myserver/mscrmservices/2007/crmservicewsdl.aspx -> Does not contain entity definition
You are using the wrong endpoints.
Dynamics CRM 2011 introduces a complete new WCF based web service.
It's endpoint is http://ServerName/OrganizationName/XRMServices/2011/Organization.svc See the endpoint overview
So you should either add a Service Reference (See Use the WSDL Endpoint) or use early/late bound access (See Write Code for Microsoft Dynamics CRM (Web Services)
The endpoints you mention in your post are for legacy purposes. See the article Use the Microsoft Dynamics CRM 4.0 (2007) Endpoint
I recently came across a similiar situation. We are actually using CRM 4.0 (not 2011), and I was experiencing the same issues you are having. I came across this article:
http://www.stunnware.com/crm2/topic.aspx?id=HelpCustomizations
Basically, a reboot and refresh of the Web Service in VS fixed the issue. It looks like CRM doesn't constantly build these Web Services (which makes sense).
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 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.
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've been tasked to create an API where a web page (developed externally) should be able to communicate with a CRM system. I've looked into the CRM SDK and created a couple of C# classes that perform some basic operations to get a feeling of it, but my main issue now is what should I give the web page's developer so that he can use what I have. Does it have to be a REST/SOAP API hosted on the domain of the CRM so that the web page can send queries or can I create a DLL from the c# project and give that to the web page's developer?
In fact, how would it work out if it's a REST API if CRM is hosted by Dynamics/Microsoft?
You are looking to create a wrapper around the Dynamics CRM Api to support development of an application that interfaces with Dynamics CRM. There are two ways to do this:
Create a hosted web service.
Generate a DLL with public methods.
If you are okay with the developer-user having to configure a connection string for Dynamics CRM and the application is being developed in a .NET language and the CRM server is addressable from the location where the application runs than # 2, generate a DLL with public methods, is the easier answer.
If any of those are not true you are likely to find that # 1, a hosted web service, is a better fit.
I'm a PHP Developer that recently got introduced to Dynamics CRM Online as I am building an application that needs to pull Customer details directly from a Dynamics CRM Online account to populate a Customer selection list.
I've gone through a number of options including:
http://mscrmtools.blogspot.com/2012/08/php-to-crm-online-easy-way-to-do.html
But I was unable to authenticate at all. According to the blogger, Tanguy, MS has since changed and the solution he posted is no longer valid. I am unable to locate a new solution for connect.
I've even tried the Dynamics SDK (http://www.microsoft.com/en-us/download/details.aspx?id=24004) but I've never done C# coding so I'm at a lost and it seems the samples weren't even compiling anyway. At the same time, I'm not sure this tool was even meant for pulling data from Dynamics CRM Online or the user hosted version.
If there's anyone who can help, it would be greatly appreciated as I've been trying to figure this out for days and trying various options only to continually hit dead end after dead end.
Thanks so much in advance.
My suggestion in this situation is always to create a C# Web Service that will act as a bridge between CRM and your php code.
The Web Service use .NET so can easily pull the data from CRM, and because is a Web Service you can consume it by any platform (with SOAP or REST is your decision)
I have been working through a CRM Online - PHP connector for the last few months. I have no server to host C# code so i've been restricted to connecting to CRM using PHP.
I have managed to get Office 365 and Windows Live authentication working (in the near future all Windows Live users will be migrated to Office 365). I have been starting to document my process here.
http://crmtroubleshoot.blogspot.com.au/2013/07/dynamics-crm-2011-php-and-soap-using.html
After spending a fair bit of time on this connection I find myself agreeing with Guido Preite. If you are in a position to host a C# Web Service somewhere then this is probably worthwhile.