Error when exporting to .exe

Got another bug when exporting an exe from version 5.0-0765:

Generating project files (this may take up to a few minutes)
VL.Assimp.vl
VL.IO.MidiFileParser.vl
SpaceMusic
Building projects
Unable to build J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\Export\src\SpaceMusic\SpaceMusic.csproj. Reason:
J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\vvvv-binaries\vl_stride_compiled\VL.Stride.Windows\src\VL.Stride.Windows.csproj : error NU1107: Version conflict detected for Microsoft.CodeAnalysis.Workspaces.Common. Install/reference Microsoft.CodeAnalysis.Workspaces.Common 2.9.0 directly to project VL.Stride.Windows to resolve this issue.  [J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\Export\src\SpaceMusic\SpaceMusic.csproj]
J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\vvvv-binaries\vl_stride_compiled\VL.Stride.Windows\src\VL.Stride.Windows.csproj : error NU1107:  VL.Stride.Windows -> Microsoft.CodeAnalysis.Workspaces.MSBuild 2.9.0 -> Microsoft.CodeAnalysis.Workspaces.Common (= 2.9.0)  [J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\Export\src\SpaceMusic\SpaceMusic.csproj]
J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\vvvv-binaries\vl_stride_compiled\VL.Stride.Windows\src\VL.Stride.Windows.csproj : error NU1107:  VL.Stride.Windows -> Microsoft.CodeAnalysis.CSharp.Workspaces 1.0.0 -> Microsoft.CodeAnalysis.Workspaces.Common (= 1.0.0). [J:\Studio JHH Dropbox\JHH SERVER\1_PROJEKTE\120_SpaceMusic\14_SM_GIT\SpaceMusicZH\Export\src\SpaceMusic\SpaceMusic.csproj]

----

Thanks for fixing :)

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.

Thanks.

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, quite possible, although we are also just moving over to StandardLibs. Tebjan asked me to post this here as a bug.

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.

How does the generated Directory.Packages.props file look like in your case? It’s located in the generated src folder of the exported app.

It should contain the following entries:

    <PackageVersion Include="Microsoft.CodeAnalysis.Common" Version="4.4.0" />
    <PackageVersion Include="Microsoft.CodeAnalysis.CSharp.Workspaces" Version="4.4.0" />
    <PackageVersion Include="Microsoft.CodeAnalysis.Workspaces.Common" Version="4.4.0" />
    <PackageVersion Include="Microsoft.CodeAnalysis.Workspaces.MSBuild" Version="4.4.0" />

Also the VL.StandardLibs/VL.Stride.Windows.csproj should reference those versions:
image

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…