-
Notifications
You must be signed in to change notification settings - Fork 47
Remove the dependency on a specific version of the framework #48
Comments
@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? |
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. |
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? |
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. |
That would be another solution! It seems quite easy to reverse, if there is outcry. 😄 |
Currently blocked by nunit/nunit.portable.agent#13 and #64 |
Removing from 3.2, this is instead going to wait until some sort of portable engine solution. |
Copying the below comment over here, so there's a good record.
|
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.
The text was updated successfully, but these errors were encountered: