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

TargetFrameworkVersion of Microsoft.Azure.Devices.Gateway package #203

Closed
yfakariya opened this issue Apr 11, 2017 · 5 comments
Closed

TargetFrameworkVersion of Microsoft.Azure.Devices.Gateway package #203

yfakariya opened this issue Apr 11, 2017 · 5 comments

Comments

@yfakariya
Copy link
Contributor

Hi team,

I'm using gwsdk .NET Core binding in part of my solution which is built as netstandard1.4 based class libraries to enable unit testing on .NET Framework toolset.
However I cannot use the binding as is because the Microsoft.Azure.Devices.Gateway's target framework version is currently netstandard1.6 nevertheless it does not depend on any features require netstandard 1.6.

I cannot imagine other scenarios to justify change the .NET Standard version, but I think it is better to specify lower version if possible. Is it possible to change target framework lower such as netstandard1.1?

@aribeironovaes
Copy link
Contributor

aribeironovaes commented Apr 11, 2017 via email

@yfakariya
Copy link
Contributor Author

Hi @aribeironovaes, thank you for quick response.
As far as my environment, I succeeded to change <TargetFrameworkVersion> to netstandard1.1 and it looked fine (can be compiled and it just works). It is OK to make PR when I finish extra testing.

But I don't understand well about meaning of your "the version of the SDK". If it means NetStandard.Library package version, there are no problem to change to netstandard1.1 because .NET Standard version (it just defines API compatibility set) is not related to .NET Core/SDK version (currently 1.0.4 and 1.1.1).

I'm also not sure that you have plan to add APIs which only exist in netstandard1.6 like AssemblyLoadContext. If so, changing to netstandard1.x is not acceptable.

@damonbarry
Copy link
Member

We'll change our <TargetFrameworkVersion> to netstandard1.3 (because we depend on the device SDK, and that's what it supports). We'll get this checked into master soon.

@damonbarry damonbarry added the bug label Apr 13, 2017
@yfakariya
Copy link
Contributor Author

Thank you!

@damonbarry
Copy link
Member

Fixed in the latest release.

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