Compiling on Linux

[artifexor]

Is there any plan to compile RVWorld on Linux using mono?

I got a lot of filename case error (sln file uses folder trrntzip instead of Trrntzip) and for example ILMerge.exe is wired to a Windows folder which is not exists on Linux. I know there is a pull request for change this problem and github says it merged but master tree looks different.

[waagbo]

I belive that much of these issues are related to the way NetFx structures project files and explicitly declares content. I've submitted a suggestion for upgrading libraries, etc. to netstandard2.0 and the CLI tools to netcore (#8). This PR ensures full CLI compatibility on Linux.

The GUI projects are a bit tricker to convert. The use of WinForms will require Mono as far as I understand.

If my PR is accepted, the next step would be to look further into the practicalities with WinForms and Netcore. My initial tests show that support for the WinForms designer is kind of flaky (at last in my clean Visual Studio 2019 Community setup). Works fine in JetBrains Rider though. The conversion itself seems like a pretty doable task.

As you mention ILMerge/ILRepack is also a concern which should be taken into consideration here.
A project fully converted to netcore3.1 will have the possibility to create a single binary with dotnet publish -r win-x64 -p:PublishSingleFile=True --self-contained false. This has yet to be confirmed for the WinForms projects.

Personally I think the way to go for Mono is to get as much up and running on the netcore-stack, and Mono compatibility will eventually be a result of the effort.

[waagbo]

So I tested my theories above. Turns out that Mono and Netcoreapp3.1 are not friends at all.
To maximize compatibility of the GUI apps, I think that keeping them on NetFx 4.7.2 is probably the best. I'm still eager to convert all the libraries til netstandard2.0 so we can compile the GUI apps for Linux netcoreapp3.1. I'm currenly looking into replacing ILMerge with ILRepack to make the move to netstandard2.0 happen.

@artifexor Are you expecting the GUI apps to compile on Linux using mono or are the command line apps as netcoreapp3.1 sufficient?

[waagbo]

@artifexor Could you have a look: Pull request #8 should resolve this issue. All the applications are now building on Linux. GUI applications requires mono to build. The setup for making pretty releases ILMerge/ILRepack are not ported, nor do I see the immediate reason to do so.

[artifexor]

@vidarw Thanks for your work and help! I tried to compile the CMD and GUI version.

CMD version looks fine at compile time but when i am running it says "A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/usr/share/dotnet'". Same for all binaries. I am not .net and mono expert and no idea what does it means. Will look for some answer (and solution) on Google.

GUI gives more pleasure because RomVault and TrrntZipUI are working but RomVaultX is not working. Starting directly gives "run-detectors: unable to find an interpreter for ./RomVaultX.exe" error and running via "mono RomVaultX.exe" gives

Unhandled Exception:
System.DllNotFoundException: SQLite.Interop.dll assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods.sqlite3_config_none(System.Data.SQLite.SQLiteConfigOpsEnum)
  at System.Data.SQLite.SQLite3.StaticIsInitialized () [0x0001d] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteLog.Initialize (System.String className) [0x0003f] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString, System.Boolean parseViaFramework) [0x00046] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString) [0x00000] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at (wrapper remoting-invoke-with-check) System.Data.SQLite.SQLiteConnection..ctor(string)
  at RomVaultX.DB.DBSqlite.ConnectToDB () [0x000b4] in <8ec72dd8982a41c9915ce112cd274e61>:0 
  at RomVaultX.frmMain..ctor () [0x00087] in <8ec72dd8982a41c9915ce112cd274e61>:0 
  at (wrapper remoting-invoke-with-check) RomVaultX.frmMain..ctor()
  at RomVaultX.Program.Main () [0x00018] in <8ec72dd8982a41c9915ce112cd274e61>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException: SQLite.Interop.dll assembly:<unknown assembly> type:<unknown type> member:(null)
  at (wrapper managed-to-native) System.Data.SQLite.UnsafeNativeMethods.sqlite3_config_none(System.Data.SQLite.SQLiteConfigOpsEnum)
  at System.Data.SQLite.SQLite3.StaticIsInitialized () [0x0001d] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteLog.Initialize (System.String className) [0x0003f] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString, System.Boolean parseViaFramework) [0x00046] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at System.Data.SQLite.SQLiteConnection..ctor (System.String connectionString) [0x00000] in <08d698bf938d4adabc54bd24f50eb290>:0 
  at (wrapper remoting-invoke-with-check) System.Data.SQLite.SQLiteConnection..ctor(string)
  at RomVaultX.DB.DBSqlite.ConnectToDB () [0x000b4] in <8ec72dd8982a41c9915ce112cd274e61>:0 
  at RomVaultX.frmMain..ctor () [0x00087] in <8ec72dd8982a41c9915ce112cd274e61>:0 
  at (wrapper remoting-invoke-with-check) RomVaultX.frmMain..ctor()
  at RomVaultX.Program.Main () [0x00018] in <8ec72dd8982a41c9915ce112cd274e61>:0

