Skip to content
This repository has been archived by the owner on Jan 8, 2023. It is now read-only.

Remove the dependency on a specific version of the framework #48

Open
rprouse opened this issue Jan 10, 2016 · 8 comments
Open

Remove the dependency on a specific version of the framework #48

rprouse opened this issue Jan 10, 2016 · 8 comments

Comments

@rprouse
Copy link
Member

rprouse commented Jan 10, 2016

The runners currently reference a specific version of NUnit.Framework. We should use reflection or a mini engine to load the framework to break that dependency. If we merge the nunit.driver PR nunit/nunit#1170, that could be used to break this dependency.

@CharliePoole
Copy link
Contributor

@rprouse I might have misunderstood, but I though we had decided that having a separate runner per framework version was OK for what the runners are used for. If we spend time on making the runners use reflection, aren't we taking away from the "ultimate" approach of using a communications interface?

@rprouse
Copy link
Member Author

rprouse commented Jan 11, 2016

I think this is important either way. If the ultimate approach is that we communicate from the desktop, then the Xamarin runners can be thought of as platform specific agents. In that case, they need to be able to load the framework in a version independent way. To do that, we need to load the framework through some sort of reflection.

My current thinking is that the nunit.driver serves that purpose. I think the naming may cause confusion between us though. Right now, the driver just loads the framework and allows you to execute tests, but I am pretty sure that it will grow slightly into a mini/micro engine, but not loaded from the API, with no addins and very few services.

This is just a step towards making the Xamarin runners platform agents, but I also think that they need to be special agents in that they can be run from the desktop like a classic agent, or run manually with UI on the devices as they are now.

@ChrisMaddock
Copy link
Member

I thought I'd have a play around with this.

Have come up against one issue that the portable agent is netstandard 1.3, whereas (I think!) win phone 8.1 only supports up to netstandard 1.2.

@rprouse - I don't follow the .netcore stuff so closely - what's the appropriate way to handle this - a netstandard 1.2 version of the portable agent?

@rprouse
Copy link
Member Author

rprouse commented Oct 18, 2016

I was actually thinking of dropping the older WinPhone support and just supporting Android, iOS and UWP. There hasn't been any interest in the support for the older WinPhone platforms, only for the three listed.

@ChrisMaddock
Copy link
Member

That would be another solution! It seems quite easy to reverse, if there is outcry. 😄

@ChrisMaddock
Copy link
Member

ChrisMaddock commented Oct 18, 2016

Currently blocked by nunit/nunit.portable.agent#13 and #64

@ChrisMaddock
Copy link
Member

Removing from 3.2, this is instead going to wait until some sort of portable engine solution.

@ChrisMaddock ChrisMaddock removed their assignment Nov 25, 2016
@ChrisMaddock
Copy link
Member

Copying the below comment over here, so there's a good record.

The .NET Standard engine required to do #48 in the way we want to is actually nearly ready - the work is done in a branch here: https://github.com/nunit/nunit-console/tree/issue-388b - it just needs the final touches, review and merging etc. As such, it's probably not the best time to start work on plugging in the portable agent, as we'll want to replace it again within the next few months.

So, I'd recommend not starting on #48 quite yet - although if you'd be interested in picking that up once the .NET Standard engine is merged - we'd love the help then!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants