Linux FAQ

[Noggog]

Braindump discussion hub on information trying to get Synthesis to run on Linux

[UplinkPhobia]

For those having an issue with the UI flickering and becoming partly black such as

The basic step that solved it for me was to disable DXVK (Running through MO2 under Lutris with 7.x ProtonGE version).

According to the DXVK documentation and doitsujin/dxvk#2568, you can create a dxvk.conf file containing

[Synthesis.exe]
d3d9.shaderModel = 1

To make sure that Lutris uses the config file, add an environment variable (System options tab in Lutris) called DXVK_CONFIG_FILE and set the value to the path of the dxvk.conf file.
In my case, that was enough to make things work.

(Just for the reference, I used this reddit guide to setup my MO2 and such, which might or might not have an impact. Mainly the fact that the default MO2 installer in Lutris uses a 5.x wine version.
I also have dotnet installed in my wine prefix, and not wine-mono, but I had issues with both so I can just say that wine-mono didn't resolve the problem. I don't know if this solution is valid only with dotnet, or with mono as well.

As for the explanation, it seems like .NET applications have this bug with DXVK. The same method resolved the issue with other tools that were apparently also made with .NET)

[Snogard]

i have a method of running mo2 with the steam runtime (cloud saves, achievements, and nxm links work). i can post my scripts if you are interested.

[har-nick]

If you're having issues with Synthesis not finding the dotnet SDK while running through SteamTinkerLaunch, try running the dotnet sdk install through STL's One Time Run feature. I previously tried manually installing through wine, and while it installed correctly, it wasn't detected by Synthesis.

[Snogard]

Just go in the settings and put the dotnet path manually and restart Synthesis

[Nuanulla]

What's the exact dotnet path I should put in settings?

[Snogard]

You can check inside your wine prefix. mine is:
C:Program Files\dotnet\dotnet.exe

[Snogard]

I got as far as installing a synthetizer but i have this errors.

SustainedSpellsPatcher.csproj : error NU3037: Package 'System.Security.Principal.Windows 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3037: Package 'System.Security.AccessControl 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3028: Package 'System.Security.Principal.Windows 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3037: Package 'Microsoft.Win32.SystemEvents 4.7.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3037: Package 'Microsoft.NETCore.Platforms 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3028: Package 'Microsoft.Win32.SystemEvents 4.7.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3028: Package 'System.Security.AccessControl 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3028: Package 'Microsoft.NETCore.Platforms 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3037: Package 'System.Security.Principal.Windows 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3037: Package 'System.Security.AccessControl 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3028: Package 'System.Security.Principal.Windows 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3028: Package 'System.Security.AccessControl 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3037: Package 'Microsoft.NETCore.Platforms 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature validity period has expired.
SustainedSpellsPatcher.csproj : error NU3028: Package 'Microsoft.NETCore.Platforms 5.0.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamping certificate is not trusted by the trust provider.
SustainedSpellsPatcher.csproj : error NU3037: Package 'Microsoft.Win32.SystemEvents 4.7.0' from source 'https://api.nuget.org/v3/index.json': The repository countersignature validity period has expired.

is there a way to turn of the signature verification? or is this working fine on the windows side?

Synth file from -> https://github.com/ExpensiveLadder/SustainedSpellsPatcher

[Noggog]

is this working fine on the windows side?

Seems to work for me:

I've never seen this error before. Feels like it's something related to non-windows. https://stackoverflow.com/questions/65919460/the-author-primary-signatures-timestamp-found-a-chain-building-issue-untrusted
Don't know too much about getting this all spun up on linux to give too much more advice

[Snogard]

thank you for testing it on windows, if i find a solution i'll report back

[gibsonjareds]

I just recently ran into this problem when I was forced to rebuild my prefix. I think it’s related to outdated certificates inside of wine’s fake environment. I still don’t know for sure how to update those. If you look in the everything log, it shows that the signatures/certificate validity expired in 2021 (if yours is like mine).

