Move MRTK build tools into their own distinct repo and package

[MenelvagorMilsom]

Move MRTK build tools into their own distinct repo and package

I've been thinking about this for a while. There are a number of projects using MRTK that are also using the MRTK build tools for their own CI pipelines. These tools are a fantastic resource for these projects, as people won't need to author their own C# command line build for Unity.

However, there are a few problems with the way we currently distribute these build tools.

• Projects that aren't using MRTK, but may want Unity CI builds, need to create their own Unity build tools in order to build via command line.
• If changes are need to these build tools in a specific project, those changes need to be made to MRTK and that project may not get those changes until those changes have been included in a release.

Solution

I think that the MRTK build tools should be moved into their own distinct repo with it's own packaging. This package with build tools can then be consumed by MRTK and any project that may need build tools for Unity.

This isn't the highest priority, and I'm not sure about when we'll have the resources to make these changes, I just want to start a discussion. However, I've implemented build pipelines for a number of projects now using the MRTK build tools and I believe having an authoritative location for Unity build tools with better scope for changes will make the process easier in the long run.

[MenelvagorMilsom]

This is referring mostly to the C# scripts found under \Assets\MRTK\Core\Utilities\BuildAndDeploy but I also think this new package could potentially contain powershell or python scripts to make creating new unity pipelines easier.

[keveleigh]

I like this idea! Though, recently I've been moving away from using these build tools in pipelines, instead favoring a combination of https://github.com/microsoft/unitysetup.powershell and the built-in MSBuild@1 task. I'm using #7554 to track that work for MRTK's pipelines. Have you found any edge cases or special features the MRTK's build tools support that might not be possible with that combination of tooling?

[MenelvagorMilsom]

That would work in the majority of cases, but there are some things that need the MRTK build tools custom command line args in order to build the VS Solution as we want it. Also, when building using unitysetup.powershell, is there some way to build without using -ExecuteMethod? If not, there is still a need for some C# build scripts.

As an example of special features, I think including -debug in the build for some project I was working on was important initially, as the MRTK build tools make some changes to the BuildOptions that were required in order for that project to build.

Another example may be some command line flag that enables the build functionality described in #9444.

I do think we can streamline a lot of what's currently present in the build tools, and we can intend it for use with unitysetup.powershell, but I think it still adds value on its own. I think moving it into its own package and repo will also afford us the freedom to do the streamlining that these tools need.

[IssueSyncBot]

We appreciate your feedback and thank you for reporting this issue.

Microsoft Mixed Reality Toolkit version 2 (MRTK2) is currently in limited support. This means that Microsoft is only fixing high priority security issues. Unfortunately, this issue does not meet the necessary priority and will be closed. If you strongly feel that this issue deserves more attention, please open a new issue and explain why it is important.

Microsoft recommends that all new HoloLens 2 Unity applications use MRTK3 instead of MRTK2.

Please note that MRTK3 was released in August 2023. It features an all-new architecture for developing rich mixed reality experiences and has a minimum requirement of Unity 2021.3 LTS. For more information about MRTK3, please visit https://www.mixedrealitytoolkit.org.

Thank you for your continued support of the Mixed Reality Toolkit!