My team and I are working on a new netstandard 2.0 project that will make CRUD requests on XRM/Dynamics CRM (v9+). We need a new nuget that is compatible with netstandard 2.0 and makes REST calls.
We have tried the nuget Microsoft.CrmSdk.CoreAssemblies but we would like to avoid using the CRMContext and make REST calls passing the access token inside.
Web API is built on open standards, ODATA, and you don't need to add specific assemblies to use it. You just have to compose HTTP requests for specific operations.
This guide can be a good starting point https://learn.microsoft.com/en-us/dynamics365/customer-engagement/developer/use-microsoft-dynamics-365-web-api
Microsoft is transitioning with v9 of CRM to give more parity to the new WebAPI accesses and will probably eventually phase out the organization service which is supported via the SDK lib
Related
I am building an application using AWS SES, but it is not clear to me which version of the API I should be developing against.
AWSSDK.SimpleEmail
AWSSDK.SimpleEmailV2
Looking at the Amazon Simple Email Service Documentation I see both API and API v2 listed.
Logic would tell me to use v2 as that is a higher number, but at the same time the Developer Guide primarily references API (not API v2).
Similarly the Code examples section is much smaller for v2.
If I look at the .NET libraries, which is the SDK I would be using, it isn't much help either, and both versions have had updates pushed in the last 24 hours, and both are on version 3.10X.XX.
Is there any documentation from AWS that indicates the status of their SES SDKs and when particular versions are going to be deprecated? I would prefer not to start developing against a specific version only to find that support is ending for it in a short time.
Thanks
As per https://docs.aws.amazon.com/cli/latest/reference/ses/index.html
AWS CLI version 2, the latest major version of AWS CLI, is now stable
and recommended for general use. To view this page for the AWS CLI
version 2, click here. For more information see the AWS CLI version 2
installation instructions and migration guide.
In other words, I would recommend using version 2.
Now the question you are asking is given the .NET SDK V3, what version of the SES .NET API should you use.
In the AWS Github, it uses SES .NET Service Client v1:
https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/SES/Actions
However, now there is .NET Service Client v2.
https://docs.aws.amazon.com/sdkfornet/v3/apidocs/items/SimpleEmailV2/TSimpleEmailServiceV2Client.html
Both are supported and I do not think you have to worry about support for v1 ending in the short time. I will confirm and post back.
I am working on API versioning on .Net Core 3.1. The issue is that we are consuming an external nuget package that will apply different versions on different API versions. For example, for API Version 1.0, I need to use V2.0 of this nuget package; for API Version 2.0, I need to use V3.0 of this nuget package.
So if I use the strategy this way: https://dev.to/99darshan/restful-web-api-versioning-with-asp-net-core-1e8g by spliting the controller classes in the same project, then it would force all of my API versions with the same nuget package versions.
I was wondering what's the better way to do API versioning in my scenario?
As long the features you are using are functionally compatible (typically by source code), then the NuGet package versions do not need to match. You did not specifically say, but I get the impression you are defining API versions by applying attributes and that is the only surface area used by the code and libraries that define the corresponding controllers.
You're describing a typical setup for plug-in or composition based API applications. Assuming that is correct, then the NuGet package version is only interesting to the host application (e.g. the hosting server code). The host application that runs the server must use a version of the NuGet package that is greater than or equal to the highest version used by any of the other referenced assemblies. The rest is handled by .NET, not NuGet. Modern .NET projects enable automatic binding redirects; typically without any developer configuration. This means that if your controller libraries are an array of say version 1.0, 2.0, and 3.0 and the host references 3.0, then all libraries ultimately use 3.0 at runtime. The only caveat to this is that all libraries must target the same runtime. For example, you cannot make a mix of full .NET Framework and .NET 5.0 (formerly .NET Core) work together. As long as the runtimes are aligned, you should not have any problem getting everything aligned; regardless, of NuGet package or assembly version.
There are also, at least, two other solutions to this problem.
Use Conventions - API Versioning provides a fluent interface for defining API versions by convention. It was designed to solve the exact problems of applying API version metadata to controllers defined in another library. This configuration would likely be defined in the host application. You can also define your conventions so you don't have to define every version individually. The VersionByNamespaceConvention uses this approach to derive a single API version by the containing .NET namespace.
Use Custom Metadata - Contrary to popular belief, API Versioning does not care about attributes. It provides some attributes as a simple, out-of-the-box way to apply metadata, but it's not a hard requirement. It only cares about IApiVersionProvider. This means that you can easily roll your own attributes and then plug it into API Versioning by implementing IApiVersionProvider or IControllerConvention. This would allow you to create metadata library, with .NET Standard if necessary, that will likely never change and you can subsequently add to the versioning configuration.
#2 is a more advanced scenario. I'm not aware of any existing examples that would demonstrate all of that end-to-end, but if you choose that path and have questions, I can push you in the right direction.
My team has written maintains a library that wraps functionality around a full framework .net .dll, specifically the IBM FileNet.Api.dll. We have been transitioning our library to use .net Standard and so far, all is well. After creating a .net core app and attempting to connect to FileNet, we run into a web service runtime problem.
Here is the error that is thrown:
The operation cannot be completed because a supported web service
runtime is not present. Either Microsoft Web Services Extensions (WSE)
3.0 or the Windows Communication Foundation (WCF) is required.
Does anyone know of a NuGet package that provides this runtime for .net Core or a workaround for this issue?
Updade:
I have now had several conversations with the engineer team at IBM and they do not support .NET Core, nor do they plan on supporting it at this time. What I am doing is to create a .NET Framework 4.x API to basically convert to and from FileNet. It's a bit janky but when the customer wants their API in .NET Core I'm having to build something to make it work.
I'm running into the same issue. From what I've discovered System.Web.Services which is used by the FileNet.Api.dll and IBM's CEWSI for creating SOAP connections has been deprecated after .NET Framework 4.x in favor of WCF and is not available in .NET Core, .NET Standard, nor .NET 5.
It also appears that Microsoft is pushing developers to use REST instead of SOAP. I have not found anything from IBM to replace the DLL or CEWSI.
Sorry this isn't more useful, I'm still trying to figure out how to use .NET Core with it as well and short of basically recreating the functionality myself I haven't found a viable solution.
I want to use Google.Apis.AnalyticsReporting.v4 to ETL the google analytics data to our data warehouse. It is worthy to mention that I use SSIS (Microsoft Integration Service) and use Script Component (C#) as task to ETL aforementioned data.
I found this task very hard and find these references,
Use Google Analytics API to show information in C#
It used Google.Apis.Analytics.v3 for doing this and it is not V4. First of all, I create service account,
https://cloud.google.com/iam/docs/creating-managing-service-accounts#iam-service-accounts-rename-console
and save service account email and .p12 key, after that I use this method,
Analytics Reporting v4 with API key
that use Google.Apis.AnalyticsReporting.v4 but many references have errored and they are old, such using Google.Apis.Services;
I confused and want to know the code for ETL the GA data by C#. Appreciate to help me on this issue. I want to ETL metrics like "session" and dimension like "campaign"
I was never able to get it to work using a scripting component because of the .net version of the dlls. The library dlls are around .net 4.5 and as far as far as i could see most versions of MS Sql server dont support higher then .net 4.0. You also have to figure out where the dlls need to be in order for ssis to find them. If your going to get it to work your going to need all the dlls from the library as you cant use nuget install. i would start with the basic tutorial get that working as a console application then copy it over to SSIS and put that into your scripting component you need all the using and their corresponding dlls there is a lot of them.
Google apis.services isnt old its the auth part of the library it just hasnt needed to be changed.
custom component
What I have done was create a custom component to connect to Google analytics. The main issue I had was the dlls and the .net framework. I was never able to use the Google .net client library. I was only able to get this working by manually creating my own Google analytics library targeting .net 3.5 and using Oauth2 rather than service account.
Coding my own service account authentication code has so far escaped me. I beleave i have a very old open question here on stack asking how to get it to work.
Disclaimer: I work at ZappySys
Calling API is possible in SSIS using Script Task by referencing SDK dlls but you have to consider two things.
How much effort needed to code this flow. Some times its not worth it to develop your own if any one already developed such component (Free or Paid).
Is SDK provided by Google is compatible with SSIS version? Each SSIS version supports specific .net version(s). So you must use Google SDK compatible with that. For Example if you like to code this for SSIS 2012 then you must use SDK which is coded in .net 4.0 or Lower version. Using latest SDK might not work sometimes if its coded in .net 4.6 for example.
Here is the list of supported .net versions by various SQL Server / SSIS
SSIS / SQL Server 2012 - Use .net 4.0
SSIS / SQL Server 2014 - Use .net 4.5 or lower
SSIS / SQL Server 2017 - Use .net 4.6.0 or lower
SSIS / SQL Server 2019 - Use .net 4.6.2 or lower
If you do not want to go through hassle you may consider 3rd party components such as ZappySys Google Analytics Source for SSIS
When trying to use Microsoft Dynamics 365 SDK Core Assemblies in a .NET Core 2.0 project, the following error occurs at runtime simply by using Microsoft.Xrm.Sdk:
TypeLoadException: Could not load type
'System.ServiceModel.Description.MetadataConversionError' from
assembly 'System.ServiceModel, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089'.
It looks like the Core Assemblies (Microsoft.Xrm.Sdk.Client) may simply not be compatible with anything other than ~net4x.
Is there any obvious way to get around this error or load the WCF System.ServiceModel class/interfaces needed by Microsoft.Xrm.Sdk in the context of target netcoreapp2.0? Is it possible to use
Microsoft.Windows.Compatibility to bridge the gap? It looks like the Microsoft.Windows.Compatibility pack documentation indicates Windows Communication Foundation (WCF) classes/interfaces are "available". How can I use the compatibility pack to perhaps load System.ServiceModel.Description?
Thank you for any help you can provide!
I tried all possible things and can say that SDK, ServiceModel etc are not compatible with .net core and never will be, according to multiple discussions on github. However, i was able to do this:
Use XrmToolBox and crmsvcutil.exe to generate models (optional)
place them in netstandard2 project
reference XRM SDK from nuget
SDK works under .net core in part where LINQ queries and raw QueryExpressions are translated to subclasses of OrganizationRequest
write custom IOrganizationService which serializes OrganizationRequests and sends them to some other app
Other app is .net core web api which references that project and XRM SDK, but runs on full framework on windows and executes actual requests, serializes responses and sends them back.
IMPORTANT EDIT:
I found out that SDK 2016 doesn't work reliably in .net core on linux due to various reasons, and stopped at 2011 (nuget package is Microsoft.Xrm.Sdk.2011). It works fine except in one case: whe you do context.AddObject and pass an Entity with no ID. SDK relies on p/invoking native Windows library to create sequential UUID and crashes on Linux. You can overcome this by setting ID prior to calling .AddObject().
I had the same issue and it got resolved when I selected template Console Application (.Net Framework) in Visual Studio instead of Console Application (.Net Core).