Standalone cyz2json

[LucindaLanoy]

Due to the work on CytoProcess, the cyz2json repository has undergone several changes and has become too intertwined with CytoProcess. The goal is to ensure that cyz2json can function independently as a single version and continue to be used in other Cytosense-related projects. We also need to make it easier to update the repo's two main dependencies: .NET and the CyzFile-API.

[LucindaLanoy]

On my fork I have tried reducing the repo to the minimum working version as I find the repo quite cluttered, and I'm not sure all files are still used, here's what I found :

• To work, the process only needs Cyz2Json.sln and everything in the Cyz2Json folder (Program.cs, Cyz2Json.csproj, and the API folder), they are the core of the project allowing compilation.
• For github action, all we need is the workflow file (build.yml) and the LICENSE.txt, it doesn't need anything else.
• I haven't tested Docker containers, I wonder if they are really necessary considering that A) github action builds releases with the DLL inside directly for all os (while dockers are only for Linux), and B) I could make the original version work fine on my computer in early 2024 with only dotnet to install so if this is it, I think we could just write it down on the Readme (already the case), besides the installation of the software environment is kinda the point of the csproj file if I'm not mistaken.
• Licences, Readme, and examples are obviously not used but are needed for other reasons, examples should be checked to make sure they are not outdated.
• I can't find the use of version.json and .gitignore, removing them changes nothing. Similarly, two files from Robert remain, shell.nix and Makefile and I'm not sure they are still relevant with the use of Github Action (and removing them doesn't change anything either).
• Directory.Build.props finally is normally used to build software environment in a similar way that csproj file does but it is really useful when there are several csproj sharing the same environment (that way you can only write it once instead of repeating it for each project), here it is only used for the version.txt file that cause so many problems so deleting it actually improves the process.

What I propose is that for now, we can move back to the version of cyz2json of 23 january 2026, when the changes of cytobuoy were pulled. Then we can add my temporary patch for the version.txt problem if we want but we leave dotnet 10 upgrade for later as we are dependent on Cytobuoy to update their API for any change we make to be effective. In the meantime we can make a new branch to try to rework the repo from its core (the four main files + licence/doc/examples), forget about dockers, and try to rework the YAML file to make sure the tool is able to build the releases AND work locally with dotnet build, as well as finding a way to ease the process for future dotnet and the API upgrades.

[JoeRibeiro]

Yes, a good summary and proposal. Agree with all of this - removing docker, managing the build through actions exclusively. As long as we preserve the git history since 23 Jan, those modifications can be brought back in. It seems like a good place to revert to.

[LucindaLanoy]

Great, I'll start to work on that then, the git history since Jan 23 can be preserved through the backup branch you have made I think ?(the only commit since then was the first revert commit so I think we can keep it as the save for the changes)

Edit : I have managed to revert to the pull request from Cytobuoy, then managed to add the changes from my fork and rerun the workflow. The commits since last fryday are preserved in the backup branch. I will now create a new branch to play around with the repo and try to apply what we discussed above.

[JoeRibeiro]

Great, I'll start to work on that then, the git history since Jan 23 can be preserved through the backup branch you have made I think ?(the only commit since then was the first revert commit so I think we can keep it as the save for the changes)

Edit : I have managed to revert to the pull request from Cytobuoy, then managed to add the changes from my fork and rerun the workflow. The commits since last fryday are preserved in the backup branch. I will now create a new branch to play around with the repo and try to apply what we discussed above.

backup/pre-revert-20260129

https://github.com/OBAMANEXT/cyz2json/tree/backup/pre-revert-20260129

Thanks Lucinda

[LucindaLanoy]

Update : I have managed to create a workflow that automatically get the latest version of the API (by tag and not release because releases haven't been updated since late 2024), build+publish to get the API dll and needed libraries, and then commit and push to our repo. That way, we ensure to always an up-to-date version of API in the repo. The update is scheduled to run on the 15th of each month but can also be manually triggered.

As it is only in the standalone branch for now, I can't test the manual trigger (because it only recognises workflows of the main branch) but I tested it on my own fork and it works no problem. I'll wait until the 15th of February to check if the workflow manages to run on schedule (on my fork it works when I put a schedule for everyday but only for main once again). If it doesn't I'll simply add the API copy I have on my fork (but as I said once the workflow will be on the main branch we'll be able to run it manually and on schedule).

Now what remains is :

• the latest API version seems to create problems for the set definition, i have temporarily removed them to test the new api update workflow but i'll see if i can fix this asap
• the dotnet update remains an issue as it cannot be updated like the api from the workflow, however i might have found something that checks if we are close to the end of support of the version currently in use, i'll look into it as well as on this unsafe binary problem we mentioned in issue Updating to dotnet 10 #17
• still need to improve main workflow to build the release.