Opened 9 years ago
Last modified 9 years ago
#107 new defect
Report .NET version in use
Reported by: | Iritscen | Owned by: | Christian |
---|---|---|---|
Priority: | major | Component: | AEI2 |
Keywords: | Cc: |
Description
I'm not sure how tricky this is, because there can be multiple .NET versions installed on a machine, and OniSplit also has that .config file next to it which guides it in which version to run on. But I was talking to Neo about a language-related issue with OniSplit, and he pointed out that older .NET versions may not play nicely with foreign scripts compared to newer versions, so it would be helpful to see what version is in use when we receive an AE support request -- maybe in aei_output.log where it currently says ".NET: true".
Also, so I don't have to make a new ticket for this, I wanted to remind you to remove the checking of .raw/.sep files from the "Building sources list" step so that we don't see all those "Not a level file!?" errors in Installation.log.
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Would be relatively easy with Mono (as it's really a program that can be invoked and most likely has a "show version" flag) but especially on Windows that's not so easy.
comment:3 by , 9 years ago
Looks like on Windows you might have no choice but to get a list of all frameworks/CLR versions (see https://msdn.microsoft.com/en-us/library/hh925568%28v=vs.110%29.aspx). We can then determine from that list which one would by used by OniSplit, taking into account that OniSplit is distributed with a .config file that lists:
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0.30319"/>
Having this in place (and maybe the version of Windows, since some of these users were probably on old PCs) might allow us to narrow down the issue the next time someone reports the problem(s) that bug #92 seems to be about.
As you suggested, on Macs, you can simply use the --version switch. Here is some sample output:
$ mono --version Mono JIT compiler version 4.0.4 ((detached/d481017 Mon Sep 28 17:32:19 EDT 2015) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: normal SIGSEGV: altstack Notification: kqueue Architecture: x86 Disabled: none Misc: softdebug LLVM: yes(3.6.0svn-mono-(detached/a173357) GC: sgen
Unfortunately this only gives us the Mono version, with no mention of what CLR is supported or used, but this probably won't matter.
P.S.: Thanks for fixing the "Not a level file!?" errors, it has cleaned up that part of the log a lot. However packages with .DS_Store files are still triggering the message, so if you find it easy to add an exception for those, too, it would prevent this happening throughout the log:
Folder /Games/Oni-Test/AE/AEInstaller/packages/00050Menu_Fixes__AE_/oni/common Folder/file /Games/Oni-Test/AE/AEInstaller/packages/00050Menu_Fixes__AE_/oni/common/level0_Final Added for level level0_final Folder /Games/Oni-Test/AE/AEInstaller/packages/02000Globalization_Fixes_for_Characters/oni/common Folder/file /Games/Oni-Test/AE/AEInstaller/packages/02000Globalization_Fixes_for_Characters/oni/common/.DS_Store Not a level file!? Folder/file /Games/Oni-Test/AE/AEInstaller/packages/02000Globalization_Fixes_for_Characters/oni/common/level0_Final Added for level level0_final
I just want to clarify that the reason for this request is bug #92, which seems to be a persistent issue for a small number of users who may all be using foreign scripts in Windows.