NUnit dll hell, annoying reference issues when cross-compiling between Windows and Linux.

[Chris Capon]

Hi.

So, I'm developing software primarily with Visual Studio under Windows, but also cross compiling the source using Mono under Linux.  The program is intended to run in both environments and NUnit is being used to test the library functionality.

Under Windows, when linking to the NUnit.framework, the installed 2.6.3 package creates this reference:

nunit.framework, Version=2.6.3.13283, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL

Under Linux, the installed 2.6.3 package creates a different reference when linking to the framework:

nunit.framework, Version=2.6.3.0, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77

Notice how the PublicKeyToken is identical in both cases.

When compiling the source under Linux, the Windows nunit.framework reference can't be resolved.  After I manually switch the project to the Linux reference, everything compiles cleanly.  But what a pain!  I'd like to automate the build process so it just updates the code from revision control and builds the runtime.  The rest of the project all cross compiles cleanly, only this framework reference fails.

Why would the two NUnit framework assemblies (with the same major version numbers and PublicKeyToken) require a reference change?

Is there some way to deal with this reference change cleanly or do I have to massage the project file each time a new build is required?

Much thanks for your help.

Chris.

[Charlie Poole]

Our release has version 2.6.3.13283. On your Linux system, you are running a version of NUnit from another source. I'd be curious to know what that source is, so we can address the issue with them.

The fix for you is pretty simple: just use our assembly on both systems. Place a copy of nunit.framework.dll in a convenient location and reference it.

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nunit-discus...@googlegroups.com.
To post to this group, send email to nunit-...@googlegroups.com.
Visit this group at http://groups.google.com/group/nunit-discuss.
For more options, visit https://groups.google.com/d/optout.

[Chris Capon]

Thank you for your response.  I will give that a try.

If you want to address the difference in version numbers, the Linux system is Debian running the current Testing distribution.  Version 2.6.3 is the latest stable version they provide (although they refer to it as "nunit 2.6.3+dfsg-1").  The package installs the nunit.framework in the GAC.  As Debian is the parent for a number of other distributions (like Ubuntu) the same problem may exist in those as well.

Debian's package management system is designed to resolve inter-dependencies through version numbers.  Their current handling of the NUnit package does not allow for multiple versions to be simultaneously installed.  This restricts which version of NUnit I can select under Windows.

Cheers and thanks.

[Greg Young]

Its generally a bad idea to make people install libs like this anyways.

You can see we do just this in eventstore here:

https://github.com/EventStore/EventStore/tree/release-v3.4.0/tools/nunit-2.6.3

--
Studying for the Turing test

[Rob Prouse]

Greg,

Can't you use NuGet to get the official builds of NUnit? It would ensure you get the same assemblies across platforms without checking them into your repository.

Rob

Rob Prouse

 

I welcome VSRE emails. Learn more at http://vsre.info/

[Charlie Poole]

Hi Chris,

I thought that was probably it. Debian requires all packages in the
distro to be built from source. Apparently, they replaced the logic in
our nant script, which inserts a date-based build number, with a
hard-coded zero. That makes sense since they are building it
routinely, long after the date of our release. It would be best if
they hard-coded the same build number as our release.

I'll file a bug with them to fix this and one for us to stop
generating date-based versions in the build script!

Charlie

[Charlie Poole]

Greg,

Nobody makes them! There are about four different ways to use the framework:
* Add it to your repository
* Use nuget
* Install on your system somewhere
* Build it from source as a part of the project

These days, most seem to prefer NuGet - which would be a useful option
for Chris as well.

Charlie

[Charlie Poole]

Hi Rob,

I think you may have meant that for Chris, who has the windows/linux
problem. :-)

In a linux environment, it's very common to use what comes with the
distro. If that's not used, people tend to prefer a native package to
a zip install or even nuget.

WRT the framework, I think nuget is the ideal option these days and it
works well on Linux, as we know. All our CI builds use it to restore
the packages we reference.

For the "full" NUnit, I think it's up to us to eventually provide some
linux packages. The distros are notably slow in getting new releases
and Debian is (by design) slower than most.

Charlie

[Greg Young]

And we have a dependency to manage a dependency. If I hit a few then I
would consider it. I am not alone in my thinking on this see most C
projects/Go projects.

[Charlie Poole]

Hi Greg,

You're not the only one to prefer this. That's why we started
providing a zip in addition to an msi years ago. It's primarily there
for people who want to check the binaries into their repo.

All the members of the NUnit team are developers and as such have
strong opinions about the right way to develop. As a project, we don't
impose anything beyond the vision we have for NUnit itself.

Charlie

[Chris Capon]

Thanks Charlie.

I have posted two bug reports with the Debian maintainer as well.

1) Ensure that the current release version # exactly matches the equivalent version available in the download section of NUnit.org (for cross compatibility purposes).

2) Request that they also provide packages for historical versions (not just the latest release).  This removes the dependency for all applications using NUnit to be constrained to a single, current version.

Cheers,

Chris.

[Chris Capon]

For those who follow, 

I found a solution to the immediate problem. 

On the Windows side and from within Visual Studio, after adding a reference to the nunit.framework, it is possible to right-click on the reference under project / References and select Properties from the drop-down menu.

In the Properties window, it is possible to alter some of the settings.  A boolean property called Specific Version can be switched from True to False.

Within the project file, the reference then looks like this:

    <Reference Include="nunit.framework, Version=2.6.3.13283, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">

      <SpecificVersion>False</SpecificVersion>

    </Reference>

 

After this, the project compiled without complaint or modification under both Windows and Debian GNU/Linux.  I don't know to what degree the version numbers can differ once this flag is set, but at least it allowed the build number in this case to be different.

Much Thanks for all your help.

Chris.

[Charlie Poole]

I haven't filed the bug yet, so maybe I'll simply comment on yours.
Can you post the links?

On Thu, Dec 3, 2015 at 8:04 AM, Chris Capon <tta...@gmail.com> wrote:
> Thanks Charlie.
> I have posted two bug reports with the Debian maintainer as well.
>
> 1) Ensure that the current release version # exactly matches the equivalent
> version available in the download section of NUnit.org (for cross
> compatibility purposes).
>
> 2) Request that they also provide packages for historical versions (not just
> the latest release). This removes the dependency for all applications using
> NUnit to be constrained to a single, current version.
>
> Cheers,
> Chris.
>
>
> On Wednesday, December 2, 2015 at 12:19:05 PM UTC-5, charlie wrote:
>>

[Chris Capon]

Hi Charlie.

I'd appreciate it.  They don't seem willing to address the issue and are blaming upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806890

And the multiple versions report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=806896

Cheers,

Chris.