[Mono-list] Detecting Mono Under Windows

[Charlie Poole]

My mistake... the code at
https://github.com/nunit/nunit/blob/d42d932d1db8fa169901d941c388497a7c3307ec/src/NUnitEngine/nunit.engine/RuntimeFramework.cs#L581
is used in NUnit currently. Since we were only recognizing older
versions of Mono, that code made some degree of sense. However, it
appears that a few months back, somebody added the *-api directories
to what was being looked for. That seems to be an error since we are
trying to enumerate profiles under which we can run tests. That would
involve only the mono-?.? directories and not mono-?.?-api as I
understand it.

Can you tell me at what version the notion of different profiles for
execution disappears?




2016-08-26 13:58 GMT-07:00 Charlie Poole <charlie at nunit.com>:
> Hi Alex,
>
> Thanks for the reply. The Windows machine I checked on had Mono 3.2.3
> on it and seems to have yet another setting. The key
> HKLM\SOFTWARE\Novell\Mono\Mono DefaultCLR has value 3.2.3. I'll
> download a 3.2.3 to make sure that's not a spurious setting somebody
> (like an earlier version of me) created!
>
> As for the NUnit code you pointed to, the method was an experiment
> that fortunately never made it into production.
>
> So, it looks as if I have three checks to make, stopping after the
> first one succeeds:
> 1. Content of HKLM\SOFTWARE\Mono (or HKLM\SOFTWARE\WOW6432Node\Mono)
> 2. Subkey indicated at HKLM\SOFTWARE\Novell\Mono\Mono DefaultCLR\(Default)
> 3. Subkey indicated at HKLM\SOFTWARE\Novell\Mono\DefaultCLR
>
> Does that make sense to you?
>
> Charlie
>
> 2016-08-26 13:27 GMT-07:00 Alexander Köplinger <alkpli at microsoft.com>:
>> Hi Charlie!
>>
>> The new MSI based installers write the following registry keys since Mono 4.2:
>>
>> HKLM\Software\Mono (or HKLM\Software\WOW6432Node\Mono depending on whether you use the x64 or x86 installer):
>> - Architecture
>> - Installed
>> - Version
>> - SdkInstallRoot
>> - FrameworkAssemblyDirectory
>> - MonoConfigDir
>>
>> The MSI based installer was actually introduced in Mono 3.12, but it only wrote the "Installed" key back then. All these versions up till now install into C:\Program Files\Mono though so you could just look for that.
>> There can only be one version of Mono installed on the machine (x64/x86 can be installed side by side) with the new installer.
>>
>> For the earlier .exe-based installers the Novell registry keys are still correct, though we had a quite long time where we didn’t produce Windows installers at all (I think from 3.0.10 – 3.12.0).
>>
>> - Alex
>>
>> PS: Regarding detecting Mono versions, please note that code like https://github.com/nunit/nunit/blob/d42d932d1db8fa169901d941c388497a7c3307ec/src/NUnitEngine/nunit.engine/RuntimeFramework.cs#L581 doesn't
>> make sense on modern Mono versions since you can’t run against the 2.0/3.5/4.0 class libraries or CLR version anymore. You'll always run against the latest* libraries and runtime, which was part of the reason for renaming the profile folders
>> to 2.0-api, 4.0-api and so on because we only keep them so you can still compile class libraries targeting these older profiles. They are reference assemblies with metadata only.
>>
>> * which is sadly still called 4.5 on disk because too many apps hardcoded that path even though it contains ~4.6.1 .NET APIs right now
>>
>>
>> On 26/08/16 20:54, "Mono-list on behalf of Charlie Poole" <mono-list-bounces at lists.dot.net on behalf of charlie at nunit.com> wrote:
>>
>>     Hi All,
>>
>>     I'd like to fix NUnit so it detects all Mono installations under Windows.
>>
>>     The old code, now broken, looks at the registry entry
>>     HKLM\SOFTWARE\Novell\Mono\DefaultCLR to find the default version and
>>     then check HKLM\SOFTWARE\Novel\Mono\<version> to find the install
>>     root.
>>
>>     It looks as if this has been broken for a long time - I've only been
>>     using Mono on Linux myself and so didn't notice.
>>
>>     I'd like to know what to check currently and what other settings may
>>     have been used over the years. Ideally, NUnit should find even a quite
>>     old installation if a new one has not replaced it.
>>
>>     The alternative, of course, would be to enumerate all available
>>     versions, default to the newest and let the user select older ones if
>>     desired.
>>
>>     Any advice will be appreciated.
>>
>>     Charlie
>>     _______________________________________________
>>     Mono-list maillist  -  Mono-list at lists.dot.net
>>     http://lists.dot.net/mailman/listinfo/mono-list
>>
>>