[gibsonjareds]

I've successfully run a few patchers locally. I had to switch to using Proton 7.0 (no GE or tkg). This required using Dotnet SDK 6.0.411 as for some reason dotnet 7.0+ don't seem to be able to run in that version of proton. I was able to launch, and the package verification succeeded. After that, I was able to install the recommended 7.0.201 SDK and run the patcher under Proton 8.11 tkg.

It's either the patches by TKG or GE or the version of dotnet that aren't working, I think.

[Cubeson]

I got as far as installing a synthetizer but i have this errors.

SustainedSpellsPatcher.csproj : error NU3037: Package 'System.Security.Principal.Windows 5.0.0' from source 'https://api.nuget.org/v3/index.json': The author primary signature validity period has expired.
(...)

I am having the same problem, I wonder if it has something to do with me having installed Dotnet 7 for linux already.
I ran prefix dotnet.exe --info with proton and I got this:

STEAM_COMPAT_CLIENT_INSTALL_PATH=/usr/games/steam STEAM_COMPAT_DATA_PATH=~/.steam/debian-installation/steamapps/compatdata/489830/ ~/.steam/root/compatibilitytools.d/GE-Proton8-6/proton run dotnet.exe --info
.NET SDK:
 Version:   7.0.306
 Commit:    f500069cb7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19043
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.306\

Host:
  Version:      7.0.9
  Architecture: x64
  Commit:       8e9a17b221

.NET SDKs installed:
  7.0.306 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.AspNe
tCore.App]
  Microsoft.NETCore.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.
App]
  Microsoft.WindowsDesktop.App 7.0.9 [C:\Program Files\dotnet\shared\Microsoft.W
indowsDesktop.App]

Other architectures found:
  None

Environment variables:
  DOTNET_ROOT       [/usr/lib/dotnet]

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

interesting enviroment variable...

[ErikSteiner]

Hello guys, I was able to run 0.25.4 with GE-Proton8-16. I follow the guide Lexy’s Legacy of the Dragonborn: Special Edition, where it was required to build two files with several patches.

Up to this point, I used proton-8.0 or GE-Proton8-9.

The problem was that Synthesis either closed immediately after starting, or the red lights did not disappear completely or only partially. Partially, I could start Synthesis several times and always the same patches remained red. With the latest GE version, the probability is significantly higher that all red and purple lamps disappear and I can apply the patches. I say probability on purpose, because still sometimes Synthesis exits directly after the start, or the red lamps do not disappear completely with the patches.

I have installed .NET both as runtime and as SDK in version 7.0.11.sdk111-1. At least, I can start Synthesis, and it notices that the runtime is installed. It then tells me that the SDK has to be installed as well. Interestingly, it does not register the installation of the SDK on Linux. So I have to install the SDK in the prefix, while the runtime can be used from Linux.

Thanks to Steam Tinker Launch I can quite easily enable logging with traces. However, I lack the understanding to be able to derive anything from it. I suspect that something is not implemented in proton/wine.

[Stigir]

I'll chime in for people having .net SDK issues on launch.

The Linux versions of .net install "properly" for me, but Synthesis couldn't find them. So I used Wine to install the Windows version of .net, and that worked for me. It even prompted me to point it specifically at my game.

Then just add the .net directory to the settings tab of Synthesis, as suggested above:
C:Program Files\dotnet\dotnet.exe
(It could also be in Program Files (x86), pending on which .net you installed).

I also had the nuget issue after that, but it fixed itself after re-opening MO2 a couple of times.

[monyarm]

Well, I have the black screen and the suggestion here didn't help. Anyone else have any ideas?

[studioph]

I've been experimenting a ton with Bottles in hopes of creating a stable, reproducible environment to run Synthesis in so that everyone doesn't have to keep troubleshooting the same things. However, I've had almost the opposite experience of others in this thread and found Synthesis to be the most finicky piece of software I've ever tried to run in wine...maybe it's bottles? maybe it's me? I'm running Ubuntu 22.04 so I'd be shocked if it was the Linux host...

Some of my own notes (which don't seem to align with others' experience above but putting them down nonetheless in case it helps others):

• kron4ek seems to be the most stable/compatible, specifically staging or staging-tkg. Trying to use the non-staging version of kron4ek triggers a wine crash dialog on startup
  • Still get the stupid nuget error when adding a patcher, closing and reopening usually changes the package, hoping means it makes progress, but after a couple of times it gets stuck on one package
• Unable to get Synthesis to startup with any version of GE Proton I've tried (including several versions of 9 and 8), not even a wine error dialog like above
• Using DXVK seems to cause crashes when hovering over the buttons in the top left (group, git, local, etc)
• Caffe and soda are also equally useless

My process for creating the bottles (which I've scripted and am thinking of posting a gist or something) is as follows:

• Create the bottle (custom, , win64)
• Install the dotnet 7 SDK downloaded from MS using "Run executable" (never had SDK install issues FWIW)
• Unzip Synthesis (using the latest 0.27 release) into C:\Program Files\Synthesis
• Add Synthesis.exe to the bottle as a program
• Run Synthesis
• ???
• Profit?

Overall, I've been trying to go about this methodically in hopes it would yield better results but I'll be honest, it's been trying my patience...very close to making a Windows VM just for this, though that poses its own challenges.

I'd love to pool heads with people and see if we can't nail down a reliable, reproducible way to run on Linux

[farelmapm]

• Unable to get Synthesis to startup with any version of GE Proton I've tried (including several versions of 9 and 8), not even a wine error dialog like above

I'm having this issue right now but it seems like no one else have this problem? Synthesis won't start if I run it with a proton prefix, which means I can't run it through my MO2 (Because I'm using the MO2 Linux Installer). I got an error stack of the crash, but I'm not a .NET developer so reading this is beyond me

Output of wine Synthesis.exe (runs as normal): https://gist.github.com/farelmapm/48abd2238f902ac671a228b4c4ff030e
Output of protontricks-launch -vv --appid 489830 Synthesis.exe: https://gist.github.com/farelmapm/feb5c84417effd0201b2a1b012581138

[Kataiser9]

• Unable to get Synthesis to startup with any version of GE Proton I've tried (including several versions of 9 and 8), not even a wine error dialog like above

I'm having this issue right now but it seems like no one else have this problem? Synthesis won't start if I run it with a proton prefix, which means I can't run it through my MO2 (Because I'm using the MO2 Linux Installer). I got an error stack of the crash, but I'm not a .NET developer so reading this is beyond me

Output of wine Synthesis.exe (runs as normal): https://gist.github.com/farelmapm/48abd2238f902ac671a228b4c4ff030e Output of protontricks-launch -vv --appid 489830 Synthesis.exe: https://gist.github.com/farelmapm/feb5c84417effd0201b2a1b012581138

I'm quite late here, but have you tried multiple different proton versions? Shot in the dark, but I had been running a specific custom build of Proton (Ceepu-Proton9-1) and had pretty much the exact same error message as you. Eventually tried using mainline Proton 9.0 and it worked fine.

(Not helpful for OP here presumably, due to "(including several versions of 9 and 8)", but since I had the same error as in the reply, thought it might be worth mentioning.)

[farelmapm]

I'm quite late here, but have you tried multiple different proton versions? Shot in the dark, but I had been running a specific custom build of Proton (Ceepu-Proton9-1) and had pretty much the exact same error message as you. Eventually tried using mainline Proton 9.0 and it worked fine.

Thank you, but I eventually got it running (which by "running" I meant opening without crashing, I still had other issues that I eventually gave up on) if I remember correctly by pretty much messing around with different prefixes. I think at some point I tried creating a clean Proton prefix for Skyrim (after backing up my original prefix first) and then manually installed .NET 8/9 instead of through Wineprefix menu installation and eventually something fixed it. For anyone still having this issue sorry I can't give any detailed instructions because I'm not sure myself what actually fixed it and I couldn't get it to actually work anyway. But I think the general idea is to mess around with your prefixes and/or Proton versions.

[junip0r]

error NU3037: Package '...' from source 'https://api.nuget.org/v3/index.json': The repository countersignature validity period has expired.
error NU3028: Package '...' from source 'https://api.nuget.org/v3/index.json': The repository countersignature's timestamping certificate is not trusted by the trust provider.

The solution that worked for me on Arch Linux:

• Download the Verisign Universal Root Certificate:

wget https://cacerts.digicert.com/universal-root.crt.pem

• Add the certificate to the system:

sudo trust anchor --store universal-root.crt.pem

[studioph]

Thanks for sharing this! I finally came back to Synthesis after a hiatus and was still struggling with the nuget issue. Before I saw this though I symlinked the .net/nuget downloads folder to my linux home and just ran dotnet restore from linux, which had no issues, thus when I opened synthesis it didn't need to download anything so no issues.

[zachboatwright]

This worked for me also! I'm on Kubuntu so I just had to modify what you said with the instructions specific to Debian here.

[katzmannr]

This worked for me as well. Such a simple trick. Just be aware that you switch into the "Runner" folder in users\steamusers\Temp\Synthesis......\Runner ("..." are random cryptic foldernames).

[katzmannr]

A word of warning here: The mentioned certificate was removed from Ubuntu / Debian already in 2021 due to security concerns. It is still used for nuget 6.0 package dependencies, so poses a potential security risk. The package is part of mutagen itself. On Linux dotnet comes with that certificate, but is only used for this specific use case.

[ingenarel]

long story short to run this:

• use lutris (if you know how to automate most stuff without using lutris then go ahead)
• use proton-GE (mandatory)
• download the latest .net sdk from microsoft
• run and install it
• run synthesis
• profit

i wrote out a long guide a few minutes ago, but accidentally closed the browser, so here's the short version 😭

[Older0ne]

A detailed guide would be greatly appreciated. I still can't get it to work even though I have dotnet SDK on my system, I even have it installed with a windows exe through wine (idk where to though), but the error "can't start 'dotnet' process. File not found" persists. Both lutris and no lutris MO2 gives the error.

[ingenarel]

@Older0ne are you using proton-GE or wine?

[Older0ne]

@Older0ne are you using proton-GE or wine?

I tried it with both normal Proton and Proton GE

[ingenarel]

@Older0ne do you use different wine prefixes or do you use the default prefix?
i use $HOME/.wine aka the default prefix for my games, and i also installed dotnet in the same prefix
also what happens when you do dotnet --version?

it should give something like this

[Older0ne]

@ingenarel I use the default prefix generated when you open the game through steam (when installing MO2 it tells you to use that). When I do the command it does tell me the dotnet version, for me it's 9.0.103. The crux of my problem could be that I don't know what "install dotnet in the prefix" means, I installed dotnet through terminal with instructions from their website, as I said I also used the windows installer with wine but idk where to it installs. How do I install it in the prefix?

[katzmannr]

Since quite a lot has changed on the Microsoft side regarding signing, I will continue here.
This topic is very complex and even touches the law deeply.

Summary: Use nuget at your own risk. What is currently done to duct tape the whole system is plainly illegal. We just this once look past it since we need to keep our old packages working.

Ok, no the details, why this breaks on Linux:

We have a nuget.config. I do not know how this file is generated, but I found out that it was not updated with the latest dotnet sdks (8.0.x, 9.0.x). I found an article how to update to trusted signers. Basically you download "nuget.exe" and force an signer update of nuget.org. Done.

Next you will find that package downloading fails with NU3037. Honestly, I do not know if it is the repository, the package or something else. This patcher is extremely important to keep Skyrim running, so far I have not found other ways. Skypatcher could be a solution on the long run.

