Why export fails with library using static enum made with newer version of Gamma?

maximesouvestre · January 19, 2026, 12:15pm

Heyo!

Ok, let me try to explain more clearly what is happening, as the title might be a bit blurry.

I developed new nodes for VL.Devices.Phidgets, and I had to create a StaticEnum for one of them.
I followed the article from the gray book to do so, but I did it with Gamma 7.1.0144.

Phlegma released a new nuget version of the library a few days ago.
Now, when I try to export my app, made with Gamma 7.0 and using the latest nuget (0.1.1), I get this error:

Unable to build D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj. Reason:
Determining projects to restore…
D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\VL.Devices.Phidgets.vl\VL.Devices.Phidgets.vl.csproj : warning NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping ( Package Source Mapping | Microsoft Learn ) or specify a single package source. The following sources are defined: vvvv-public-feed, nuget.org [D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj]
D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj : warning NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping ( Package Source Mapping | Microsoft Learn ) or specify a single package source. The following sources are defined: vvvv-public-feed, nuget.org
D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj : error NU1109: Detected package downgrade: Stride.Core.Mathematics from 4.2.1.2487 to centrally defined 4.2.0.2293. Update the centrally managed package version to a higher version.
D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj : error NU1109: 260119_Phidgets_Manager → VL.App.Console 2025.7.0 → VL.AppServices 2025.7.0 → VL.Core 2025.7.1-0144-g5b48859314 → Stride.Core.Mathematics (>= 4.2.1.2487)
D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj : error NU1109: 260119_Phidgets_Manager → Stride.Core.Mathematics (>= 4.2.0.2293)
Restored D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\VL.Devices.Phidgets.vl\VL.Devices.Phidgets.vl.csproj (in 1.16 sec).
Failed to restore D:\Documents\vvvv\gamma\Exports\Phidgets_Debug\src\260119_Phidgets_Manager\260119_Phidgets_Manager.csproj (in 1.25 sec).
1 of 3 projects are up-to-date for restore.

There was a problem exporting your Application.
Please check for solutions by clicking the “Troubleshooting” button.

From what I understand, there is a conflict with 2 versions of the same library being referenced, and I can tell it is coming from VL.Devices.Phidgets because the error only comes when I add this nuget to my patch and export.

When I open the c# project file of my StaticEnum, I can see this that VL.Core is referenced with version 2025.7.1-0144-g5b48859314. And VL.Core in my patch is referenced with version 2025.7.0. If I edit the version of VL.Core of VL.Devices.Phidgets.Utils to 2025.7.0, my export works again correctly.

Something I don’t understand though is that when I open my patch with Gamma 7.1.0137, the version of VL.Core in the StaticEnum switches automatically from 2025.7.1-0144-g5b48859314 to 2025.7.1-0137-g9913e5c752. And obviously, the export works in that case because both version of VL.Core are identical.

So, why with Gamma 7.0 this process is not done automatically too? Should we do something specifically in the c# project of the StaticEnum of VL.Devices.Phidgets to avoid this issue? It would be nice that everyone could use the library and export their app without dealing with VL.Core version issues. Also happening with Gamma 6.7.

If you want to try on your own, here are the steps:

Open Gamma 7.0
Add nuget VL.Devices.Phidgets (nuget install vl.devices.phidgets) but do not reference it yet in your patch. It should be version 0.1.1.
Navigate to C:\Users\username\AppData\Local\vvvv\gamma\nugets\VL.Devices.Phidgets.0.1.1\csharp\VL.Devices.Phidgets.Utils
Open .csproj file with VS Studio
Open VL.Devices.Phidgets.Utils from Solution Explorer
Check VL.Core version (2025.7.1.0144
Reference VL.Devices.Phidgets in your patch. You can see the version of VL.Core in VS Studio stays at 2025.7.1-0144-g5b48859314
Make this simple patch:

image979×686 8.35 KB
Export. It will fail with the same error message pasted above.
Repeat process but with Gamma 7.1 preview (ideally not 0144 as it is already the version of VL.Core for VL.Devices.Phidgets.Utils). You will see that on step 7, the version of VL.Core in VS Studio will automatically switch to the version of Gamma 7.1.xxxx you are using.

I just want everyone to be able to export their app when they are using the library. I just don’t know if I did something wrong, or if I am missing something somewhere.

Thanks for reading !

joreg · January 19, 2026, 1:38pm

hey maxime,

the problem is with how you deployed the nuget: it contains the c# code, which it shouldn’t. instead if must contain the built .dll!

so what you’re missing is 2 things:

first in the github action it needs a line that includes a build task for your .csproj. compare with the template that shows that: VL.NewLibrary.Template/.github/workflows/main.yml at e47cf3d56fafd169ea6f4c084ea6629e84fedd82 · vvvv/VL.NewLibrary.Template · GitHub
then in the .nuspec you need to include the \lib folder, see: VL.NewLibrary.Template/deployment/VL.NewLibrary.Template.nuspec at e47cf3d56fafd169ea6f4c084ea6629e84fedd82 · vvvv/VL.NewLibrary.Template · GitHub

but also you’ll have to make sure that:

the .dll your .csproj is building is being built to the packs root\lib folder
that your .vl document references this built .dll and no longer the .csproj

bjoern · January 19, 2026, 1:43pm

I think this needs to be directed at @phlegma.

maximesouvestre · January 19, 2026, 1:56pm

Ah alright !

So we are doing something wrong right now.

Great, thanks for the links and explanations. I will check this and make sure we have everything correctly set to publish a new version of the nuget soon!

@bjoern We discussed with @phlegma last week, and I now have access to the main repo too. So I can also check and change the process if he doesn’t have the time ;) But you are right, good he is also mentioned in the thread !

