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 Iritscen, 9 years ago

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.

comment:2 by Christian, 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 Iritscen, 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
Note: See TracTickets for help on using tickets.