nsalerno at securewatch24.com
Tue Sep 21 14:54:23 EDT 2010
Ah. It is my unit test. I have a test that launches installutil. The installutil.exe that comes with the 2.6.7 RPM packages is from the /usr/lib/mono/1.0 (there doesn't seem to be one for 2.0). The running of installutil invokes my Installer class and at that point PlatformID is going to be 128. In that particular case my Installer derived class is standard so it should have no problem running in a 1.x runtime (and it appears to be the case).
For the other tests in the suite, PlatformID is 4 as the runtime is 2.0.
From: Kornél Pál [mailto:kornelpal at gmail.com]
Sent: Tuesday, September 21, 2010 2:00 PM
To: Nicholas Salerno
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] System.PlatformID
Try looking at Environment.Version in the prod environment. If you get
1.1.x rather than 2.0.x you know what your problem is.
Note that only app.config is able to require a specific runtime version,
and there is no such thing as a 3.5 runtime (it's 2.0 with extra
assemblies versioned to 3.5.x.x).
Nicholas Salerno wrote:
>> It means you're running in the 1.0 profile. If you were running under
>> the 2.0 profile, you'd get 4 (PlatformID.Unix).
> If I write a scratch C# program to show the PlatformID I do get 4. However, in my production build I am getting 128. As far as I know the production build should be the 2.0 profile, especially since the build scripts (.proj/.csproj) have some components specifically require 3.5 as the minimum framework version (the whole project is targeted for the 3.5 framework). If the production assemblies are running as the 1.0 profile I would think something would have not worked properly by now. I'm a bit puzzled and will look into it.
> Thank you for the explanation.
> -----Original Message-----
> From: Jonathan Pryor [mailto:jonpryor at vt.edu]
> Sent: Monday, September 20, 2010 10:24 PM
> To: Nicholas Salerno
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] System.PlatformID
> On Mon, 2010-09-20 at 18:06 -0400, Nicholas Salerno wrote:
>> When I query System.Environment.OSVersion.Platform on Linux I get a
>> value that will equate to 128. Yet, this is not in the source code
>> definition for the PlatformID enum.
> It means you're running in the 1.0 profile. If you were running under
> the 2.0 profile, you'd get 4 (PlatformID.Unix). See:
> The first versions of the framework (1.0 and 1.1) didn't include
> any PlatformID value for Unix, so Mono used the value 128. The
> newer framework 2.0 added Unix to the PlatformID enum but,
> sadly, with a different value: 4 and newer versions of .NET
> distinguished between Unix and MacOS X, introducing yet another
> value 6 for MacOS X.
>> Question: is 128 supposed to mean Linux?
> It means Unix under the 1.x .NET profile; under the .NET 2.0 profile,
> PlatformID.Unix (4) is returned.
>> I am wondering if there is a better way or if this is all that can be done.
> Targeting .NET 2.0+ will help (no 128 value), but only so much (there's
> still distinct PlatformID.Unix and PlatformID.MacOSX values), so
> preferable (normally) are feature checks, not platform checks.
> Feature checks are also more useful anyway, as a feature may be added in
> some version of a platform, and (based on reading years of Dr. GUI
> articles in MSDN) platform version detection and handling is HARD. You
> would not believe the number of errors applications make doing that...
>> Also, what if Microsoft suddenly came out of nowhere and said that 128
>> will map to AIX?
> I would laugh. A lot. (AIX?! Seriously?)
> The matter still has a theoretical nature, which can be answered thus:
> More specifically, Mono 2.6 is the last release with 1.x profile
> support, and thus is the last version that will return 128 for
> PlatformID on Unix platforms. (Plus, most actual apps have been 2.0
> apps for quite some time.). Mono 2.8 is 2.0+ only, and thus will never
> return 128.
> Furthermore, 2.6 is only getting bug fixes (if that), not feature fixes,
> so even if Microsoft added a new enum value, only mono master will
> actually receive the value, not 2.6 (or likely 2.8, at this point).
> Thus, in practice, it's not really worth worrying about.
> - Jon
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list