---- Reported by matt@use.net 2005-12-05 22:06:48 MST ----

using NUnit.Framework; 
 
[TestFixture] 
public class Fixture 
{ 
  [Test] 
  public void test() 
  { 
    int? value; 
    Assert.IsNull(value); 
  } 
}  
 
gmcs -r:nunit.framework -t:library test.cs  
nunit-console test.dll 
 
 
Actual Results: 
giant crash in native code 
 
Expected Results: 
should run just fine OOTB 
 
 
Additional Information: 
if you copy 2.0-compiled nunit*.dll into the right place and set several 
environment variables to point to said right place, it runs.



---- Additional Comments From bmaurer@users.sf.net 2005-12-06 00:34:40 MST ----

Nunit is compiled with 1.0, so it will load the 1.0 corlib, this would
happen with the upstream nunit dlls as well.



---- Additional Comments From nazgul@omega.pl 2005-12-06 13:46:39 MST ----

Actually, nunit (from nunit.org) is now packaged in new versions:
nunit.2.2.3 and nunit-2.0-2.2.3 and the latter allows compiling tests
using .NET 2.0. The issue comes back from time to time and indeed,
this is a mono packaging bug, because it do not split installed nunit
into 1.0 and 2.0 version.

I suggest reopening this bug and using it as a placeholder for making
nunit-2.0 mono packages work.



---- Additional Comments From matt@use.net 2005-12-07 09:31:12 MST ----

Kamil's interpretation is correct, so I am reopening. If I run 
lib/mono/2.0/nunit-console.exe, it should use a 2.0-compiled 
nunit*.dll so my test case above works correctly. 



---- Additional Comments From nazgul@omega.pl 2005-12-07 14:51:25 MST ----

There were several discussions about this (see for example
http://lists.ximian.com/pipermail/mono-devel-list/2005-October/015413.html).

Currently the problem is that GAC can holds only one version of nunit
assemblies and its versioning schema do not allow making some sane
separation here (and Charlie Poole seems to have resigned from the
idea of different version numbers for 1.1 and 2.0 profiles as proposed
in
http://lists.ximian.com/pipermail/mono-devel-list/2005-November/015593.html).

One nice idea to consider is to disable installation of nunit
assemblies into gac (another one from Charlie
http://lists.ximian.com/pipermail/mono-devel-list/2005-December/016018.html)
I didn't try this, but it seems feasible, just keep nunit assemblies
in the same directory as nunit-console and make nunit.pc point to this
 directory.






---- Additional Comments From charlie@nunit.com 2005-12-07 17:08:28 MST ----

I have indeed temporarily abandoned the use of a separate version
number for equivalent builds of nunit under 1.1 and 2.0. If there's a
fundamental problem with doing this, I can change it. However, in the
windows environment, only nunit.framework is placed in the gac - and
we're considering changing that.

What if nunit were treated as a separate product, rather than part of
mono? Then we could have lib/NUnit 2.2, lib/NUnit 2.4, etc. Developers
need to have multiple versions installed, and I'd dearly love to make
it possible for mono developers to work on NUnit.



---- Additional Comments From vargaz@gmail.com 2005-12-08 14:44:05 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO76945 has been marked as a duplicate of this bug. ***



---- Additional Comments From robertj@gmx.net 2005-12-08 20:40:13 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO76946 has been marked as a duplicate of this bug. ***



---- Additional Comments From nazgul@omega.pl 2005-12-11 10:03:37 MST ----

Created an attachment (id=168931)
Patch for installing nunit compiled with 1.1 and 2.0 profiles separately




---- Additional Comments From nazgul@omega.pl 2005-12-11 10:07:01 MST ----

Hi, I attached a patch, which changes way the mono's version of nunit
is installed. Now dlls are not installed into the GAC, but into
/prefix/mono/nunit/ and /prefix/mono/nunit2/ directories. I made
changes to mono-nunit.pc and nunit-console generation to point to the
new directories. Also the nunit-console2 and mono-nunit2.pc generation
(and installation) was added.

Patch works for me, but of course it needs some verification. Any
comments welcome.



---- Additional Comments From nazgul@omega.pl 2005-12-11 10:11:16 MST ----

One more thing, in my mono 1.1.9 installation I can see gnunit and
gnunit2, but I can't find their sources in mono tree. Their
installation directories need also to be tweaked for sure.



---- Additional Comments From bmaurer@users.sf.net 2005-12-12 01:22:58 MST ----

I personally don't like mono/nunit / mono/nunit2. The 2 looks like it
is describing the nunit version. Also, need to change gnunit to have a
2.0 targeted version.



---- Additional Comments From nazgul@omega.pl 2005-12-12 14:27:56 MST ----

After some more discussion with Charlie I tried the scenario, which
works fine with latest nunit on windows - to run 2.0 tests using nunit
binaries compiled for 1.1, but with tweaked config file. It works
fine, so I will prepare a completely new (and much simpler) patch to
just use different config file for mono/2.0/nunit-console.exe and to
add nunit-console2 script.



---- Additional Comments From nazgul@omega.pl 2005-12-12 16:29:46 MST ----

Created an attachment (id=168932)
This patch installd specialized nunit-console.exe.config files for 1.0 and 2.0 profiles




---- Additional Comments From charlie@nunit.com 2006-01-02 16:47:29 MST ----

Everyone should be aware that running NUnit - whichever compile -
under 2.0 solves the initial bug with int? but not all possible bugs. :-)

For example, in order to make all combinations of int and int? work
with Assert.AreEqual, I woule have to add 2.0-specific code to NUnit.
As of now, we aren't adding such code - I expect to do it for 3.0.

In specific cases, I've been able to make such tests work by creating
a derived Assert class internal to the test itself and adding the
appropriate methods. For example...

        private class Assert : NUnit.Framework.Assert
        {
            public static void AreEqual(int expected, int? actual)
            {
                Assert.AreEqual((int?)expected, actual);
            }
            public static void AreEqual(int? expected, int actual)
            {
                Assert.AreEqual(expected, (int?)actual);
            }
        }





---- Additional Comments From rharinath@novell.com 2006-01-10 11:02:43 MST ----

A variant of Kamil's patch has been committed as SVN r55295.


Imported an attachment (id=168931)
Imported an attachment (id=168932)

Unknown operating system unknown. Setting to default OS "Other".