Mono.Cecil no longer supports .NET 2.0

[CharliePoole]

@rprouse commented on Thu Dec 31 2015

The mono.cecil project dropped support for .NET 2.0 back in May, jbevain/cecil#220

Since our engine is compiled 2.0, we cannot update mono.cecil once they release a new version. Currently, their minimum framework version is .NET 3.5.

I was looking for a newer release of mono.cecil that has a PCL version. It isn't released yet, but it is needed for a portable engine.

Options,

1. Move the console/engine to .NET 3.5
2. Don't upgrade
3. Create our own NuGet package that contains the older 2.0 version of the assembly and the newer PCL version 👎
4. ???

Microsoft's end of support for .NET 2.0 is in April.

This is blocking #677 #1138 and to a lesser extent #362

---

@CharliePoole commented on Thu Dec 31 2015

Potentially a big deal! I'll start with the list of blocked issues:
#677 As it says in the description, it's not clear if this will be a true "engine" In fact, this could be the defining issue where we decide not to go the engine route.
#1138 I'm not sure there is a problem here since this refers (in my mind anyway) to an engine running on the desktop. What we need to find out is whether an engine running under .NET 2.0/3.5 is able to analyze assemblies built for other targets. I don't see why not, since they are not actually loaded. Consider that we are already analyzing .NET 4.5 assemblies. Of course, this needs to be tested on a VM that has only .NET 2.0 or 3.5 installed.
#362 I don't understand why you say this would be blocked.

---

@CharliePoole commented on Thu Dec 31 2015

It's not clear to me if 2.0 support was actually dropped rather than just talked about. PR jbevain/cecil/#220 looks like it was closed without merging. Of course, there is a good chance it will be at some point.

---

@rprouse commented on Thu Dec 31 2015

The current release on NuGet has 2.0, but no PCL. The nuspec currently checked into master no longer has 2.0 and includes PCL, so the next release will drop support.

---

@CharliePoole commented on Thu Dec 31 2015

I think we need to define our own goals in "supporting" .NET 2.0.

I have always thought of two different kinds of support for runtimes.

1. We will run tests under that runtime.
2. Our runners will execute under that runtime.

Currently, our runners all execute under 2.0 and higher and we can run tests under 2.0 and higher, which makes it seem like 1 and 2 are the same.

However, in NUnit 2.6.4 our runners ran under .NET 2.0 and higher and supported test execution under .NET 1.1, which helps remind us that there is a difference.

I considered requiring .NET 3.5 for the 3.0 console runner, while still supporting 2.0 for test execution. I didn't do it for a few reasons...

1. It seemed better to support folks who test apps on machines with .NET 2.0 only.
2. There is almost no difference between 2.0 and 3.5.
3. Our codebase was already designed for 2.0.

In NUnit V2, supporting execution under a lower-level runtime than the one we use for NUnit itself required creation of separate builds for some components.

In 3.0, we already have a version of the framework for .NET 2.0. But if we were forced to use 3.5, we would have to create a separate 2.0 version, not using Cecil, along with a 2.0 agent to run in a separate process. Alternatively, we would execute 2.0 tests under 3.5.

None of this seems undoable, but I thnk we should first decide what we want to support and what we mean by support. I don't think MS's dropping of support (which means an entirely different thing for them) has much to do with us.

---

@CharliePoole commented on Thu Dec 31 2015

When the new release comes out, we should make sure we don't upgrade until
this is resolved.

On Thu, Dec 31, 2015 at 12:15 PM, Rob Prouse notifications@github.com
wrote:

The current release on NuGet has 2.0, but no PCL. The nuspec currently
checked into master no longer has 2.0 and includes PCL, so the next release
will drop support.

—
Reply to this email directly or view it on GitHub
nunit/nunit#1168 (comment).

[ChrisMaddock]

Closing this. We're currently using two different versions of Mono.Cecil for different platforms, and @CharliePoole is investigating removing it as a dependency entirely.