X64 build reversion && .NET4.6 compatibility.

[Dracolique]

Hi Alvydas!

long time no speak. You may remember me from some email exchanges a few months ago. I was (am still am) working on an orthographic top-down MMO. That project is coming along nicely, but I've recently started a new one with a friend of mine and we're having some troubles with MSF 2.0.3.

Firstly, there seems to be an issue where building via the tools-> msf -> build functions always seems to revert and build to x86 architecture even if you have x86_64 previously selected. This isn't a huge issue for me - I can just build the Client, GameServer and MasterAndSpawner manually. If I do this then they build just fine. I don't know if there is a solution which would make the auto-build system use previously selected architecture (I didn't see anything in the BuildOptions to force it toward x86_64, but I also didn't look terribly hard because there's an easy workaround).

Anyway that is not my main issue, I just thought I'd mention it while I'm here. My main issue is this: the current project that I'm working on incorporates a Python3.3 interpreter which is built against .NET4.5, and that means I absolutely must use the upcoming .NET4.6 scripting runtime version for it to work.

But MSF 2.0.3 simply does not work with .NET4.6. Currently this runtime option is only available in Unity2017 beta builds, but it will be a standard feature soon enough. I would personally appreciate it if you could look into the issue and see if there's an easy fix... but you'll need to do this pretty soon in any case if you want to avoid a lot of disgruntled users when Unity2017 gets out of beta.

Sorry to be the bearer of bad news and more work for you :( I've attached some .NET4.6 MSF crash log output files for you to look over.

ClientLog.txt

MasterSpawnerLog.txt

[arcanor]

Here are a few thoughts:

• You didn't mention what test scenarios you'd already tried. Have you tried the same project built with the same editor version, but instead using the standard .NET2.0 Api compatibility level?
• In your Master and Spawner scene, in the Spawner gameobject, are the variables set appropriately for your choice of deployment target? Specifically, what are DefaultSpawnInBatchmode, and SpawnWebglServers set to?
• What command line parameters are you using with your Master and Spawner servers?
• Do you get similar results when testing other MSF demos?

Also, don't forget that MSF is open source now, so please consider doing the changes yourself and contributing to the community! :)

[Dracolique]

I tested thoroughly. I simplifed down to an empty project with nothing else in it and I would not be posting here if the problem was something other than described. I also tested on multiple machines. MSF works just fine after being built in the following configurations:

2017.1.b6 \ .NET3.5 Runtime\ .NET 2.0 Subset\ x86
2017.1.b6 \ .NET3.5 Runtime\ .NET 2.0\ x86
2017.1.b6 \ .NET3.5 Runtime\ .NET 2.0 Subset\ x86_64
2017.1.b6 \ .NET3.5 Runtime\ .NET 2.0\ x86_64

But the Client & MasterAndSpawner start crashing and producing the provided logs the moment the project is built against the .NET4.6 Runtime.

Regarding fixing the code myself: I'm fully capable of it, and If it's not fixed by the time I actually need MSF to be working in this project then I will do so, but I have plenty on my plate already. I just figured I'd give you guys a heads up so you can get ahead of the curve and not have a broken framework on the asset store when .NET4.6 compatibility is released.

There's also the fact that I purchased the framework shortly before it was made freely available (not the first time this has happened... TextMeshPro springs to mind), and although that is definitely not your problem, I am still in the mindset of a paying customer - I'm unaccustomed to being required to fix things that I've paid good money for. Perhaps that's unfair, but it is what it is.

[arcanor]

@Dracolique - Please note that I am just a (paying) customer like yourself. I sometimes try to help @alvyxaz (project creator) and the community by reviewing issues from time to time and doing some initial troubleshooting. As for that, those questions I asked above weren't just FAQs to put you off. They were actual questions to help me understand and maybe help identify where the problem might lie.

Also, FYI, I am not personally able (without a fair degree of trouble) to test these scenarios myself because I don't have time or inclination to be testing the Unity beta. My own development projects don't require it (yet)! My questions are solely based on my experience with MSF.

So, all that being said, and if you don't mind my asking, could you please provide:

• the settings in your variables DefaultSpawnInBatchmode, and SpawnWebglServers
• your command line parameters when launching the Master and also Spawner servers
• which specific demo(s) you were running when you got these errors (MSF comes with many possible ways to configure it)

These may provide insights as to how the problem may be fixed.

In any case, as a fellow community member, I thank you for submitting this issue so that we're all aware of the incompatibility. And hopefully we can figure out what's at the bottom of it and get it working properly.

[Dracolique]

I am sorry if I came across a bit harsh. Here is the information you requested:

In the pursuit of simplicity, I started a brand new project, imported nothing but MSF2.0.3 and did my build tests. All settings are default. So with that in mind:

DefaultSpawnInBatchmode = false;
SpawnWebglServers = false;
(assuming the Quickstart build doesn't override these somewhere)

The problem was encountered with the QuickStart demo executables, both when targeting x86 via the automated build script and also when built manually targeting x64. The following scenes were included in each manual build:

Client.exe: Client, SimplePlatform
GameServer.exe: GameServer, SimplePlatform
MasterAndSpawner.exe: MasterAndSpawner, SimplePlatform (not needed but I included it anyway)

The command line parameters to launch Master and Spawner servers were also default.

[alvyxaz]

@Dracolique Hey!

Regarding the QuickBuild issue - it was never meant to work on all the platforms and all of the games, it's provided only as an example. You can copy the MsfQuickBuild.cs file and make the changes that would fit your setup ;)

Regarding the 4.6 support - I wasn't going to do that until Unity2017 is released (or at least until it's further into the beta).

Tomorrow I'll take a look to see if it's something simple, if it is - I'll try to submit a fix within the next few days :)

[Dracolique]

Hi Alvydas,

No worries about the quick build thing - like I said it's not a big deal anyway. Yeah if you can spend a few minutes looking into 4.6 that would be great. As I said to @arcanor, I'll figure it out myself if I need to but I think you're probably more qualified to quickly discover what's going on.

Thanks for taking the time to look into it!

[alvyxaz]

@Dracolique - I've download the Unity 2017.1.0b6, set the runtime to .NET 4.6, made a "Quick Setup" build, and everything was running fine.

Except for occasional crash when closing the application - GetLastError: 'Attempt to access invalid address.'

Does it crash randomly, or does it always produce the same stack trace? My logs didn't show any stack trace, but yours seem to have crashed while going through XmlSerializer internals.

I found something related to "XmlSerializer" and .NET 4.6, but I doubt it's the case: Link

Whatever the case may be, the error seems to be caused due to invalid memory access, which, in a managed language, should not be happening, so it's most likely in the unmanaged (native) code within Unity. My guesses are:

• Something's not completely working within the Unity's .NET 4.6 runtime compatibility (probably due to the native scripts within Unity) - this is the most likely problem
• Internal Mono version contains XmlSerializer bug (doubtful, as it's not crashing on serializer in my build)
• Internal networking library (Websocket-sharp) might have some issues, but it's also doubtful, as it's working on .NET 3.5 and I've tested it on Mono environment with 4.6-like runtime.

Again, let me know if it crashes "randomly" or at the specific point, and we'll try to figure it out from there :)

By the way, @arcanor , I don't think I can thank you enough for helping the community!

[Dracolique]

@alvyxaz

On further testing, when run on my main development machine and on my other computer at home it always crashes on clicking the Create Room button, generating the the logs I provided earlier .

However, I tested on my work machine today, and it ran fine, but sometimes crashed on exit like yours, or on click of 'Play as Guest', with the log showing that it failed to load SspiCli.dll (a signed Microsoft security DLL).

Given this, along with your experience, I think you're right... the .NET4.6 implementation is likely to blame. It's just too unstable at the moment. I will put off implementing networking until Unity 2017 is released. There are other things I can do for the moment.

Thanks for running your own tests on it though, Alvydas.

[alvyxaz]

@Dracolique No problem - I can't wait to hop on the .NET 4.6 too, mainly to be able to use TPL and latest 3rd party libs.

Seeing how unstable it is at the moment made me a bit sad, haha. Random crashes like that are very difficult to fix, and I wouldn't be surprised if after the full release of Unity 2017 the .NET 4.6 feature would still be in the "experimental" state. Let's hope for the best, though ;)

[angusmf]

https://forum.unity3d.com/threads/frequent-crashes.489173/

[alvyxaz]

@angusmf thanks, angus!

By the way, I'm sorry for being so inactive during these past few months. I'll make an announcement in a few days explaining what has happened

[zhuxianzhiniko]

I use unity version 2017.4.1f1, and .net 4.6.
Build default project, but not start GameServer, works fine if you use .net3.5.

Error:

An exception was thrown while starting a process. Make sure that you have set a correct build path. We've tried to start a process at: './GameServer.exe'. You can change it at 'SpawnerBehaviour' component

System.ComponentModel.Win32Exception (0x80004005): ApplicationName='./GameServer.exe', CommandLine=' -msfLoadScene SimplePlatform -msfMasterIp 127.0.0.1 -msfMasterPort 5000 -msfSpawnId 0 -msfAssignedPort 1500 -msfMachineIp 127.0.0.1 -msfSpawnCode "278ded" -msfLobbyId 0', CurrentDirectory='', Native error= Parameter error

Starting process with args:

-msfLoadScene SimplePlatform -msfMasterIp 127.0.0.1 -msfMasterPort 5000 -msfSpawnId 0 -msfAssignedPort 1500 -msfMachineIp 127.0.0.1 -msfSpawnCode "278ded" -msfLobbyId 0

[angusmf]

You can get around that problem by passing the full path to the game executable

[zhuxianzhiniko]

@angusmf Thank you very much. It is working. Why is the path related to the .net version?

[angusmf]

Great question, but I think it's technically a bug in the new runtimes. It should be reported to Unity.

[MostHated]

Sweet, I bet we should see a fix for it sometime in late 2019. : D