NetworkInterface.GetAllNetworkInterfaces throws on UWP

[clairernovotny]

I’m using the “final” .NET Core bits off of the MyGet feed and ran into an issue trying to use System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces(). The method throws on UWP with a NotImplementedException.

    System.Net.NetworkInformation.dll!System.Net.NetworkInformation.NetNativeNetworkInterface.GetNetworkInterfaces()    Unknown
    System.Net.NetworkInformation.dll!System.Net.NetworkInformation.NetworkInterfacePal.GetAllNetworkInterfaces()   Unknown
    System.Net.NetworkInformation.dll!System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()  Unknown
>   Zeroconf.dll!Zeroconf.NetworkInterface.NetworkRequestAsync(byte[] requestBytes, System.TimeSpan scanTime, int retries, int retryDelayMilliseconds, System.Action<string, byte[]> onResponse, System.Threading.CancellationToken cancellationToken) Line 28  C#
    Zeroconf.dll!Zeroconf.ZeroconfResolver.ResolveInternal(System.Collections.Generic.IEnumerable<string> protocols, byte[] requestBytes, System.TimeSpan scanTime, int retries, int retryDelayMilliseconds, System.Action<string, Heijden.DNS.Response> callback, System.Threading.CancellationToken cancellationToken) Line 75    C#
    Zeroconf.dll!Zeroconf.ZeroconfResolver.BrowseDomainsAsync(System.TimeSpan scanTime, int retries, int retryDelayMilliseconds, System.Action<string, string> callback, System.Threading.CancellationToken cancellationToken) Line 113 C#
    ZeroconfTest.UWP.exe!ZeroconfTest.UWP.MainPage.ResolveClick(object sender, Windows.UI.Xaml.RoutedEventArgs e) Line 25   C#

Why isn’t this working on UWP? The library has explicit support for netcore50 in the 4.1.0 nuget package. I would not expect arbitrary methods to simply not work. It sort of undermines trust that WYSIWYG when it comes to available surface area.

[davidsh]

cc: @joshfree @stephentoub @CIPop @himadrisarkar @ericstj

Those particular methods are unimplemented right now. We plan to add the rest of the support later this year in an update to the System.Net.NetworkInformation package.

[clairernovotny]

Is there a document that lists out which methods are known not to be implemented per OS/platform along with plans for future support across all of CoreFX?

It'd be far more helpful to reference this in advance than during testing and discovering these things.

[joshfree]

@davidsh can you provide the full list of System.Net APIs that throw on UWP? These need to be added to @leecow's release notes for Monday morning

[clairernovotny]

To be clear, my request is across all of corefx if there are other areas where this may come up.

Thanks!

[nadimkobeissi]

Those particular methods are unimplemented right now. We plan to add the rest of the support later this year in an update to the System.Net.NetworkInformation package.

@davidsh Any ETA on this? This is particularly confusing since the official .NET Core documentation lists these methods as implemented and documented. Frankly, I don't think they should be even listed there until they actually are in the framework...

[davidsh]

cc: @himadrisarkar

Himadri will look into the documentation to see why it is out of sync with the code implementation.

[CIPop]

I don't think they should be even listed there until they actually are in the framework...

+1

@davidsh, @himadrisarkar @joshfree These APIs exist to support the netstandard surface but will throw on run-time. There are others that do the same. I believe we have previously done an analysis and came up with a list that now needs to be integrated within the documentation.

@onovotny to work-around this missing functionality please use Windows.Networking.Connectivity. Here are a few related classes that might get you the information you need:

• https://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.networkinformation.aspx
• https://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.connectionprofile.aspx
• https://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.connectivity.networkadapter.aspx

[Horcrux7]

@CIPop This alternative API not solve the problems with libraries which supports the netstandard.

[CIPop]

@CIPop This alternative API not solve the problems with libraries which supports the netstandard.

I acknowledge that: it's a complicated workaround for those libraries to work on UWP until we get the APIs implemented.

