Re: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
Well, ideally there should be no nunit shipped with mono. Or at least it would be nice to have mono/nunit20 kept in sync with nunit.org repository. As for my changes they are mostly mono build system specific except for the config file. Is there any reason why nunit use this kind of hardcoding the version of used mscorlib? Isn't it possible to use some command line option to switch the choosen mscorlib? 2005/9/9, Charlie Poole [EMAIL PROTECTED]: Ideally, I'd like to see the mono version of nunit that we build kept in synch with the one that you guys are building. So please let us know of changes that you think should be reflected back to NUnit. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien Pouliot Sent: Thursday, September 08, 2005 11:18 PM To: Kamil Skalski Cc: mono-devel-list Subject: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile Hello, On Thu, 2005-08-09 at 23:22 +0200, Kamil Skalski wrote: Currently nunit distributed with mono is rather unusable with 2.0 there are, at least, 14236 tests saying otherwise http://mono.ximian.com/tests/displayTestResults.php?profile=1 distro=0 but I agree it may not be perfect for 2.0 ;-) assemblies. I attach a patch, which makes it fully usable: - nunit-console.exe.config is removed, because it enforces choosing 1.1 corlib assemblies in preference over 2.0 ones make sense as our main target is still 1.1 assemblies (and the contents of this config are mostly related to making nunit work on 1.0 .NET, which is not an issue with mono) - nunit-console2 is added, I'm copying the design of monop2 and wsdl2 - the nunit dlls from 2.0 are now installed you mean installed in the GAC ? if so what happens when 2.0 compiled assemblies overwrites the assemblies compiled with 1.1 (same name, version# and public key) ? does the 1.1 (default) profile still works ? Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? I think the real question is is it working ?, i.e. have you tested this on the mcs tree and ensure every test target are still working ? -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: SPAM-LOW: Re: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
Hi Kamil, Well, ideally there should be no nunit shipped with mono. That doesn't seem to make sense, since people who build mono from source wouldn't be able to run the tests. If you ship tests, you probably have to ship the ability to run those tests. Or at least it would be nice to have mono/nunit20 kept in sync with nunit.org repository. I'd like to see that, but we on the NUnit would have to get more mono-oriented, or some mono folks would need to help us get the code to that state. As for my changes they are mostly mono build system specific except for the config file. Is there any reason why nunit use this kind of hardcoding the version of used mscorlib? Isn't it possible to use some command line option to switch the choosen mscorlib? We experimented with this approach around 2.2.1, but couldn't get it to work with all combinations of installed frameworks. Ideas are welcome! Whatever we do has to work with .NET 1.0, 1.1 and 2.0 as well as mono. Up to now, our goal has been to do this without making platform-specific binaries. That is, I would execute the same nunit code under mono on my windows machine as when I execute it under MS .NET. Charlie 2005/9/9, Charlie Poole [EMAIL PROTECTED]: Ideally, I'd like to see the mono version of nunit that we build kept in synch with the one that you guys are building. So please let us know of changes that you think should be reflected back to NUnit. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien Pouliot Sent: Thursday, September 08, 2005 11:18 PM To: Kamil Skalski Cc: mono-devel-list Subject: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile Hello, On Thu, 2005-08-09 at 23:22 +0200, Kamil Skalski wrote: Currently nunit distributed with mono is rather unusable with 2.0 there are, at least, 14236 tests saying otherwise http://mono.ximian.com/tests/displayTestResults.php?profile=1 distro=0 but I agree it may not be perfect for 2.0 ;-) assemblies. I attach a patch, which makes it fully usable: - nunit-console.exe.config is removed, because it enforces choosing 1.1 corlib assemblies in preference over 2.0 ones make sense as our main target is still 1.1 assemblies (and the contents of this config are mostly related to making nunit work on 1.0 .NET, which is not an issue with mono) - nunit-console2 is added, I'm copying the design of monop2 and wsdl2 - the nunit dlls from 2.0 are now installed you mean installed in the GAC ? if so what happens when 2.0 compiled assemblies overwrites the assemblies compiled with 1.1 (same name, version# and public key) ? does the 1.1 (default) profile still works ? Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? I think the real question is is it working ?, i.e. have you tested this on the mcs tree and ensure every test target are still working ? -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Kamil Skalski http://nazgul.omega.pl ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile
Ideally, I'd like to see the mono version of nunit that we build kept in synch with the one that you guys are building. So please let us know of changes that you think should be reflected back to NUnit. Charlie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sebastien Pouliot Sent: Thursday, September 08, 2005 11:18 PM To: Kamil Skalski Cc: mono-devel-list Subject: SPAM-LOW: Re: [Mono-dev] [PATCH] make nunit work out of the box on 2.0 profile Hello, On Thu, 2005-08-09 at 23:22 +0200, Kamil Skalski wrote: Currently nunit distributed with mono is rather unusable with 2.0 there are, at least, 14236 tests saying otherwise http://mono.ximian.com/tests/displayTestResults.php?profile=1 distro=0 but I agree it may not be perfect for 2.0 ;-) assemblies. I attach a patch, which makes it fully usable: - nunit-console.exe.config is removed, because it enforces choosing 1.1 corlib assemblies in preference over 2.0 ones make sense as our main target is still 1.1 assemblies (and the contents of this config are mostly related to making nunit work on 1.0 .NET, which is not an issue with mono) - nunit-console2 is added, I'm copying the design of monop2 and wsdl2 - the nunit dlls from 2.0 are now installed you mean installed in the GAC ? if so what happens when 2.0 compiled assemblies overwrites the assemblies compiled with 1.1 (same name, version# and public key) ? does the 1.1 (default) profile still works ? Optionally we could leave the appSettings !--Specify the location to be used by .NET for the cache -- add key=shadowfiles.path value=%temp%\nunit20\ShadowCopyCache / /appSettings section in nunit-console.exe.config and remove any other contents. Should I commit? I think the real question is is it working ?, i.e. have you tested this on the mcs tree and ensure every test target are still working ? -- Sebastien Pouliot email: [EMAIL PROTECTED] blog: http://pages.infinit.net/ctech/ ___ 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