No idea what does it means or my way to start .exe is simply wrong. I have the System.Data.SQLite.dll file and x(86|64)/SQLite.Interop.dll file as well.

I prefer GUI this time even if I like command line apps for such task. And I like the "original" one executable for romvault style. Probably this is what ilmerge does.

I am using Debian sid with the latest dotnet-sdk (=3.1.201-1) and mono (=6.8.0.105+dfsg-3) from microsoft repository. Hah, at least I think so. DFSG means that mono is from the debian repo and not from the microsoft repo. I try to find out how to disable debian repo for mono packages (or give higher priority to the microsoft repo if some packages exist in both). Probably my mono installation messed up a little with mixed microsoft and debian packages. Same version but might using different path scheme which leads to errors. I will come back when sorted out.

[waagbo]

dotnet/cli

A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/usr/share/dotnet'

I think there is some kind of dependency missing in the local dotnet setup. I've got the same problem, but was fooled by dirty build folders. I have flipped the self-contained flag to true. This creates binaries with everything included (and worked even though I uninstalled everything dotnet-related). They are significantly lager, but compared to common utilities in other languages (terraform/golang) they are on par. I think it's fair to leave it on by default. If the pull request is merged I'll create a separate issue and get it fixed. Could you please do a make clean and try again?

mono/gui*
Repacking hybrid netstandard2.0 libraries and .NET 4.7.2, and why I tried to convince @gjefferyes to lift everything to netcoreapp3.1 in one go. Sadly my initial tests shows that using netcoreapp3.1 for the GUI totally breaks non-Windows compatibility so thats pretty much off the table.
Did some tests of repacking on the binaries built with make build-gui this morning. I get the same errors as this guy reported: gluck/il-repack#243

Regarding RomVaultX. You'll need a Linux native SQLite.Interop.dll to get past you issue.
http://blog.wezeku.com/2016/10/09/using-system-data-sqlite-under-linux-and-mono/
(referenced from https://www.reddit.com/r/dotnet/comments/9fh2qb/sqliteinteropdll_not_found_in_linux_build/)
We are playing in the black magic realm of getting Mono/.NET 4.7.2 to play along with Linux native libraries. If you are interested enough to create a bash script that compiles the interop libary, I'll for sure include it. To be warned the next step that probably bites after getting SQLite up and running is probably the Dokan.NET virtual file system. Feel free to contribute to this one if interested. I personally find RVX to niche and would rather put the effort elsewhere than getting direct compatibility.

[artifexor]

@vidarw
Purged all mono packages, raised the priority of the mono repository, reinstall mono packages. Now there is only mono-project originated packages installed. I am running this simple script to build:

git clone https://github.com/RomVault/RVWorld.git RVWorld
pushd RVWorld
git fetch origin pull/8/head:pr8
git checkout pr8
nuget restore
make
make build-gui
popd

dotnet-cli: working fine without error now

mono/gui*: nothing changed, romvault is fine but lot of dll instead of one executable, romvaultx gives the same error about sqlite. ILRepack gives the same assembly error as you referenced. I have the package libmono-sqlite4.0-cil (Mono Sqlite library (for CLI 4.0)) installed. Do I still need that interop stuff? Projects still have wired Windows path to reference assemblies:

$ rg 'Program Files'
RVWorld/ROMVault/ROMVault.csproj
69:    <CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
71:    <CodeAnalysisRuleDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\\Rules</CodeAnalysisRuleDirectories>
86:    <CodeAnalysisRuleSetDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\\Rule Sets</CodeAnalysisRuleSetDirectories>
87:    <CodeAnalysisRuleDirectories>;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\\Rules</CodeAnalysisRuleDirectories>
361:      <ReferenceAssemblies>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2</ReferenceAssemblies>

RVWorld/TrrntZipUI/TrrntZipUI.csproj
151:      <ReferenceAssemblies>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2</ReferenceAssemblies>

RVWorld/RomVaultX/RomVaultX.csproj
261:      <ReferenceAssemblies>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2</ReferenceAssemblies>

RVWorld/DATReaderTest/UDCReader.cs
101:            //System.Diagnostics.Process.Start(@"C:\Program Files\Notepad++\Notepad++.exe", strCmdText);

[waagbo]

Got a confirmation from GordonJ that RomVaultX will not run on linux. The Dokan.NET virtual file system is Windows only. So with the reported bugs in ILRepack, I think we are at the best possible spot currently available.

[artifexor]

@vidarw thank you, bad news.