Add support for Unity6.5

[timoore]

Description

Add support for Unity 6.5, while retaining compatibility with Unity 6.3. In Unity instanceIDs have been replaced with an opaque EntityId which is actually a 64 bit integer. Our native code will use one or the other as appropriate.

Additionally, the TreeView classes now require templated versions, so their usage was updated.

Issue number or link

#704

Author checklist

• I have submitted a Contributor License Agreement (only needed once).
• I have done a full self-review of my code.
• [ X I have updated CHANGES.md with a short summary of my change (for user-facing changes).
• I have added or updated unit tests to ensure consistent code coverage as necessary.
• I have updated the documentation as necessary.

Remaining Tasks

Test with Unity 6.5 in GitHub CI?

Testing plan

Gave it a spin with Unity 6.3 and 6.5.

Reviewer checklist

Thank you for taking the time to review this PR. By approving a PR you are taking as much responsibility for these changes as the author.

As you review, please go through the checklist below:

• Review and run all parts of the test plan on this branch and verify it matches expectations.
  • If the issue is a bug please make sure you can reproduce the bug in the main branch and then checkout this branch to make sure it actually solved the issue.
• Review the code and make sure you do not have any remaining questions or concerns. You should understand the code change and the chosen approach. If you are not confident or have doubts about the code, please do not hesitate to ask questions.
  • Code should follow the C++ Style Guide
• Review the unit tests and make sure there are no missing tests or edge cases.
• Review documentation changes and updates to CHANGES.md to make sure they accurately cover the work in this PR.
• Verify that the Contributor License Agreement has been submitted, if needed.

[timoore]

This should be ready for review now.

[azrogers]

While running the built package I get the following error:

Library\PackageCache\com.cesium.unity@aae6182cf96f\Source\generated\Reinterop.RoslynSourceGenerator\ReinteropInitializer.cs(232261,19): error CS0619: 'TreeView' is obsolete: 'TreeView is now deprecated. You can likely now use TreeView instead and not think more about it. But if you were using that identifier to store InstanceID data, you should instead opt to upgrade your TreeViews to use TreeView to get the proper typing.'

I believe this is because the preprocessor directive is handled when the package is built, so the code that's outputted is the code for the version of Unity we're building on CI with. I think this might mean we need to build a separate package for Unity 6.5+. I think it should be possible to distribute this through the package manager and have it handle the correct package for the correct unity version, though I'm not positive.

[timoore]

While running the built package I get the following error:

Library\PackageCache\com.cesium.unity@aae6182cf96f\Source\generated\Reinterop.RoslynSourceGenerator\ReinteropInitializer.cs(232261,19): error CS0619: 'TreeView' is obsolete: 'TreeView is now deprecated. You can likely now use TreeView instead and not think more about it. But if you were using that identifier to store InstanceID data, you should instead opt to upgrade your TreeViews to use TreeView to get the proper typing.'

Just to be sure, you're testing the built package in 6.5?

I believe this is because the preprocessor directive is handled when the package is built, so the code that's outputted is the code for the version of Unity we're building on CI with. I think this might mean we need to build a separate package for Unity 6.5+. I think it should be possible to distribute this through the package manager and have it handle the correct package for the correct unity version, though I'm not positive.

I guess this comes down to the meaning of "6.5 is supported" and whether we want to commit to that in this release.

[j9liu]

I guess this comes down to the meaning of "6.5 is supported" and whether we want to commit to that in this release.

We can definitely try to build a separate package for 6.5 and release on GitHub. Sadly I don't think we can have two package versions with the same version number but intended for different Unity versions.

We could try to host two versions, one that is 1.X.Y and 1.X.Y.65 (or something similar) and restrict the .65 version to "unity": 6000.5. That's pretty hacky, but at least it would allow both versions to be available?

For now, I think it's worth:

• Rewriting the changelog entry to "Added support for building the package from source in Unity 6.5." (Or "Fixed errors when building the package from source in Unity 6.5"?)
• Merging this PR in.
• If time allows, add a follow-up PR to build this on CI and incorporate it into next month's release. (Does not have to be @timoore).

Is that a fair game plan?

[kring]

Using a #if in a ConfigureReinterop file is never going to work properly. Or at least it will require separate native builds for the different versions. We really don't want to do that. For one thing, it will double the already horrendously long CI times.

It should be possible to solve this using inheritance instead. In a separate file, define a class CesiumTreeViewItem. Using a #if, make it inherit from either TreeViewItem or TreeViewItem<int> depending on the Unity version. Then use that class in this file instead of TreeViewItem.

If there are any methods of CesiumTreeViewItem where the signature changes as a result of the #if, you can't use them in ConfigureReinterop. Provide a common signature by wrapping them instead.