[HansJansen]

@perpetualKid:

For what it's worth, I include the log file and the list of errors and warnings the "Build All" command produced.

(I had to rename the Ide.log file as the system refuses to upload "this kind of file".)

Attached File(s)

•  ErrorsWarnings.txt (6.82K)
  Number of downloads: 262
•  Ide_log.txt (12.19K)
  Number of downloads: 258

[James Ross]

HansJansen, on 04 October 2018 - 04:39 AM, said:

I have tried to run your latest ORTS-MG with MG3.7 on my Linux system, but without much success, alas.
The binary package starts running with Wine, up to the point of pressing the Start button; then it vanishes without a trace (:(). If I start it with the mono command (I have installed the latest MonoDevelopment, including the MonoGame V3,7), it comes up with a small window stating it needs .NET Framework 3.5 SP1 and XNA Framework 3.1, and shuts off when I hit the OK button.

The .NET and XNA framework checks are all OpenRails.exe does before starting Menu.exe, so you can skip that and try running Menu.exe directly.

HansJansen, on 04 October 2018 - 04:39 AM, said:

- In Contrib/ActivityEditor/ActivityEditor/ActivityEditor.csproj, changed line

<Compile Include="ActionProperties\ControlStartProperties.designer.cs">

into

<Compile Include="ActionProperties\ControlStartProperties.Designer.cs">

- In Menu.csproj, changed line

<Compile Include="ImportExportSaveForm.designer.cs">

into

<Compile Include="ImportExportSaveForm.Designer.cs">

– Renamed file Orts.Formats.Msts/ACEFile.cs to Orts.Formats.Msts/AceFile.cs

All fixed in X4248, although I am unsure what'll happen for people on Windows with regards "AceFile.cs". Subversion will probably leave it alone, but I believe the rename is correctly in the repo so should propagate to git okay:

https://james-ross.co.uk/temp/orts_159.png

HansJansen, on 04 October 2018 - 04:39 AM, said:

So three occurrences of the case-sensitive nature of Linux, as opposed to Windows.
Maybe you can put these changes into your sources?

They're in the official sources now, so when the next update of the MonoGame version is made they should be included.

HansJansen, on 04 October 2018 - 04:39 AM, said:

After that, when built individually, the following 5 projects produce this error:

The command “echo $Revision: 000 $>Revision.txt
	date /t>>Revision.txt
	time /t>>Revision.txt exited with code 127. (MSB3073)

– ContentChecker
– Launcher
– Menu
– RunActivity
– TrackViewer

(“Build All” results in the same error for only Launcher, Menu and RunActivity.)

I have no idea how to tackle these errors. Could you point me to possible cause(s)?
It would be nice to at least finish the building of the solution (not to mention running the result!)
I am quite willing to delve further into that problem, should you wish me to do so.

These errors are all caused by code which is included in the project build configuration to ensure the version numbers are reset to 0, to avoid confusion with any official versions.

Inside each project file (.csproj), the code is inside "<PostBuildEvent>". You can just remove it, but be aware that Open Rails may report official version numbers when it shouldn't do. I believe the equivalent code for Linux would be (with the XML escaping needed for the project files):

echo "$Revision: 000 $">Revision.txt
date +%x>>Revision.txt
date +%R>>Revision.txt

[HansJansen]

James, thank you very much for your reply. Tomorrow, I will try to change things as you have pointed out, and see where that takes me. Of course, I will report failure or success here!

Regards,

[dajones]

Assuming that you are able to get the MG version compiled and running on Linux, you will then start running into file name case problems in the content files. There are hundreds or thousands of them and often the names aren't used consistently, so renaming the files won't always fix the problems. I have a private sim that can use MSTS content on Linux and I ended up adding code to automatically fix the case when an open attempt fails. You will probably need to do something similar.

I didn't add code to automatically fix directory names, but there are problems there also. I usually use symbolic links to fix those. For example I have a symbolic link from Routes to ROUTES, so that both work.

Doug

[HansJansen]

dajones, on 04 October 2018 - 02:22 PM, said:

Assuming that you are able to get the MG version compiled and running on Linux, you will then start running into file name case problems in the content files. There are hundreds or thousands of them and often the names aren't used consistently, so renaming the files won't always fix the problems. I have a private sim that can use MSTS content on Linux and I ended up adding code to automatically fix the case when an open attempt fails. You will probably need to do something similar.

I didn't add code to automatically fix directory names, but there are problems there also. I usually use symbolic links to fix those. For example I have a symbolic link from Routes to ROUTES, so that both work.

Doug

Doug, thank you for these thoughts! I wouldn't be surprised by that kind of problems anyway - they are only to be expected in Windows programs that never have to bother with case problems.
For the moment I am not anywhere near a compilation success, but I will keep this in mind just in case I get lucky somewhere/when...

Thanks, and regards,

[HansJansen]

@James Ross:

I have tried running the binary package by starting Menu directly. This gets me the opening window, but not a single textfield reacts to a mouse click. Hitting any button results in a stack trace

System.EntryPointNotFoundException: LockWindowUpdate

So I will leave this alone for the time being, and concentrate on the compilation process.

I changed the PostBuildEvent stuff like you suggested, and that indeed gets rid of these errors. So now, more files get compiled during the Build All, but this now results in no less than 190 Error messages... Progress indeed(;)).