[nadimkobeissi]

Just a comment: .NET Core and that whole family of new and open .NET efforts are really promising and cool, but the framework needs to be communicated and organized in a far more coherent way than it is now.

[ChristophvanderFecht]

Hi everybody!
I just spend a good two days looking for a way to retrieve the subnetmask of my network adapters, for now no luck. Each "solution" I found point to the not implemented method System.Net.NetworkInformation.NetworkInterface.GetAllNetworkInterfaces()...

My question now is, did anybody here figured out a way to get the subnetmask of the available interfaces?

thx, bg

[jtoivola]

Create C\C++ Runtime Component and use GetAdaptersAddresses.
https://msdn.microsoft.com/en-us/library/windows/apps/aa365915.aspx

Available since Anniversary.

[ChristophvanderFecht]

@jtoivola Thx for the suggestion. I also found that currently you can only get the information by using native code. I will have a look at this.

Yesterday I used this PInvoke as mentioned on Stackoverflow. It solved the problem for me.

[dotMorten]

These APIs exist to support the netstandard surface but will throw on run-time. There are others that do the same

This is an absolutely horrible practice. That completely defeats the purpose of having a .NET Standard.

[clairernovotny]

@karelz will this be included in the work to get netstandard 2.0 to UWP? Like actually implemented and working, not throwing?

[karelz]

We should at minimum consider it. Personally I'd say that if it is implementable (via APIs available in UWP context) and not super-costly, I don't see a reason to exclude it - @davidsh @CIPop is it part of your NS2.0 UWP plan?

Note: The issue is marked 'untriaged' - we are still working through Networking area triage (it's taking longer than I'd like as we are heads down on quite a lot of high-pri Netwroking issues :().

cc: @geoffkizer @Priya91

BTW: It would help if we can see upvotes on the top post to capture customer impact/interest. 10+ votes will be something hard to ignore ;-)

[davidsh]

@davidsh @CIPop is it part of your NS2.0 UWP plan?

yes, this is already part of our .NET Standard 2.0 for UWP plan.

And by the way, the implementation won't be using WinRT APIs for UWP. We plan to re-use the existing .NET Core implementation which will work on UWP since those needed win32 api's will be part of allowed api for app container.

[clairernovotny]

@davidsh That's fantastic news! From the above comments, it sounded like there might be other API's in a similar situation -- that are in the surface area but throw at runtime on UWP. Is that still the case for 2.0 or have those gaps been filled? If there will still be a gap, is there a list we can triage to help get community support behind any specific sections?

[Priya91]

@karelz What would be the milestone for .netstandard2.0 UWP? Leaving it at Future for now.

[karelz]

@Priya91 very good point. I think it's time to create one - I'll call it 2.1-UWP for now (@danmosemsft feel free to adjusted while I am OOF :))

[ccicchitelli]

@dotMorten @KAepora Couldn't agree more. I'm disappointed this is even a question that needs to be asked. Come on MS!

[davidsh]

@davidsh That's fantastic news! From the above comments, it sounded like there might be other API's in a similar situation -- that are in the surface area but throw at runtime on UWP. Is that still the case for 2.0 or have those gaps been filled?

We are working thru the list. But the objective for the ".NET Standard 2.0 for UWP" milestone is getting the entire surface area of .NET Standard 2.0 working on UWP. So, that includes System.Net.NetworkInformation as well as the System.Net.Security contract (SslStream, etc.).

In general, we have added more things to the win32 allowed list such as iphlp, schannel, etc. so that we can implement these contracts for UWP.

[clairernovotny]

Off topic to this particular issue but has there been progress on getting ILEmit to work / be supported on UWP in any capacity? Even a fallback interpreter like iOS has can be useful for some things.

[karelz]

I changed the milestone to 2.1.0 with explanation it is 'temporary version' - cc @danmosemsft