maximesouvestre · January 27, 2026, 4:28pm

We still have issue regarding this topic after your explanations @joreg .

This link and this one clearly reference the .csproj into a /src folder.
When you create a new enum within vvvv with the quad menu, you instead get a /csharp folder.
Is it important for it to be called src or can we stick with what vvvv creates by default and reference the path to csproj in the GitHub action as follow:

name: Publish VL Nuget
uses: vvvv/PublishVLNuget@1.0.43
with:
csproj: csharp\myProjectFolder\myEnum.csproj
…
When we build our csproj containing our custom enum, it ends up into /lib/Release/net8.0, but when I compare that to other nuget, I see that dlls goes into /lib/net8.0.
Could this be an issue even if the reference in the VL file is correct?

When exporting this simple app with latest nuget version, I still get this error so far:

antokhio · January 27, 2026, 7:42pm

Ok let’s start with a bit broader explanation on a pipeline so you have some idea what’s going on:

So, normally nuget assumed to be build by an github actions. What action does, it starts an windows instance, clones repository, runs build, runs pack, runs publish.

So if we know this let’s now expand this:

So system clones repository (nothing fancy)
System should build project (u can test that with):

// example build command for avalonia
dotnet build .\VL.Avalonia\src\VL.Avalonia.csproj --configuration Release --output .\VL.Avalonia\lib\net8.0\

Next is nuget pack command, if you check avalonia .nuspec you can see:

<?xml version="1.0"?>
<package xmlns="http://schemas.microsoft.com/packaging/2011/10/nuspec.xsd">
  <metadata>
    <id>VL.Avalonia</id>
    <title>VL.Avalonia</title>
     ....
  <files>
    <file src="..\VL.Avalonia\lib\net8.0\**" target="lib\net8.0\" exclude="" /> // path to dll 
    <file src="..\VL.Avalonia\*.vl" target="" exclude="" /> // path to .vl 
    <file src="..\VL.Avalonia\help\**" target="help\" exclude="" />  //path to help files
    <file src="..\VL.Avalonia\assets\**" target="assets\" exclude="" />
    <file src="..\icon.png" target="icon\" />
    <file src="..\README.md" />
    <file src="..\LICENSE" />
  </files>
</package>

You can test .nuspec this command by running:

 nuget pack .nuget\VL.Avalonia.nuspec -Version "0.0.0" -OutputDirectory .\packages

Notice u need to add path to nuget.exe to system variables
Assembled .nuspec you can extract with win rar or other archive manager, to see that your dll are correct.

Publish process i would not cover u can check some of my VL repos, to see more examples.

So correct nuget should be:

help   // optional 
lib    // should have dll's
VL.Yorpackage.vl
README.md // optional
LICENSE // optional

also nuspec should include dependencies (like other nuget packages this one depends on)

Refernces:

antokhio · January 27, 2026, 8:17pm

Few side notes:

your help patches should depend on VL.Package not dll.
to make you dll avalible in patches other then VL.Package it should be forwarded in VL.Package.vl

phlegma · January 27, 2026, 10:00pm

I just had a moment to look at this. It should be fixed now. New release is up

joreg · January 28, 2026, 9:00am

@phlegma great to hear you got it working

@maximesouvestre just a quick note:

the folder name is not important.