-
-
Notifications
You must be signed in to change notification settings - Fork 957
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AssetCompiler error on multi-project configuration #2244
Comments
Seems like if I add another intermediate project I get a different error. My project I'm working on is pretty big and is actually used with several different front-end solutions. So I created another intermediate project to hold the WPF components to be consumed. In this example the TowerNxt.WPF consumes the Aries3D.WPF project which intern consumes the Aries3D.Core project. In the provided solution attached to this message all projects are set to compile as AnyCPU. The DifferentFolders is how I would want the solution to be organized. But I also attached it where the entire solution is in a single folder to simplify the problem TowerNxt-DifferentFolders.zip Thanks |
When looking at the build output I actually saw this stack trace for the second issue
3> EXEC : error 6.521s: [AssetCompiler] Unhandled exception. Exception: TypeInitializationException: The type initializer for 'Stride.Core.Assets.AssetCloner' threw an exception. |
Thanks for looking into this. I think folder structure was a bit of a mislead. The problem seems to be caused by me introducing a third intermediary project (Aries3D.WPF) and having TowerNxt.WPF reference that project. As a test I forced my output path to match yours like this However I got the same error but now our Output Paths match If there's anything else I can do to help you or anyone else out let me know. |
Debugging this is brutal but I did find out one more thing. Removing the AssetCompiler completely seems to build and then removing the base.Draw() in teapotDemo seems to let it run. I have no clue what this breaks lol but your Teapot demo seems to work as expected. Make sure to clean the poroject after removing. |
@xen2 would you have an easy way of seeing why the error is being thrown? I think I narrowed it down to |
In my case it looks like problem is related to msbuild and version of it, when I Installed ms build and vs 2019 along with 2022 then the command is working, but yes it does need to work with vs 2022 alone. |
The problem is referencing any Stride libraries that involve WPF and a problematic The problem is caused by translation provider
which traces all the way back to this class https://github.com/stride3d/gettextnet/blob/f5f61820ea00b9a2e42570014b73e68b727a23d5/GNU.Gettext/GNU.Gettext/GettextResourceManager.cs#L70 What's happening is the base Here's where things fall apart, in .NET 8 (maybe .NET 6, as well?), the WPF library is treated as a "FrameworkReference" instead of some standard library you could reference. A lot of the above came from me debugging through CompilerApp and this thread dotnet/runtime#13226 The only solution(s) I can think of:
I think (1.) would provide the fastest solution, though would need testing to prove CompilerApp won't touch the TranslationManager EDIT: 1 & 2 doesn't work. There's additional code that touch WPF related objects. |
Release Type: Official Release/GitHub (please choose appropriate option)
Version: Version number and/or git branch
4.2.0.2122
Platform(s): Does the problem occur on Windows, Android...?
Windows/WPF
Describe the bug
I have created a pretty simple solution that contains 2 projects. The main game project and a WPF project. I based both of these off of the examples provided and .
On a fresh repo pull when compiling the solution for x64 only I get the following error message
I then modify the csproj files to compile under AnyCPU everything works. After this I can then switch the projects back to x64 and compile/run with no issues including after full clears of the bin/obj folders.
There was some discussion of this on the Discord starting
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I would have expected the solution to compile under x64 configuration
Screenshots
See above
Log and callstacks
Not possible
Additional context
Can discuss with Simba (@Doprez) and Vašo on discord for additional information.
Thank you.
The text was updated successfully, but these errors were encountered: