I use to have dropbox, but I realize I was getting super long compilation time in vscode and in VVVV, sometimes weird errors, like files unable to be modified / deleted by the compiler itself
It was dropbox itself. Most likely this is not the solution to your problem, but I would recommend to move the project away from dropbox at the compilation time.
Also, are you able to compile just a example patch with the same components on that machine?
@andresc4 Thanks for sharing your experiences with dropbox. We have been using it for a while and it’s never really been a problem. I have exported many .exe files using this setup. So mostly likely something about the new version of vvvv.
Compiling an example patch is a great idea, actually.
Please provide an example patch / example setup showing the problem. It looks to me as if you’re running your own version of VL.Stride which will come with its own challenges because we moved development of VL.Stride to the VL.StandardLibs repository.
Yes, everything is already ported to the latest and the VL.Stride packages are referenced as Source repo. So the reference errors do seem to exist in the latest VL.StrandardLibs repo.
If you checkout VL.StandardLibs, set it as source repo, reference VL.Stride in a patch and export, this error should happen.
Just tried to export a Stride help patch trying to mimic your setup (vvvv.exe + VL.StandardLibs), but running into different cs1704 errors here, which should be considered a different issue alltogether.
Yes, we also came this far now and we also get these CS1704 errors.
I believe this has to do with hard links to specific .dlls that are also loaded implicitly via the temporary obj\Release\VL.Core.dll for example, because the project that produces the linked dll is also part of the solution. But that is just a guess…