Separate assembly for InternalTrace and other common classes

[CharliePoole]

InternalTrace is implemented in nunit.engine.core, which we plan to eliminate. We would then need to replicate it in nunit.engine, nunit.agent.core and NUnit.Extensibility. What's more, the framework has its own copy of InternalTrace.

In addition, a number of other useful classes are currently shared across projects by links to the source code. This is slightly messy and can only get worse.

I propose to create a single NUnit.InternalTrace nunit.common assembly to be referenced by each project that needs to have it. In fact, I'll be re-creating it, since we had one in the past.

This is an experimental issue - what we used to call a "spike." If it seems viable, I'll continue it. If not, I'll try to abandon it quickly, with minimal time invested. UPDATE: The strikeout above definitely show the experimental nature of this issue. :-)

Since I have already implented InternalTrace centrally for TestCentric I'll start by stealing that code. Of course, nunit-console is organized quite differently to TestCentric, with multiple projects under one solution, so changes will probably be needed.

I'll report back here when I either remove this issue or remove the experimental label.

@nunit/engine-team At this point, it would be good to put in your suggestions, including whether or not you think this is a good idea. :-)

[manfred-brands]

I am normally for sharing coding over copy & digress over time.

So a separate nunit.common repository with one or more nuget packages is fine by me.
There is also the Guard class.

The downside is another dependency on a another repository.
As it is used by multiple projects, we need to make sure it stay compatible.
But if it is for infrequent changing code, that should be fine.

[CharliePoole]

@manfred-brands

At least initially, I don't think this assembly would be a separate project or package. I'd keep it in the nunit-console solution. Pluggable agents would get it bundled with the new nunit-agent-core package. That package can be published right out of the solution, as we now do for the engine library.

That could change, of course, but only if we see the need for more packages arise. In this case, I guess that would be the point where some other project, e.g. NUnitLite, wanted to use it.

[CharliePoole]

@manfred-brands

Yes, an nunit.common assembly which contains both the internal trace stuff as well as Guard, CallerExpressionArgumentExpressionAttribute and possibly other things does make sense. I'll update the description.