Building FW+FB in flatpak will be easier if I can build both with the same mono version. I need to use mono 5 to build FW. Building FB with mono5-sil (5.16.0.1) results in an error:

flexbridge/build$ ../run-in-environ msbuild FLExBridge.proj /p:Configuration=Debug
Microsoft (R) Build Engine version 15.1.8.0 ( Wed Sep 5 19:27:37 UTC 2018) for Mono
...
RunGitVersion:
mono "/home/vagrant/fwrepo/flexbridge/packages/GitVersion.MsBuild/tools/net48/gitversion.exe" "/home/vagrant/fwrepo/flexbridge/build" -output file -outputfile gitversion.json
...
ERROR [06/07/21 9:19:07:53] An unexpected error occurred:
System.TypeInitializationException: The type initializer for 'System.Text.Json.JsonSerializerOptions' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.Text.Json.Serialization.Converters.IEnumerableConverterFactory' threw an exception. ---> System.TypeLoadException: Could not find method '.ctor' due to a type load error: Type System.Text.Json.Serialization.Converters.IDictionaryConverter1[TCollection] has invalid vtable method slot 32 with method none assembly:/home/vagrant/fwrepo/flexbridge/packages/GitVersion.MsBuild/tools/net48/System.Text.Json.dll type:IDictionaryConverter1 member:(null)
--- End of inner exception stack trace ---
at System.Text.Json.JsonSerializerOptions..cctor () [0x0001f] in <74da783969ef4b53bcddcbb5f10fc069>:0
--- End of inner exception stack trace ---
at GitVersion.OutputVariables.VersionVariables.JsonSerializerOptions () [0x00000] in :0

This is not a problem if I use msbuild FLExBridge.proj /p:Configuration=Debug with mono 6.

OS: Ubuntu 20.04
Branch: feature/nuget

Maybe there is a work-around where I can skip using gitversion?

The about page is quite out of date, it should be updated to reflect the current state of support.

Here's the current version

how do we want to update this?

The Jenkins build of LfMerge depends on a TeamCity build named FLExBridgeLfmergeLinux64Continuous, which is supposed to build the lfmerge branch. The lfmerge branch was merged into develop in commit 7e06978 and deleted a little while later. But this has been causing the Jenkins build of LfMerge to fail. So I'm going to re-create the lfmerge branch based on commit 7e06978, or possibly commit 67d12ee a short time later which appears to contain several build fixes. This will allow the Jenkins build of LfMerge to work again.

Actually, I simplified the previous paragraph; there are really two Jenkins builds of LfMerge, one that builds lfmerge-7000072 from the master branch, and one that builds lfmerge-70000{68,69,70} from the fieldworks8-master branch. The master branch build has been working fine; it's only the fieldworks8-master branch that's been failing. But now I need to merge some code into LfMerge's fieldworks8-master branch, which means I need to get its Jenkins build working again. Re-creating the lfmerge branch here is the simplest way to do that.

From code review comment in #251:

We have been keeping a changelog for flexbridge for many years in debian/changelog and we have build scripts in this repository that have been used to keep this as well as some public documentation up to date.

The build scripts etc should be changed to take the changes from CHANGELOG.md and update debian/changelog and the documentation etc.

#407 got the AppVeyor build running again, but now there's an error:

Error publishing NuGet package artifact output/SIL.ChorusPlugin.LibFLExBridge.4.2.0-beta0025.snupkg: NuGet package cannot be read: The required element 'authors' is missing from the manifest.

And the same error message for all other symbol packages: SIL.ChorusPlugin.LibTriboroughBridge, SIL.ChorusPlugin.FLEx, etc.

This may become moot if #405 is approved and nuget package building moves to GitHub Actions, but in the meantime, it's worth looking into this error.

The build that creates the NuGet package(s) for FlexBridge is currently running on TeamCity. It's been failing to build since the commit that updated SIL.Chorus.Mercurial to 6.5.1. The reason, at least for the Linux64 build, is because the TeamCity runner is still on Ubuntu Xenial, which has Python 3.5. Mercurial, starting with release 6.2, supports Python 3.6 (or above) only.

We could fix this by creating a new TeamCity Linux build agent, but we're trying to move away from TeamCity. The better solution would be to move the NuGet packaging build to GitHub Actions.

FLEx Bridge-master-Win32-Continuous is currently failing at unit test on TeamCity.

The test runs fine locally on my developer machine, where dependencies are gathered via UpdateDependencies.bat.

When I reviewed Download.targets which TC uses, it seems the dependencies are being pulled from the FlexBridgeBeta Continuous builds.

The reason the unit test is failing now is because we recently added STRONG_NAME on the master branch of libpalaso, and the failing unit tests are flagging the error:
"Could not load file or assembly 'Palaso.TestUtilities, Version=2.5.120.0, Culture=neutral, PublicKeyToken=cab3c8c5232dfcf2' or one of its dependencies"

Should Download.targets be deprecated and let TC manage the dependencies?

appveyor.yml currently builds with image: Visual Studio 2019. We should update that to 2022 so that AppVeyor will be able to build code that targets .NET 8.

Here's an AppVeyor build that targets .NET 8 and built successfully from a PR branch. The only change needed was updating the image to 2022 instead of 2019.