Here the error is described in detail:
https://learn.microsoft.com/en-us/nuget/reference/errors-and-warnings/nu3037
This is the wine story of it (probably incomplete):
https://forum.winehq.org/viewtopic.php?p=147948

The patcher github page:
https://github.com/Wolfman5750/Z-Floor-Patcher

So this Patcher is a bit older and probably by itself could cause NU3037 even on Windows.
But obviously it works on Windows. Why ? Because of a certificate bundle with old certificates.

NuGet/Home#13252

Basically they workaround the problem that the source (!) package certificate is invalid.
Normally this problem is solved in two ways:

1. (Preferred) Old source packages are updated to the new certificates if the old one gets invalid.
   "It's your repositories, your certificates, you are responsible for it." -> Github Owners
   To be fair, the repository maintainers could be asked about this (automatic) step should there be a reason not to automatically update.

2. (Dangerous) The user is asked to agree to (invalid) source package and ignore the error.
   Alternatively the user could download the patcher from github and add it manually to synthesis (if this actually removes the signature check, I have not done it)

Instead now they say that the old certificates are "needed" since the old code was signed with those certificates. Lazy way and the user (as in 1) does not know what is going on.

At least solution 1) makes sure that as soon as new certificates are valid, the old packages get updated. A more secure solution would be to not allow use of the package until the repository owner has updated them.

This is what happens on Linux: Since it does not use the signature bundle (and maybe has an encryption issue as well), the old source packages are invalid.

[Noggog]

So, to summarize:
Patchers reference libraries, which they download as nuget packages when being built. Over time as stable patchers get older, those referenced nuget packages have certificates that are signed with a "expires by" date, and that date passes by.

The two options to address this are to either

• Update the patcher to point to the latest library versions, whose nuget packages would presumedly have fresh signatures
• Just download them from nuget.org anyway

---

In general, it'd be the github owners responsibility to keep their setups up to date, I'd imagine. However, in the real world as it relates to modding, we all know modders come and go. They get involved for a year or two and then drop off the face of the earth.

It's all open source, so the community at large can help with this even when the original author isn't as interested. You could open up a PR for Z-Floor-Patcher to update it to latest pretty quick if it's important to you (which I just did since I was in the area).

Additionally, this initiative is meant to house projects that authors know they wont be interested in long term as they move on to other things, or just want it to be more of a community patcher overall. We could probably add some automation to the organization to do some of these nuget updates. Let me know if you'd like to get involved with that!

[xDieymirx]

Figured it out, it now works when you follow my steps to be able to install Synthesis on Linux.

first, you need MO2 installed, (Use the furglitch installer, and if you run into a issue with cabextract/xact just type in while installing the prefix: protontricks 489830 xact), to fix it before you press continue after closing the game), and you will add Synthesis.exe as a executable, and then close Mo2, open up protontricks, pick the appid with 489830, then go to Download DLLS:

Net 9 Runtime & Core
Net 8 Runtime & Core
d3dcompiler_47
visual studio 2015-2019 or 2022 (idk)

Then, search up Net 9 SDK, and Nuget.org, install those two exes, and then instead, press the run an arbritary executable, and install both those. Bam, it works.

[katzmannr]

Today I gave it another go (clean) with Synthesis 3.5 and 3.5.3.
3.5: Everything I tested failed.

• Signature error on the old repository, no way to fix
• Downloaded and build Z-Floor Patcher manually: Worked, exe can be run
• Added Precompiled Exe in Synthesis: Error about wrong Path (Z-Floor-Patcher without ".exe") or "Could not find target CLI file" - environment variable not found
• Tried to open local solution: Worked, but there was no way to go "back", the only log entry is "Getting available projects from ..."

Installed both dotnet 9 core and runtime
replaced nuget.exe with the one downloadable from nuget.org (worked from commandline)
For normal project I get "primary signature error" which is the issue I cannot resolve since Synthesis does not offer a solution.

Everything.txt

Edit: Found out that for some reason exe was not build for win platform.
-> With the correct build settings I can run the exe and finally use Synthesis like this. Big progress!

Will try 3.5.3 later.

[Noggog]

Thanks for the tests!

Signature error on the old repository, no way to fix

This seems to be related to linux complaining when pulling in old nuget packages. For example, your setup is complaining:
error NU3037: Paket "Mutagen.Bethesda.Core 0.37.0" aus Quelle "https://api.nuget.org/v3/index.json": The validity period of the repository's primary signature has expired.
Mutagen.Bethesda.Core 0.37.0 is a package from 2022, and im guessing whatever signature was used to sign that package has expired since then (im not an expert on signing mechanisms). It seems like the windows setup goes along and downloads it anyways, while linux throws a fit.

If you're building it fine on the side with your own downloaded nuget.exe, perhaps somehow that program doesn't care about the signatures? Synthesis, when it does its normal operations, uses dotnet build, dotnet restore, etc, and im guessing that hooks into the "normal" nuget suite which apparently cares more about the expired signatures?

A few options:

• Upgrade your patchers to use latest versions instead of ones from 2022
• Figure out how to instruct your linux system to download them anyway (not sure what goes into that)

Added Precompiled Exe in Synthesis: Error about wrong Path (Z-Floor-Patcher without ".exe") or "Could not find target CLI file" - environment variable not found

I can perhaps help and fix this. I was going to suggest one route is you build all the patchers yourself, and just use synthesis to run the pipeline or change settings. You said that threw an error for you?

[61.0][Z-FloorPatcher][Skyrim Special Edition] Error while running: System.IO.FileNotFoundException: Could not find target CLI file: D:\Modding\tools\Z-Floor-Patcher-main\ZFloorPatcher\bin\Release\net6.0\Z-FloorPatcher.exe
 ---> System.ComponentModel.Win32Exception (203): An error occurred trying to start process 'D:\Modding\tools\Z-Floor-Patcher-main\ZFloorPatcher\bin\Release\net6.0\Z-FloorPatcher.exe' with working directory 'D:\Modding\tools\Z-Floor-Patcher-main\ZFloorPatcher\bin\Release\net6.0'. 
Environment variable not found.

One idea i had might be that the exe wasn't marked to be executable? I know in linux you have to mark files explicitly as executable in permissions before things are runnable. Not sure if that's applicable when using WINE or whatever tricks you're running things through. I'm guessing that path exists?

Tried to open local solution: Worked, but there was no way to go "back",

As in the UI didn't have any back button? Have a picture of this? Either way, i dont think this route will work any better than the git one. It'll still want to pull in nuget packages and all that just the same. (Git patcher is just a solution patcher that downloads the files for you from github)

Found out that for some reason exe was not build for win platform.

What exe are you talking about? The UI, im guessing? I do believe the UI is built for windows. The TargetPlatformIdentifier is Windows and it runs fine on an actual Windows install (as most users are doing this).

---

Another route to try is the CLI initiative. This would be an exe built for native linux, and so would hopefully avoid some of the headaches? Another thing to try that I'd be willing to help upgrade with more features as needed. Only thing I think it wouldnt be able to do well is the settings UIs that some patchers offer.

[katzmannr]

I deleted the comment, it was absolutely Chaotic.

Step 1: Signature handling is more strict than on Windows as I know (discussed above). Should work with updated repository (this is what the error says. Since I have the latest nuget, that is the only conclusion I do have.) Will check tomorrow when I am less tired.

Step 2: Local Solution: I am not sure what goes wrong here. What I did:

• Local Solution -> Existing Solution
• Load Solution
• Give Patcher a Name.

I could only press the confirm "button" when the Executable was added to a different group. In all other cases the confirm "button" was darker and not pressable. But in that case it showed that the name is wrong. The confirm "button" went dark afterwards.

When the group with the Executable was not present I never got a working confirm "button. I restarted too to check if anything changes.

Step 3: Executable: Works, but only for Z-Floor or other more simple patchers.
For "Engarde_Synthesis" it does not work. the internal patcher program that runs the executable throws an error that the config.json is not found.

The config.json is there, it is even in 4 places: Data folder, synthesis Data folder and two times in the Temp Synthesis folder.

My guess is that the the config folder needs to be specified for the call of the executable. But I cannot change anything on the patcher call.

I barely know C#, so I do not know if the code can be changed to
a) Do not throw error when config file is not found (or handle that properly)
b) Load the config file from default place like "Data"
c) Get config path from external file.

`
string configFile = File.ReadAllText(state.RetrieveConfigFile("config.json"));

var config = JsonConvert.DeserializeObject(configFile, new JsonSerializerSettings
{
NullValueHandling = NullValueHandling.Ignore
})!;

`

No difference between 0.35.0 and 0.35.3.

01-01-2026_22h54m52s.log

[Noggog]

I deleted the comment, it was absolutely Chaotic.

Yes, creating a fork and upgrading the patchers there would be an alternative option.

Haha no worries. I did catch this quote, though ^.
To be clear, you do NOT need to fork and upgrade patchers to do what I'm saying. For ex, I'm running Z-Floor-Patcher on latest here, without needing to actually fork anything. This is what git patchers do and are for. You instruct them to use a repo's code, but with the latest versions of the mutagen library, and it downloads the patcher, swaps out the versions, and builds it locally. This was set up specifically to let users upgrade patchers to use latest versions, even if the original author is MIA. You only need to fork if there ends up being backwards incompatible API changes, which for ZFloor is not true, so it's good to go.

I understand the mechanics might not work well on linux out of the box. But that's the idea, and what the "normal" windows user is doing during normal usage.

What I'm saying is that you can also do this (either through the UI like in that picture, or by editing the PipelineSettings.json directly), so that your ZFloorPatcher is targeting 0.52.0/0.35.3 directly, like my picture. Then synthesis will be downloading more recent packages that hopefully wont hit the signature expired bug. (and will also have all the mutagen bugfixes from the latest versions)

Local Solution: I am not sure what goes wrong here.

Solution Patcher UI are definitely less polished than the git patcher, which is 98% of the usage. One UX annoyance I know exists is that the setup wants you to select the Patcher Project to use. If a solution had a few projects within it, the setup wants to know which csproj to build and run as the patcher. Most have only 1, so the choice is obvious. But the UI sometimes doesn't select it, and that's what blocks the "accept" button. You need to click the Patcher Projects area so the single entry is "selected"

That should let you add it. Still, I don't think utilizing the Solution Patcher will fix any of your issues. My suggestions are still:

• use the Git Patcher + upgrade to latest libraries
• use the Git Patcher + tell linux to STFU about signature expirations
• Compile exe on the side and use CLI patcher. (maybe we need to fix some pathing bugs for you, which i can help with)

Executable: Works, but only for Z-Floor or other more simple patchers... throws an error that the config.json is not found. The config.json is there

This makes some sense. When building on the side you are making an exe. You can run it. Okay. But there needs to be some more prep.

Patchers also have a few other concepts like Internal Data, or settings files that the settings UI output. These need to be in the right location for the exe to find. The Git patcher handles this, but a scratch built exe you made might not.

Few questions:

1. You say you have a config.json. But this is generated via the settings within github patcher synthesis UI

If you got to the stage that you could use this and make a config.json from it.. then you've overcome the hurdles we're discussing, and should be able to just run it without worrying about CLI patchers.

2. If you somehow got a config.json elsewhere and are running via CLI patcher and it's complaining it can't find it.. do the paths match? Im guessing it's looking for the config.json in a different path than where you are storing it. The CLI parameters don't expose the parameters to customize the location for all these internal files. It expects them to be in the spot it expects (which the git/solution patchers handle).

