{"id":4259,"date":"2020-03-16T17:46:11","date_gmt":"2020-03-17T00:46:11","guid":{"rendered":"https:\/\/officedevblogs.wpengine.com\/?p=4259"},"modified":"2020-03-16T17:46:11","modified_gmt":"2020-03-17T00:46:11","slug":"microsoft-graph-net-sdk-updates","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/microsoft365dev\/microsoft-graph-net-sdk-updates\/","title":{"rendered":"Microsoft Graph .NET SDK updates"},"content":{"rendered":"

It has been a while since the <\/span>Microsoft\u00a0<\/span>Graph SDK team\u00a0<\/span>provided an update\u00a0<\/span>and customers have been asking us when the next update will be available. It is great to hear that people care!\u00a0<\/span>These updates t<\/span>ook<\/span>\u00a0a longer\u00a0<\/span>to deliver than we planned\u00a0<\/span>as we\u00a0<\/span>ma<\/span>d<\/span>e\u00a0<\/span>a few bolder steps towards our\u00a0<\/span>longer-term<\/span>\u00a0plans, and we had a few hiccups along the way.<\/span>\u00a0<\/span><\/p>\n

Service library vs core library<\/span>\u00a0<\/span><\/h3>\n

For\u00a0<\/span>all of<\/span>\u00a0our SDKs<\/span>,<\/span>\u00a0we<\/span>\u2019<\/span>ve been moving toward a deployment model where SDKs come in two types of packages: service libraries and a core library. A service library contains the models and request builders generated from a specific version of the Microsoft Graph metadata. The core library provides the infrastructure to make reliable and resilient HTTP requests to Microsoft Graph.<\/span>\u00a0<\/span><\/p>\n

The split is necessary and useful for a few reasons. Microsoft Graph metadata is updated weekly as new features are added.\u00a0<\/span>Our goal for this year\u00a0<\/span>is to be able to update the service library packages within a week of the metadata update<\/span>s<\/span>. This means that the process to release the service libraries is going to be highly automated, the version numbers are going to go high, and there\u00a0<\/span>won\u2019t<\/span>\u00a0be<\/span>\u00a0preview releases of these service libraries between minor version releases. Service libraries are a little confusing\u00a0<\/span>because<\/span>\u00a0<\/span>they have a version number, but that version number is not related to\u00a0<\/span>the\u00a0<\/span>Microsoft Graph API version. Currently<\/span>,<\/span>\u00a0there is a\u00a0<\/span>Microsoft.Graph<\/span><\/a>\u00a0<\/span>package<\/span>,<\/span>\u00a0which supports Microsoft Graph v1.0<\/span>,<\/span>\u00a0and\u202f<\/span>a\u00a0<\/span>Microsoft.Graph.Beta<\/span><\/a>\u00a0<\/span>package that<\/span>\u00a0<\/span>support<\/span>s<\/span>\u00a0the Microsoft Graph beta API.<\/span>\u00a0<\/span><\/p>\n

The core library will release on a much slower cadence and there will be preview releases. This library will work with all the service libraries. Or stated differently, the core library can be used to call any version of the Microsoft Graph API. Over time, the core library will contain all the\u00a0<\/span>handwritten<\/span>\u00a0code<\/span>, and t<\/span>he service library will only contain generated code.\u00a0<\/span>We are<\/span>\u00a0not quite there yet, but\u00a0<\/span>this<\/span>\u00a0will enable us to do more\u00a0<\/span>really cool<\/span>\u00a0stuff.<\/span>\u00a0<\/span><\/p>\n

Azure SDK alignment<\/span>\u00a0<\/span><\/h3>\n

Recently, more developers have started to take advantage of the features available in both Microsoft Graph and Azure. This has led us to work more closely with the Azure SDK team to ensure that the Azure and\u00a0<\/span>Microsoft\u00a0<\/span>Graph SDKs will work together seamlessly. We all know the challenges of mismatched dependent assemblies. We also recognized that we were building similar but different mechanisms to get authorization tokens.\u00a0<\/span>We are<\/span>\u00a0working to\u00a0<\/span>improve\u00a0<\/span>that<\/span>\u00a0experience<\/span>.<\/span>\u00a0<\/span><\/p>\n

Breaking SDK update<\/span>\u00a0<\/span><\/h3>\n

The Microsoft Graph versioning policy guarantees that there will be no breaking changes. The policy describes what is considered a breaking change, but when you get down to details<\/span>,<\/span>\u00a0there is still room for interpretation.\u00a0<\/span>The\u00a0<\/span>intent<\/span>\u00a0<\/span>of our versioning policy is\u00a0<\/span>less ambiguous<\/span>.\u00a0<\/span>We are committed<\/span>\u00a0<\/span>to ensuring\u00a0<\/span>that changes to\u00a0<\/span>the\u00a0<\/span>Microsoft Graph API\u00a0<\/span>will not\u00a0<\/span>negatively\u00a0<\/span>impact deployed\u00a0<\/span>applications.<\/span>\u00a0<\/span><\/p>\n

Recently<\/span>,<\/span>\u00a0there were a number of changes to the API that\u00a0<\/span>do<\/span>\u00a0<\/span>not cause deployed applications to fail<\/span>,<\/span>\u00a0but do change the generated service library\u00a0<\/span>in such a way<\/span>\u00a0as to potentially cause compilation errors when an existing application is updated to a new version of the SDK. For this\u00a0<\/span>reason<\/span>\u00a0you will see\u00a0<\/span>that\u00a0<\/span>the\u00a0<\/span>major version number of the\u00a0<\/span>service library for Microsoft Graph\u00a0<\/span>v<\/span>1.0 has changed. This is the first time it has happened<\/span>,<\/span>\u00a0and\u00a0<\/span>hopefully it will remain a rare\u00a0<\/span>occurrence<\/span>.<\/span>\u00a0<\/span><\/p>\n

.NET SDK v1.0 service library v3.0.0\u00a0<\/span>u<\/span>pdates<\/span>\u00a0<\/span><\/h3>\n

The\u202f<\/span>microsoft.graph<\/span>\u202f<\/span>N<\/span>uget<\/span>\u00a0package has\u00a0<\/span>moved<\/span>\u00a0from v1.21.0 to v3.0.0. You may be wondering what happened to v2.0.0. Believe it or not, we are attempting to avoid confusion.\u00a0<\/span>There has been quite a bit of talk about the Microsoft Graph\u00a0<\/span>v<\/span>2<\/span>.0<\/span>\u00a0<\/span>and we\u00a0<\/span>do not<\/span>\u00a0want anyone to\u00a0<\/span>assume<\/span>\u00a0that this\u00a0<\/span>NuGet<\/span>\u00a0package version corresponds to the Microsoft Graph API version.\u00a0<\/span>T<\/span>he\u00a0<\/span>NuGet<\/span>\u00a0package version is not related to the Microsoft Graph API\u00a0<\/span>v<\/span>ersion. We have\u00a0<\/span>a\u00a0<\/span>different\u00a0<\/span>NuGet<\/span>\u00a0package for\u00a0<\/span>each<\/span>\u00a0Microsoft Graph API version.<\/span>\u00a0<\/span><\/p>\n

The following<\/span>\u00a0changes to the service library\u00a0<\/span>might<\/span>\u00a0<\/span>cause your compiler to complain:<\/span>\u00a0<\/span><\/p>\n