Bevy + dynamic linking

[captainkidd5]

When attempting to use the debugger with bevy with the following dynamic_linking feature enabled:

[dependencies] bevy = { version = "0.11.2", features = ["dynamic_linking"] }

I get these errors:

Any idea how I might fix this? Everything works without dynamic_linking enabled, but the compile time for bevy is crazy

[parthopdas]

happy to look into it. i'll need more details - use screentogif to capture the repro and if possible provide a simplified repro project.

[captainkidd5]

Sure thing, here is the repo: https://github.com/captainkidd5/vs_test

Note that these are the standard recommended Bevy setup settings for debugging as outlined here https://bevyengine.org/learn/book/getting-started/setup/

and the gif:

[parthopdas]

looked into it definitely a bug with r-a.vs as cargo build+run works but r-a.vs doesnt. i'll need another day or so.

[parthopdas]

@captainkidd5 "cargo run" runs the app and i can see the main window.

howevere i am unable to run vs_test.exe from the command line. any idea whats going on?

still investigating the difference between the two.

[parthopdas]

found the problem, CI drop with fix coming up.

[parthopdas]

@captainkidd5 the fix is here, please test it out and let me know https://www.vsixgallery.com/extension/KS.RustAnalyzer.3a91e56b-fb28-4d85-b572-ec964abf8e31/

once you are fine with it i will release it to vs marketplace.

[parthopdas]

@captainkidd5 gentle reminder!

[captainkidd5]

apologies, I'll be at my computer tomorrow and will try it out/get back to you. Thanks for the fix!

[captainkidd5]

Okay so good news is that the fix works for compiling and running the program, awesome!

However there are a few new issues, I am happy to open a new issue here on github but the gist:

1). I was also having this problem before this release, but after attempting to run the program a second time after a full bevy recompile I get the output of "Blocking waiting for file lock on build directory" which never goes away and I'm forced to close all rust processes in the task manager. This forces a complete recompile of bevy which defeats the purpose of the bevy optimizations which normally allow 3-4 second compiles.

2). Bevy specific (afaik) : When using the .net debugger to run the project assets do not seem to be properly copied over to the output directory. Perhaps Bevy is not within a reasonable scope for this extension.

As you can see the program starts, the assets are just not found. They are normally found when using cargo run.

Here is a repo where these issues can be tested

https://github.com/captainkidd5/game_1

I'm actively developing this so please use this commit for reproducing the issues described above:

https://github.com/captainkidd5/game_1/commit/61de015fe7a82dfad17937fe03e603f02a738443

Great job on fixing the dynamic linking part!!

[parthopdas]

for issue 1

This forces a complete recompile of bevy which defeats the purpose of the bevy optimizations which normally allow 3-4 second compiles.

• are you sure about this? it hasn't been my experience while debugging the original issue i.e. incremental builds get done quickly e.g. when launching the debugger.

For the "waiting on the file lock" issue - do you have your test explorer open? if so can you close it and retry as a workaround. this is an issue for sure and is on my radar as one of the top most usability issues. thing is cargo uses this as a sync mechanism. any "smart" ideas how we can bypass this cargo lock?

for issue 2 - from a quick scan of the commit id files, i didnt see any .net project. how have you structured the .net project? if you are using "copy files" do you have the copy whenever newer set in solution explorer? happy to help out on this if you can give me a reduced repro.

[parthopdas]

also as a request it will help out if you do some smoke testing of the other parts of this extension viz. debugger, build, intellisense and if you have unit tests, the testing part. just a smoke test by a 2nd pair of eyes.

[captainkidd5]

Closing the test explorer doesn't seem to be fixing the issue. Still stuck with the same message. As far as testing and ideas on how to fix the syncing issues, unfortunately I'm still extremely new to rust in general so I won't be much help for a while until I get my feet a little more wet. I'm not sure how to even write unit tests in rust quite yet. I also didn't know I need a .net project (.csproj?), I'm just opening a folder with visual studio.

I'm also unsure of how exactly Bevy works with copying assets to the target folder. I'll poke around the Bevy discord a bit.

I'll check back in at some point when I have the ability to really help out. Wish I could be more help!!

[captainkidd5]

https://github.com/bevyengine/bevy/blob/v0.11.0/crates/bevy_asset/src/io/file_asset_io.rs#L67

someone in the bevy discord mentioned that "Bevy won't copy the assets over, instead bevy will look for BEVY_ASSET_ROOT or CARGO_MANIFEST_DIR - the latter is set by Cargo when you cargo run"

[parthopdas]

@captainkidd5 ignore the thing about .net. you do not need .net for this extension. for some reason i thought you were doing .net + rust development.

i'll leave you to investigate the bevy related issue - if there is anything specific you need me to do in the plugin let me know.

for the "blocking waiting for lock file" i may have a fix and should have something for you to test shortly.

[parthopdas]

actually false alarm from my side. no i do not have a good solution for the locking issue. i would recommend you try "cargo vendor" or changing cargo target directories using environment variables to see if it helps. if you do hit up anything, let me know i'll be happy to add it to the product.

for now i'll deploy the dynamic link fix.

[parthopdas]

published to marketplace.