@dotMorten @ccicchitelli @KAepora I understand your view point. We're trying to do our best. Sadly, in some (hopefully rare) cases we have to resort to the NotImplemented solutions - due to inability to fully implement the API, or due to resource constraints - ideally backed with low usage data and available workarounds.
If you want to start general discussion about what else to do in such cases, what kind of tooling should be available, etc., let's create a new issue for that. cc @terrajobst

In general, we have added more things to the win32 allowed list such as iphlp, schannel, etc. so that we can implement these contracts for UWP.

Just to be super clear: In the cases when we will rely on newly white-listed OS APIs, we will of course require particular min version of the Win10 OS.

[karelz]

@onovotny RefEmit is out of scope of .NET Standard 2.0 UWP wotk - it is one of the reasons why RefEmit is not part of .NET Standard 2.0, because it can't be implemented on all platforms. cc @terrajobst @danmosemsft

[ccicchitelli]

I totally understand not every method and API call can be implemented on all platforms for obvious reasons, but I'd like think that's the only reason something doesn't get included.

I'm in the position of planning to port a rather large .NET desktop/server app over, let's just say it's not exactly what I expected it would be when the ".NET everywhere!" announcement was made.

[dotMorten]

We're trying to do our best. Sadly, in some (hopefully rare) cases we have to resort to the NotImplemented solutions - due to inability to fully implement the API, or due to resource constraints - ideally backed with low usage data and available workarounds.

IMHO that just means this API shouldn't have been part of the standard. If you make the API part of the standard, and a platform is saying it supports that standard, you also commit to provide the implementation. Getting runtime exceptions instead of compile time errors is quite unacceptable. I can sit here and happily think my .NET Standard component runs on all these platforms, and then it turns out it doesn't on some. It makes our components completely unsupportable.

[hermitdave]

This is indeed lot worse that before.. I don't remember a time where API surface was not implemented for one part in Full Dotnet framework. So much for DotNet everywhere.

I agree though this issue was only raised 8 months ago. With all the final and RC releases you lot keep making, few small platforms are bounds to go unsupported.. All for the greater good. yay

[asrendon]

I tried the following below and get "An object reference is required for the non static field, method, or property" and instantiating it throws the error "Does not contain a constructor that takes 0 arguments" SO what am I supposed to do to get network interface information for my Windows universal app?

    string intlist="";
    intlist = NetworkAdapter.InboundMaxBitsPerSecond;
    interfaces.Text = intlist;

[davidsh]

SO what am I supposed to do to get network interface information for my Windows universal app?

As we indicated above in the discussion on this issue, that functionality is not yet implemented for Windows UWP.

[ViktorHofer]

A customer of mine is facing exactly the same issue and had to put a lot of effort into finding a workaround.

@danmosemsft Are there any plans to emit compiler warnings when using APIs which throw PNSE/NIE? Or is that already in?

[danmoseley]

@terrajobst is developing a tool. Immo will it work for UWP also?

[MattKunze]

I'm running into this issue with a Windows 10 Mobile Enterprise device, I can't find an API that will return any information about the current network adapters.

I added code to PInvoke GetAdaptersAddresses, but it returns a bunch of loopback adapters and a DHCP auto-assigned address, but not the actual WiFi or Ethernet address used by the device.

Would be nice to have something that works at least, and ideally one of the managed APIs

[karelz]

The tool should work also for UWP: Please document the API difference here: https://github.com/dotnet/corefx/wiki/ApiCompat

[karelz]

Looks like we are on track to bring all the APIs back in 2.1. We should still document the difference for current UWP in the above ...

[dotMorten]

@karelz Great news! Thank you for listening.

[karelz]

Just to clarify: The credits for the decision & planning go to @davidsh @CIPop @DavidGoll, I was just the messenger in this case ;-)

[mogikanin]

Just little note. Min UWP version should be 10.0.16299 to use NetworkInterface.GetAllNetworkInterfaces as well other apis from .net standard 2.0