Skip to content

Version 5.0

These are the release notes for the Beamable Unity SDK version 5.0

Highlights

Dotnet 10 Support

Dotnet 10 is the latest Long Term Support version of Dotnet, and it has a lot of language features and performance improvements. The Beamable Unity SDK 5.0 supports Dotnet 10 (as well as Dotnet 8).

If you are using Dotnet 8, you will not be required to update to Dotnet 10. However, if you do not have any Dotnet installed, the Beamable SDK will prefer to use Dotnet 10 by default.

The Dotnet version is controlled by the global.json file in your Unity project. This file will automatically be created by the Beamable SDK. 

1
2
3
4
5
{
    "sdk": {
        "version": "10.0.100"
    } 
}

You are allowed to use 8.0.302, or any of the Dotnet 10 versions.

If you decide to update from Dotnet 8 to Dotnet 10, then please remember to update the global.json file, as well as the <TargetFramework> option in your Microservice .csproj files. You can view Microsoft's documentation on how to update a project's Dotnet version.

Unity 6.3 Support

Unity 6.3 is the latest Long Term Support version of Unity, and it is officially supported starting in the Beamable SDK 5.0. There are no known compatibility issues with Unity 6.3 starting in SDK 5.0.

Bug Fixes

There are a variety of bug fixes and quality of life improvements in SDK 5.0. In addition to several bug fixes, the Beamable button will not be visible before Beamable has finished initializing, which helps smooth out the user flow of the SDK editor tools.

On Windows, Microservices have had file-locking related issues since the SDK 2.0 release. The core issue is that Dotnet locks the /bin and /obj folders of a Microservice while it is running. Any other attempt to access those folders while the service is running can lead to file-lock problems. SDK 5 adopts CLI 7, which introduces mechanisms to find and resolve the file-locks.

Upgrade to CLI 7.0.0

SDK 5.0 uses the Beamable CLI 7.0.0. The largest change in the CLI relates to how configuration data is stored in the .beamable folder. Previously, there were several configuration files in the .beamable folder for different parts of the Beamable software stack. For example, there was a connection-configuration.json file that described connection string information, and there was a file called ignore-paths.json that held information about which relative paths should be excluded from local Microservice detection. This approach led to several fragmented files. In CLI 7, the files are centralized into a single config.beam.json file.