Blog

Latest news and updates from the PlayFab developers

by Paul Gilmore 2016-12-13

Windows SDK Update Released

As we discussed in our recent blog, we are releasing a major update to our Windows SDK. This update is complete. You can get the latest version by installing the NuGet package, via Visual Studio.

You can also see the packages directly on NuGet.org:

Update Roll Out

The primary repo will not be updated until late December 2016, to facilitate a short beta period. After that, temporary repo will be deleted, and the primary repo will be replaced with this update. WindowsSdk v0.x never existed in NuGet.org, so that package will always be the latest version.

Update Details

Proposed features delivered:

  • We now support both Visual Studio 2013 and 2015. Each has its own separate NuGet package, but it should be easy to pick the right one, based on your Visual Studio version
  • Changed dependencies
    • We no longer rely on ZLib, RapidJson, CURL, nor OpenSSL
    • Most of these were not available on NuGet in their latest versions
    • We now require CppRestSdk, which provides all of these capabilities in a single package, and is up-to-date on NuGet.org
  • CloudScript results are now accessible
    • CloudScript results were a major issue with the earlier versions of PlayFab-WindowsSdk
    • All of these issues are now resolved, and any results returned by CloudScript will be parsed correctly into ExecuteCloudScriptResult.FunctionResult
  • Error Reporting
    • Some utility functions that existed in other SDKs have been mirrored to WindowsSdk, to make error reporting easier and more useful
  • Threading
    • We have added flexible threading options for API calls, providing partially asynchronous, or fully asynchronous threading options

Proposed feature not delivered:

  • Dynamic Library
    • The PlayFab WindowsSdk remains a static library
    • In short, the restrictions on a DLL interface required a large number of breaking changes, and made the SDK much harder to use
    • We ultimately decided to keep the static library, as that allows us to present an interface more consistent with our other SDKs
    • Unfortunately, this interface remains more “C#” style, rather than “C++” style, because it mirrors our C# server architecture

Bonus Features:

  • NuGet.org packages
    • While doing this upgrade, we re-discovered for the nth time how nice it is to fetch a NuGet package, build, and run, without the typical include and linking steps
    • The ease of downloading CppRestSdk reminded us that we too need to provide the easiest and best way to download and integrate our sdk
  • UPDATED: Lambda support for API callback functions
    • This support existed in the Cocos SDK, and the WindowsSdk and CocosSdk share a lot of history and capabilities
    • During the Beta phase, we were reminded that this was not yet supported, so we’ve added it in anticipation for the upcoming release

Upgrade Guide

We have rolled back almost all of the proposed breaking changes that would have made upgrading your SDK difficult. Only a few pain spots remain:

  • Api Callback results are now const objects
    • It is unsafe to modify the result objects, and allowing them to be modified makes planned future feature work less stable
  • PlayFabSettings fields use wide-strings
    • CppRestSdk uses wide unicode strings, and all of its inputs must be as well
    • Most of our data-model objects remain stl-strings, but PlayFabSettings fields had to be changed to wide-strings for performance
    • We have added some string-conversion utilities to make this easy to update
  • A few “Optional_” typedefs have been removed
    • It’s unlikely this should affect anybody, but just convert to the underlying type definition if required (or avoid reliance on our internal types)
  • Any direct use of RapidJson documents/values must be converted to the CppRestSdk web::json::value
    • Our MultiTypeVar has been removed as well, and is also replaced with CppRestSdk web::json::value
  • GitHub repo will no longer host built *.lib files
    • You should just use NuGet anyway, but the output files are too big for GitHub, so we can’t host them anymore

Thanks

Any discussion or feedback should be directed to our community support page.