Decide what features will be supported in version 4.0

[CharliePoole]

In fact, we don't yet know whether there will be a 4.0! However, in order to decide that, we first need to figure out what new features it would need to be viable and whether we can support them. A bit circular, but there you have it. :-)

[CharliePoole]

File types currently supported by the extension (plus one we don't support):

• .sln - Visual Studio Solution

• .csproj - C# Project (See formats below)

• .vbproj - Visual Basic Project (See formats below)

• .fsproj - F# Project (See formats below)

• .vjsproj - Visual J# Project (Product discontinued 2007, de-supported 2017)

• .vcproj - Old-style Visual C++ Project (Superseded in 2010)

• vcxproj - Used for Visual C++ since 2010 - UNSUPPORTED

File Formats

Some file types support multiple formats. Our current code identifies three formats:

• Legacy - Root XML Element is VisualStudioProject
  Supported for C#, VB, F# and C++. Format is slightly different for C++, so we use separate code to parse it.

• Non-Sdk - Root Element is Project and has no Sdk attribute
  Supported for C#, VB and F#. This was our "new format" through 2017.

• SDK - Root Element is Project with an Sdk attribute
  Partially supported for C#, VB and F#. That is, we have added fixes to support SDK projects on an adhoc basis.

@nunit/engine-team @nunit/core-team Comments on what we should continue to support / remove / add ?

[jnm2]

Seen, but no comments in particular. I haven't used the project loader.

[rprouse]

To be honest, I don't think I've used the project loader in more than a decade and I don't think many people do. All modern CI/CD systems use explicit names or globs to find test assemblies and every project that I've seen uses a standard naming convention for tests because of that.

I wish this project wasn't included by default so we could get some true download numbers, but my vote would be to deprecate it.

[CharliePoole]

I have seen a number of console questions or issues where people use the project (or solution) on the command-line. I used to reply "just don't do that" but I found that the answer was not terribly well received. :-)

If we deprecate the the extension rather than dropping it, we will still need to make some set of features work for the 4.0 engine. I was trying to define the minimal set we need to support if we support it at all.

Are you actually suggesting we should drop it? That's a valid point of view, but I'd like to be clear what you mean.

[manfred-brands]

I also think it is outside scope. It is impossible to support for complex project.
At work we have one big solution (500+ project) using rake (ruby make), nunit uses cake others custom scripts. Even those that do use msbuild, might require dotnet tools installed or .target files from referenced nuget packages.

[CharliePoole]

@manfred-brands Same question as to Rob... are you saying we shouldn't do a 4.0 at all? That is, cancel the project as it's already a given that the 3.x builds won't work with the 4.0 engine? I want to be really clear about what we're deciding here.

[manfred-brands]

@CharliePoole Yes. NUnit should be about testing, not about building.
We should integrate with dotnet test and allow testing on already compiled binaries.

[CharliePoole]

@manfred-brands OK that's clear. Let's see what others say.

[CharliePoole]

@manfred-brands Just noticed something in your last comment, which I should answer...

There is no thought of having NUnit run against anything other than compiled binaries. The project loader extension doesn't build anything, and I agree that would be out of scope. It merely examines a project to ascertain what output assemblies it creates and tells the engine about them. Frankly, that's complicated enough.

[manfred-brands]

It merely examines a project to ascertain what output assemblies it creates and tells the engine about them

@CharliePoole good to know, but my opinion hasn't changed. There are many different ways to define the output directory, including in files not referenced like Directory.Build.props.

[CharliePoole]

I guess we have all the comments we're going to have, so here's a plan...

As has been separately discussed, we will not continue to supply this extension unless the approach proposed by @rprouse in #25 can be made to work. I'm currently working on a spike to try it out. Consequently, there are two possible paths here:

1. The Spike Doesn't work or is not practical

   In that case, I'll do a final release of the extension (version 4.0) with no improvements but capable of running under the 4.0 engine. There will be no further maintenance of the extension.

2. The Spike Works

   In that case, we'll use MsBuild and support only the languages and format it supports. Anyone using legacy formats that MsBuild does not support will need to stick with the 3.0 console.

Either outcome will significantly reduce our level of effort in supporting extensions.

[mikkelbu]

I can live with both paths. I think I've used this extension at my old company (a couple of years ago), but only for .sln-files (in the SDK format I think). That being said I think it is fine to accept that we don't have time to solve every problem.

[CharliePoole]

Leaving this for the new lead to handle