Re: [Mono-dev] Advice on Standard Tags to represent Runtimes
To run under the mono 1.0 profile, which is API version 1.1.4322. I admit that bit is confusing, but it has some basis in prior usage. Ah, so it's the direct equivalent to the 'COMPlus_Version' environment variable in .NET? Using 'net-1.0' is like: set COMPlus_Version=v1.0.3705 Reflector.exe Using 'mono-1.0' is like: mono --version=v1.0.3705 Reflector.exe (Mono automatically maps v1.0.3705 to v1.1.4322) For consistency we should maybe add 'mono-1.1', which would be like: mono --version=v1.1.4322 Reflector.exe So you'd like to be able to select the actual mono (not api) version. OK, that's a new feature to look at. How would you distinguish whether you wanted to use the 1.0 versus the 2.0 profile under a given mono version? That is, the --version arg to mono.exe. I think the ability to run tests in different Mono versions side by side could be useful. Would any Mono developers like to comment? Would you find this useful for finding regressions? Regards, Jamie. -- http://www.testdriven.net http://twitter.com/jcansdale http://weblogs.asp.net/nunitaddin On Thu, Mar 5, 2009 at 5:01 AM, Charlie Poole char...@nunit.com wrote: Hi Jamie, In NUnit, it is now possible to specify the runtime under which tests should be run. For MS CLRs, I use net-1.0, net-1.1, net-2.0, etc. For mono, I use mono-1.0 and mono-2.0. I took this convention from NAnt. This is confusing because NAnt uses this to specify compiler tools whereas NUnit is specifying the runtime. I'm guessing that in NAnt mono-1.0 means use 'gmc' and mono-2.0 means use 'gmcs'. It means that when you use the csc task. But when you use exec it means to run under the mono 1.0 profile. What does mono-1.0 mean in NUnit when used to specify a runtime version? To run under the mono 1.0 profile, which is API version 1.1.4322. I admit that bit is confusing, but it has some basis in prior usage. Q1: Is this convention confusing? I considered using any-1.1, etc. but that looked a bit dumb. This is confusing. AFAIK there is no neat mapping between .NET and Mono versions and the CLI specs. To be clear, I make no distinction at all between different Mono release versions - like 1.92, 2.0.1, etc. For some apps, it could be necessary to specify that but it isn't currently available. And it's orthoghonal to the API version. Q2: Do you think net-x.x should be used for the generic case rather than for Microsoft? .NET is a Microsoft brand. Using it for the generic case would be confuse things. We could maybe use something like net-x.x-equiv, but then we're back to the problem of there being no neat mapping between .NET and Mono versions. Q3: When the runtime under which a test should execute (in a project file) would you rather see the vx.x form or an explicit combo like mono-2.0+net-2.0? An explicit combo like: mono-2.0+mono-2.0.1+mono-2.2+mono-2.4+net-2.0 So you'd like to be able to select the actual mono (not api) version. OK, that's a new feature to look at. How would you distinguish whether you wanted to use the 1.0 versus the 2.0 profile under a given mono version? That is, the --version arg to mono.exe. This would be a great way to flush out regressions. :-) Yes, but I can see I've opened a can of worms. :-) Regards, Jamie. -- http://www.testdriven.net http://twitter.com/jcansdale http://weblogs.asp.net/nunitaddin On Wed, Mar 4, 2009 at 3:13 AM, Charlie Poole char...@nunit.com wrote: Hi All, This is a bit OT for the dev list, but I suspect I'll get more solid answers based on experience here than elsewhere. In NUnit, it is now possible to specify the runtime under which tests should be run. For MS CLRs, I use net-1.0, net-1.1, net-2.0, etc. For mono, I use mono-1.0 and mono-2.0. I took this convention from NAnt. These tags are used in several text files and also appear in dropdowns in the GUI. The problem comes up when I want to indicate that a test must be run under a particular CLR version, without regard to whether it's mono, ms .NET or something else. In that case, I started to use v1.0, etc. but I'm not sure it's very clear. Q1: Is this convention confusing? I considered using any-1.1, etc. but that looked a bit dumb. Q2: Do you think net-x.x should be used for the generic case rather than for Microsoft? If so, what would you expect to see for Microsoft. Q3: When the runtime under which a test should execute (in a project file) would you rather see the vx.x form or an explicit combo like mono-2.0+net-2.0? This is something that is quite easy to change - up to the point where people start using it - so I'd like to get it right the first time! Thanks, Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___
Re: [Mono-dev] Advice on Standard Tags to represent Runtimes
In NUnit, it is now possible to specify the runtime under which tests should be run. For MS CLRs, I use net-1.0, net-1.1, net-2.0, etc. For mono, I use mono-1.0 and mono-2.0. I took this convention from NAnt. This is confusing because NAnt uses this to specify compiler tools whereas NUnit is specifying the runtime. I'm guessing that in NAnt mono-1.0 means use 'gmc' and mono-2.0 means use 'gmcs'. What does mono-1.0 mean in NUnit when used to specify a runtime version? Q1: Is this convention confusing? I considered using any-1.1, etc. but that looked a bit dumb. This is confusing. AFAIK there is no neat mapping between .NET and Mono versions and the CLI specs. Q2: Do you think net-x.x should be used for the generic case rather than for Microsoft? .NET is a Microsoft brand. Using it for the generic case would be confuse things. We could maybe use something like net-x.x-equiv, but then we're back to the problem of there being no neat mapping between .NET and Mono versions. Q3: When the runtime under which a test should execute (in a project file) would you rather see the vx.x form or an explicit combo like mono-2.0+net-2.0? An explicit combo like: mono-2.0+mono-2.0.1+mono-2.2+mono-2.4+net-2.0 This would be a great way to flush out regressions. :-) Regards, Jamie. -- http://www.testdriven.net http://twitter.com/jcansdale http://weblogs.asp.net/nunitaddin On Wed, Mar 4, 2009 at 3:13 AM, Charlie Poole char...@nunit.com wrote: Hi All, This is a bit OT for the dev list, but I suspect I'll get more solid answers based on experience here than elsewhere. In NUnit, it is now possible to specify the runtime under which tests should be run. For MS CLRs, I use net-1.0, net-1.1, net-2.0, etc. For mono, I use mono-1.0 and mono-2.0. I took this convention from NAnt. These tags are used in several text files and also appear in dropdowns in the GUI. The problem comes up when I want to indicate that a test must be run under a particular CLR version, without regard to whether it's mono, ms .NET or something else. In that case, I started to use v1.0, etc. but I'm not sure it's very clear. Q1: Is this convention confusing? I considered using any-1.1, etc. but that looked a bit dumb. Q2: Do you think net-x.x should be used for the generic case rather than for Microsoft? If so, what would you expect to see for Microsoft. Q3: When the runtime under which a test should execute (in a project file) would you rather see the vx.x form or an explicit combo like mono-2.0+net-2.0? This is something that is quite easy to change - up to the point where people start using it - so I'd like to get it right the first time! Thanks, Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] ANN: TestDriven.NET 2.5 Beta + Visual Studio Express
Hi Folks, I have just released a version of TestDriven.NET that works with the Visual Studio 2005 Express Editions. It has been tested with C#, VB, C++ and J# Express. For more information about using this feature, please read the following post: http://weblogs.asp.net/nunitaddin/archive/2007/04/02/express-sku-support.aspx This version comes packaged with NUnit 2.4 Final and NUnit 2.2.10. If you have Mono installed a 'Test With... Mono' option will appear. This has been confirmed to work with Mono 1.2.3 and should work with future versions. Best regards, Jamie. -- http://www.testdriven.net http://weblogs.asp.net/nunitaddin ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] OT: Mac OSX Tester needed For an NUnit bug
Hi Charlie, I've heard anecdotally that it no longer occurs. But if there's someone here who could verify whether it really exists in any of the later versions of NUnit, it would be helpful. Here's the result of NUnit 2.2.9 running on Mono 1.2.3.1/OS X 10.4.8: -- unknown-00-17-f2-00-70-80:~/HoldingBay/bin intelmac$ mono nunit-console.exe csharp-sample.dll NUnit version 2.2.9 Copyright (C) 2002-2003 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov, Charlie Poole. Copyright (C) 2000-2003 Philip Craig. All Rights Reserved. OS Version: Unix 8.8.1.0Mono Version: 1.1.4322.2032 .F.F.F.F.N Tests run: 4, Failures: 4, Not run: 1, Time: 0.477 seconds Failures: 1) NUnit.Samples.SimpleCSharpTest.Add : Expected Failure. expected: 6 but was: 5 at NUnit.Samples.SimpleCSharpTest.Add () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 2) NUnit.Samples.SimpleCSharpTest.DivideByZero : System.DivideByZeroException : Division by zero at NUnit.Samples.SimpleCSharpTest.DivideByZero () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 3) NUnit.Samples.SimpleCSharpTest.Equals : Expected Failure (Integer) expected: 12 but was: 13 at NUnit.Samples.SimpleCSharpTest.Equals () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 4) NUnit.Samples.SimpleCSharpTest.ExpectAnException : Expected: System.InvalidOperationException but was System.InvalidCastException at NUnit.Samples.SimpleCSharpTest.ExpectAnException () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] Tests not run: 1) NUnit.Samples.SimpleCSharpTest.IgnoredTest : ignored test -- It looks like it's working fine now. I've submitted this output to the bug but haven't closed it yet. I'll leave that to you. Just one comment. I don't think the following line in the output is very clear: OS Version: Unix 8.8.1.0Mono Version: 1.1.4322.2032 It's actually running Mono 1.2.3.1. The Runtime Version is '1.1.4322.2032'. Has this output changed at all in the latest NUnit 2.4? I did notice some code that finds the real Mono version in the source. It this used anywhere? Thanks, Jamie. -- http://www.testdriven.net http://weblogs.asp.net/nunitaddin On 3/13/07, Charlie Poole [EMAIL PROTECTED] wrote: Hi folks, I have this rather ancient bug that applies NUnit running on OS/X http://sourceforge.net/tracker/index.php?func=detailaid=1011452group_id=10 749atid=110749 I've heard anecdotally that it no longer occurs. But if there's someone here who could verify whether it really exists in any of the later versions of NUnit, it would be helpful. Charlie ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] OT: Mac OSX Tester needed For an NUnit bug
To answer my own question, below is what it looks like with NUnit 2.4. I notice the CLR version is much clearer and now shows: CLR Version: 2.0.50727.42 ( Mono 1.2.3.1 ) --- mono --runtime=v2.0.50727 nunit-console.exe csharp-sample.dll NUnit version 2.4.0 Copyright (C) 2002-2006 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov, Charlie Poole. Copyright (C) 2000-2006 Philip Craig. All Rights Reserved. Runtime Environment - OS Version: Unix 8.8.1.0 CLR Version: 2.0.50727.42 ( Mono 1.2.3.1 ) .F.F.F.F.N Tests run: 4, Failures: 4, Not run: 1, Time: 0.546 seconds Failures: 1) NUnit.Samples.SimpleCSharpTest.Add : Expected Failure. Expected: 6 But was: 5.0d at NUnit.Samples.SimpleCSharpTest.Add () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 2) NUnit.Samples.SimpleCSharpTest.DivideByZero : System.DivideByZeroException : Division by zero at NUnit.Samples.SimpleCSharpTest.DivideByZero () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 3) NUnit.Samples.SimpleCSharpTest.Equals : Expected Failure (Integer) Expected: 12 But was: 13 at NUnit.Samples.SimpleCSharpTest.Equals () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 4) NUnit.Samples.SimpleCSharpTest.ExpectAnException : An unexpected exception type was thrown Expected: System.InvalidOperationException but was: System.InvalidCastException at NUnit.Samples.SimpleCSharpTest.ExpectAnException () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] Tests not run: 1) NUnit.Samples.SimpleCSharpTest.IgnoredTest : ignored test On 3/14/07, Jamie Cansdale [EMAIL PROTECTED] wrote: Hi Charlie, I've heard anecdotally that it no longer occurs. But if there's someone here who could verify whether it really exists in any of the later versions of NUnit, it would be helpful. Here's the result of NUnit 2.2.9 running on Mono 1.2.3.1/OS X 10.4.8: -- unknown-00-17-f2-00-70-80:~/HoldingBay/bin intelmac$ mono nunit-console.exe csharp-sample.dll NUnit version 2.2.9 Copyright (C) 2002-2003 James W. Newkirk, Michael C. Two, Alexei A. Vorontsov, Charlie Poole. Copyright (C) 2000-2003 Philip Craig. All Rights Reserved. OS Version: Unix 8.8.1.0Mono Version: 1.1.4322.2032 .F.F.F.F.N Tests run: 4, Failures: 4, Not run: 1, Time: 0.477 seconds Failures: 1) NUnit.Samples.SimpleCSharpTest.Add : Expected Failure. expected: 6 but was: 5 at NUnit.Samples.SimpleCSharpTest.Add () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 2) NUnit.Samples.SimpleCSharpTest.DivideByZero : System.DivideByZeroException : Division by zero at NUnit.Samples.SimpleCSharpTest.DivideByZero () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 3) NUnit.Samples.SimpleCSharpTest.Equals : Expected Failure (Integer) expected: 12 but was: 13 at NUnit.Samples.SimpleCSharpTest.Equals () [0x0] at 0x0 unknown method at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[]) at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x0] 4) NUnit.Samples.SimpleCSharpTest.ExpectAnException : Expected
Re: [Mono-dev] Regression in String tests
PropertyInfo[] props =
typeof(String).GetProperties();
AssertEquals(props[0].Name, Chars);
AssertEquals(props[1].Name, Length);
I'm curious it know what this is testing for. I thought the ordering
of reflected members was explicitly not guaranteed. IIRC there was
talk of returning them in random order in .NET 2.0 to discourage this
kind of dependency.
Thanks, Jamie.
--
http://www.testdriven.net
http://weblogs.asp.net/nunitaddin
On 3/6/07, Atsushi Eno [EMAIL PROTECTED] wrote:
It is not a regression. Actually the test is quite odd.
[Test]
public void StringProperties()
{
PropertyInfo[] props =
typeof(String).GetProperties();
AssertEquals(props[0].Name, Chars);
AssertEquals(props[1].Name, Length);
}
I'll revert r73699.
Atsushi Eno
Miguel de Icaza wrote:
I just noticed this while running the corlib tests:
Failures:
1) MonoTests.System.StringTest.StringProperties :
String lengths differ. Expected length=6, but was length=5.
Strings differ at index 0.
expected:Length
but was:Chars
---^
at MonoTests.System.StringTest.StringProperties () [0x00010]
in /home/cvs/mcs/class/corlib/Test/System/StringTest.cs:1807
at 0x0 unknown method
at (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
at System.Reflection.MonoMethod.Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x00040]
in /home/cvs/mcs/class/corlib/System.Reflection/MonoMethod.cs:143
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Regression in String tests
PropertyInfo[] props =
typeof(String).GetProperties();
AssertEquals(props[0].Name, Chars);
AssertEquals(props[1].Name, Length);
I'm curious it know what this is testing for. I thought the ordering
of reflected members was explicitly not guaranteed. IIRC there was
talk of returning them in random order in .NET 2.0 to discourage this
kind of dependency.
Thanks, Jamie.
--
http://www.testdriven.net
http://weblogs.asp.net/nunitaddin
On 3/6/07, Atsushi Eno [EMAIL PROTECTED] wrote:
It is not a regression. Actually the test is quite odd.
[Test]
public void StringProperties()
{
PropertyInfo[] props =
typeof(String).GetProperties();
AssertEquals(props[0].Name, Chars);
AssertEquals(props[1].Name, Length);
}
I'll revert r73699.
Atsushi Eno
Miguel de Icaza wrote:
I just noticed this while running the corlib tests:
Failures:
1) MonoTests.System.StringTest.StringProperties :
String lengths differ. Expected length=6, but was length=5.
Strings differ at index 0.
expected:Length
but was:Chars
---^
at MonoTests.System.StringTest.StringProperties () [0x00010]
in /home/cvs/mcs/class/corlib/Test/System/StringTest.cs:1807
at 0x0 unknown method
at (wrapper managed-to-native)
System.Reflection.MonoMethod:InternalInvoke (object,object[])
at System.Reflection.MonoMethod.Invoke (System.Object obj,
BindingFlags invokeAttr, System.Reflection.Binder binder,
System.Object[] parameters, System.Globalization.CultureInfo culture)
[0x00040]
in /home/cvs/mcs/class/corlib/System.Reflection/MonoMethod.cs:143
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [Patch] ConfigurationFile should be relative to the ApplicationBase
I recently hit an issue with Mono not being able to find my .config files. My application was developed using .NET so this is a discrepancy between Mono and .NET. AFAIK this behavior isn't documented anywhere. AppDomainSetup setup = new AppDomainSetup(); setup.ApplicationBase = app_base; setup.ConfigurationFile = blar.config; .NET would look for the .config file at 'app_base\blar.config'. Mono looks for the .config file in the current directory. If the ApplicationBase isn't specified in .NET a MemberAccessException is thrown when the ConfigurationFile property is accessed (assuming it isn't an absolute path). I've attached patches for unit tests and a fix for this. This is my first patch so please let me know if I'm doing it right. Thanks, Jamie. -- http://www.testdriven.net http://weblogs.asp.net/nunitaddin ConfigRelativeToAppBase.patch Description: Binary data ConfigRelativeToAppBaseTests.patch Description: Binary data ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
