Not signed in
Copyright © 2026 Unity Technologies
The current behavior is intended, but the cause and the result are surprising. The reason why it worked in a previous version of the entities package is because of missing error detection which could lead to crashes but which in some cases managed to produce a valid result. If the customer is happy to live with the risk of editor crashes during compilation, it is possible to revert to the previous behavior with a tiny code change described later. Reproduction case public partial struct TestComponent : IComponentData, IVersionHolder { } public partial struct TestSystem : ISystem { public void OnUpdate(ref SystemState state) { state.Dependency = new Job().Schedule(state.Dependency); } partial struct Job : IJobEntity { public TestComponent.Version Version; void Execute(in TestComponent testComponent) { } } } And there is also a source generator in the project that will inject a definition for the embedded Version type inside TestComponent by targeting everything that implements IVersionHolder.. The result is a runtime error thrown from the Schedule method. Why it happens The key element to understanding the behavior is from the official Roslyn source generation documentation from Microsoft: https://github.com/dotnet/roslyn/blob/main/docs/features/source-generators.cookbook.md#proposal “[Source generators] Run un-ordered, each generator will see the same input compilation, with no access to files created by other source generators.” So what’s going on here is that the IJobEntity source generator looks at the code without the results of the other source generators. Which means that the Version type doesn’t exist. The IJobEntity code generator thus detects that the code is malformed and it abandons the process, leaving the exception throwing stub default instead of the proper code generated Schedule method. Why it worked before The IJobEntity source generator used to not check compilation errors in the code before generating additional code. This is invalid usage and potentially leads to crashes. There is no way from the source generator to figure out that the compilation error would go away thanks to another source generator, since they are completely oblivious to each other. The reason why the IJobEntity source generator doesn’t report an error is because it is expected that if the code doesn’t compile it is way more likely that it’s because of a non source generator related issue, and we don’t want to confuse users with an unactionable compilation error next to the actual one they should fix. How to fix it Two options: A - the preferred approach: ensure the source is in a compilable state before and after the source generation. This is the reason why we have stubs for most source generated functions, they will throw if called but they allow compilation to proceed without error. B - the “are you really sure?” approach: embed and modify the entities package source, and remove the following code in Packages/com.unity.entities/Unity.Entities/SourceGenerators/Source~/JobEntityGenerator/JobEntityModule.JobEntityInstanceInfo.cs // check if type is an error symbol if (systemDescription.SemanticModel.GetSymbolInfo... > 0) return false; Option B will jeopardize the stability of the editor.
How to reproduce:
1. Open the “CodegenIssue“ project
2. Open the “OutdoorsScene”
3. Enter the Play Mode
4. Observe the Console window
Expected result: No errors
Actual result: Errors “Exception: System.Exception: This method should have been replaced by source gen.“ and “Missing Profiler.EndSample (Every BeginSample call must have a subsequent EndSample call within the same frame): Default World Code.TestSystem“ shown in the Console window
Reproducible with: 1.3.2 (2022.3.50f1, 6000.0.23f1)
Not reproducible with: 1.3.0-pre.4 (2022.3.50f1, 6000.0.23f1)
Could not test with: 2021.3.44f1 (Entities not supported)
Reproducible on: macOS 14.6.1 (Intel), Windows 10 Pro (22H2)
Not reproducible on: No other environments tested
Notes:
Sign in to see your voted issues