---

TLDR: Have you tried my versioning recommendation yet? It should not require extensive forking like you're worried about. It should just utilize the git patchers to download the code -> swap the csprojs to have the latest versions -> build them locally. Hopefully it'll work a bit farther since the nugets pulled in have newer signatures.

[katzmannr]

I deleted once more the previous comment because I found out a lot more how the build works.

I use now Engarde_Synthesis as example.

Build itself works on net8.0 and net9.0 locally
Build works too, when I update the package dependencies to the latest release (without any net6.0 warnings!).

What does not work: The net6.0 package dependencies remain in the project.

I have found no way to get nuget to use anything else beside net6.0 packages.
I try to get Synthesis.CLI to run if there can be anything done about this package nightmare.

[katzmannr]

FYI I'm spending probably too much time on this topic, but I need synthesis running on Linux, like a base tool or I can abort > 2 years of modding (SkyPatcher is not really an alternative).

The problem did actually start in late 2024 only, probably as some changes in wintrust/crypt32 (or other crypt parts) were added to Windows and dotnet.

What I have checked: Root certificates, I cannot find issues here on wine side.
What I found out: Root certificate check is failing only in dotnet (NU3037 and NU3026).
Is this only on Ubuntu 2024 ? No clue, I do not have any other Distribution.
Workarounds do not work at all. I tried a lot of them, but the error never goes away.
If it is really an Ubuntu / Debian issue, then I'd really like to understand how it can happen.

[katzmannr]

Workaround from above (below comment that adds certificate) works for me as well.

[xeals]

I recently reinstalled my prefix and am having issues setting Synthesis (0.35.5) back up. I hit and solved the SDK issue but can't update the mutagen version listings. I'm not sure if this is a variant of the certificate issues above, because I can't see anything about the error (why is the stack trace truncated?).

2026-02-10 19:01:22.297 +11:00 [ERR] Error querying for latest nuget versions.  Purging and trying again
System.ArgumentException: [-2147450735]: 
The command could not be loaded, possibly because:
  ...
   at Synthesis.Bethesda.Execution.DotNet.QueryLibraryVersions.Query(FilePath projectPath, Boolean current, Boolean includePrerelease, CancellationToken cancel) in D:\a\Synthesis\Synthesis\Synthesis.Bethesda.Execution\DotNet\QueryLibraryVersions.cs:line 30
   at Synthesis.Bethesda.Execution.Versioning.Query.QueryNewestLibraryVersions.GetVersions(CancellationToken cancel) in D:\a\Synthesis\Synthesis\Synthesis.Bethesda.Execution\Versioning\Query\QueryNewestLibraryVersions.cs:line 154
   at Synthesis.Bethesda.Execution.Versioning.Query.QueryNewestLibraryVersions.GetVersionsWithRestore(CancellationToken cancel) in D:\a\Synthesis\Synthesis\Synthesis.Bethesda.Execution\Versioning\Query\QueryNewestLibraryVersions.cs:line 162
   at Synthesis.Bethesda.Execution.Versioning.Query.QueryNewestLibraryVersions.<>c__DisplayClass26_0.<<GetLatestVersions>b__0>d.MoveNext() in D:\a\Synthesis\Synthesis\Synthesis.Bethesda.Execution\Versioning\Query\QueryNewestLibraryVersions.cs:line 72

(full log)

Nuget can fetch the VersionQuery dependencies just fine and the Nuget cache has all the versions of Mutagen.Bethesda.Skyrim. I can run the restore task on the command line fine. I notice that when it does the Nuget check loop it will flash a command window but I'm not sure if that's part of the build or the check.

[xeals]

This is only an issue for using "latest" versions. If I manually enter versions to use, I don't have a problem.

[Noggog]

Hmm, can/did you try clearing your %temp% folder? Maybe your versions query project it uses internally is borked

[xeals]

Clearing out the temp folder gives the same error.