Resolved Burst compiler failing to use/compile methods and jobs in pre-built managed dll

This post is equally a "Help Wanted" post as it is a potential bug. The expected behaviour is surprisingly not documented anywhere, but my current setup worked with an older version of burst (1.5.6), but breaks when trying to upgrade to 1.7.0.

High-level goal: Build a managed dll (either externally using visual studio or with Unity) which contains methods and/or jobs that then get burst compiled by a project which uses the dll.

With burst version 1.5.6, I accomplished this by compiling a Unity project that contained the dll's code, and then importing the generated dll into another project. This approach does not work with burst 1.7.0. First, in editor burst spams a bunch of warnings like:

Code (csharp):

1. Compilation was requested for method [...] but it is not a known Burst entry point. This may be because the [BurstCompile] method is defined in a generic class, and the generic class is not instantiated with concrete types anywhere in your code.

Most of the methods that it is failing to find are not generic or contained in a generic type, so I think that is a red herring. Weirdly, the methods appear in the burst inspector, but none of the jobs or methods run bursted.

What is the correct method for creating a managed plugin and ensuring that jobs/methods contained in the plugin get bursted? I'd appreciate any help/insight into this.

 

I see, that is unfortunate. It's nice to be able to provide pre-built managed dlls (whether to other teams within the company, publishing assets on the asset store, etc). It's disappointing that burst now makes this workflow impossible, especially since it used to work and I imagine that there isn't a hard technical limitation which makes this infeasible.

Though it wasn't what I was hoping to hear, I appreciate your quick response and explanation.

 

No to both questions. I did not realize the

AssemblyBuilder

api existed, but I don't fully understand how much it would have changed in terms of final output of the assembly. To give more details:

To get this scenario working with the older version of burst, I tried building with two different approaches:
1) Build externally via Visual Studio. I couldn't get this working, and I thought the reason might have been that the assembly didn't contain the delegates, structs, etc. that burst injects (e.g.

MethodName_00000678$PostfixBurstDelegate

). The issue might have been something else, or there might have been other issue son top of this.
2) Build with Unity which entailed having a Unity project which contained the code that I wanted to be in the dll. Build the project, and then copy the dll from ProjectName_Data\Managed folder. This worked (with the old version of burst).

To actually use the plugin in a project, I would treat it like any other managed dll (i.e. put it in the Assets folder, a Package, etc).

 

Does this mean that precompiled DLLs compiled using Assembly Builder are subject to burst compilation?

 

@sheredom Any ETA on supporting precompiled assemblies?
We are looking into supporting hot reload for burst and this is a hard requirement to make your code changes burst compile on-the-fly.
It works nicely for 2021 LTS but for 2022+ you get warnings that can't be filtered or ignored.
The hot reload still works because the job just falls back to managed code but the warning persists and is annoying.
We want to give our users a seamless experience and right now we have to tell them that there is no way to fix this warning and they have to deal with it and the performance penalty if they want to hot reload their burst jobs.
More info on our tool here: https://hotreload.net/

 

Whenever I hot reload a job I get this warning.

Example Video Here

Warning:

The type in question is not generic but is defined in a precompiled assembly

Unity version: 2022.2.4f1
Burst package version: 1.8.2

Just for reference: Quiet some people that use our package asked for support to hot reload burst compiled code and many more have mentioned that they would only start using it if we support burst. I spent significant amount of man hours to make this work. In the end we were even considering to not release it like this because a warning every time you make code changes to jobs is below the quality bar that we set for our product.

 

Just came across this thread as we have updated to 2022 LTS, ECS 1.0, and noticed that our pre-compiled jobs are not being Burst compiled, so I wanted to make sure our use case is heard as well. We do not use AssemblyBuilder or PluginImporter. We use pre-compiled DLLs for a number of reasons. We have shared libraries that we do not want developers modifying, internally. Using DLLs forces changes in these libraries to go through proper channels. Second, we wish to keep projects that we develop open for client modification without freely exposing/sharing our IP.

Are there any (even unsupported) workarounds?