As a next step, I have looked through the References lists of each project. There, I seem to be missing the following:

– in RunActivity:	PresentationFramework

– in TrackViewer:	PresentationCore
			PresentationFramework
			WindowsFormsIntegration

Several of the new errors are apparently related to this. Do you know how or where I can get those assemblies?
(Maybe the crash of the binary package might be caused by this problem too...)

[HansJansen]

Short update to my previous post:

- The PresentationFramework reference in RunActivity appears not to be referred to anywhere in that project. I have removed it from the list and recompiled the project, without any visible changes.

- The 190 Error messages appear to be generated solely from the files in the TrackViewer project! In my (NSH (:))) opinion this project does not use XNA like all others, but the WPF etc. instead. Can I exclude it from the build process somehow?

[James Ross]

HansJansen, on 05 October 2018 - 10:07 AM, said:

- The PresentationFramework reference in RunActivity appears not to be referred to anywhere in that project. I have removed it from the list and recompiled the project, without any visible changes.

I've removed the reference from the official source code in X4250, although I did have to tweak "Source/RunActivity/Viewer3D/UserInput.cs" (maybe a similar tweak is already in the MonoGame version).

HansJansen, on 05 October 2018 - 10:07 AM, said:

- The 190 Error messages appear to be generated solely from the files in the TrackViewer project! In my (NSH (:))) opinion this project does not use XNA like all others, but the WPF etc. instead. Can I exclude it from the build process somehow?

You're right, in that PresentationFramework and PresentationCore are the WPF assemblies, although the TrackViewer project does also use XNA. WPF is an alternative to System.Windows.Forms. The simplest way to remove it from the build is to remove the following lines from "Source/ORTS.sln":

Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "TrackViewer", "Contrib\TrackViewer\TrackViewer.csproj", "{79C3A70B-7535-40CB-8448-91AB87CBAE44}"
EndProject

And these ones:

		{79C3A70B-7535-40CB-8448-91AB87CBAE44}.Debug|Mixed Platforms.ActiveCfg = Debug|x86
		{79C3A70B-7535-40CB-8448-91AB87CBAE44}.Debug|Mixed Platforms.Build.0 = Debug|x86
		{79C3A70B-7535-40CB-8448-91AB87CBAE44}.Release|Mixed Platforms.ActiveCfg = Release|x86
		{79C3A70B-7535-40CB-8448-91AB87CBAE44}.Release|Mixed Platforms.Build.0 = Release|x86

That should avoid it being built unless you explicitly target the "TrackViewer.csproj" file.

[James Ross]

HansJansen, on 05 October 2018 - 07:26 AM, said:

I have tried running the binary package by starting Menu directly. This gets me the opening window, but not a single textfield reacts to a mouse click. Hitting any button results in a stack trace

System.EntryPointNotFoundException: LockWindowUpdate

So I will leave this alone for the time being, and concentrate on the compilation process.

Ah yes, this is one of a number of places we call Windows APIs directly - in this case to prevent the menu window updating in the middle of some data loading and being filled in, IIRC. We're going to have to start a convention of defines for platforms or some other means to separate Linux and Windows-specific code. This is something we can look at after 1.3 is released (which will be quite soon), but in the mean time you can comment out the calls as and when you find them.

If you search the code for "extern" (or "DllImport") you'll likely find all the external functions we use. Apart from the OpenAL ones, they're probably all Windows-specific, so comment them out (the "extern" line) and then the compiler will alert you to each place they're used, so you can comment them out there. A few minor features will not work, like the memory usage on the HUD (F5) DEBUG screen, IIRC, but nothing major.

[HansJansen]

Right. Thanks again James; I will probably need quite a bit longer before I have something useful to ask/tell you.

Have a nice weekend!