Category: .NET Core

Ping–an abstraction

In C#/.NET Core  there is a Ping Class –  there is at https://docs.microsoft.com/en-us/dotnet/api/system.net.networkinformation.ping.send?view=netstandard-2.0 . And you may ask – why we need a Ping class for such a mundane task, as pinging a PC ?

Because, like for internet method, there are differences.  Let’s take the smalles example: I want to ping 1 time a PC.

On Windows, there is ping –n count

On Linux,  there is ping –c count.

So on Windows –c flag does not exists and on Linux –n is other thing.

Moral of the story : Always look for the abstraction that can alleviate for you the need for reading( see below)/understanding  why it does not work….

PING on Windows:

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
             [-r count] [-s count] [[-j host-list] | [-k host-list]]
             [-w timeout] [-R] [-S srcaddr] [-c compartment] [-p]
             [-4] [-6] target_name

Options:
     -t             Ping the specified host until stopped.
                    To see statistics and continue – type Control-Break;
                    To stop – type Control-C.
     -a             Resolve addresses to hostnames.
     -n count       Number of echo requests to send.
     -l size        Send buffer size.
     -f             Set Don’t Fragment flag in packet (IPv4-only).
     -i TTL         Time To Live.
     -v TOS         Type Of Service (IPv4-only. This setting has been deprecated
                    and has no effect on the type of service field in the IP
                    Header).
     -r count       Record route for count hops (IPv4-only).
     -s count       Timestamp for count hops (IPv4-only).
     -j host-list   Loose source route along host-list (IPv4-only).
     -k host-list   Strict source route along host-list (IPv4-only).
     -w timeout     Timeout in milliseconds to wait for each reply.
     -R             Use routing header to test reverse route also (IPv6-only).
                    Per RFC 5095 the use of this routing header has been
                    deprecated. Some systems may drop echo requests if
                    this header is used.
     -S srcaddr     Source address to use.
     -c compartment Routing compartment identifier.
     -p             Ping a Hyper-V Network Virtualization provider address.
     -4             Force using IPv4.
     -6             Force using IPv6.

PING on Linux:

ping [ -LRUbdfnqrvVaAB] [ -c count] [ -i interval] [ -l preload] [ -p pattern] [ -s packetsize] [ -t ttl] [ -w deadline] [ -F flowlabel] [ -I interface] [ -M hint] [ -Q tos] [ -S sndbuf] [ -T timestamp option] [ -W timeout] [ hop …] destination

Description
ping uses the ICMP protocol’s mandatory ECHO_REQUEST datagram to elicit an ICMP ECHO_RESPONSE from a host or gateway. ECHO_REQUEST datagrams (”pings”) have an IP and ICMP header, followed by a struct timeval and then an arbitrary number of ”pad” bytes used to fill out the packet.

Options
-a
Audible ping.
-A
Adaptive ping. Interpacket interval adapts to round-trip time, so that effectively not more than one (or more, if preload is set) unanswered probes present in the network. Minimal interval is 200msec for not super-user. On networks with low rtt this mode is essentially equivalent to flood mode.
-b
Allow pinging a broadcast address.
-B
Do not allow ping to change source address of probes. The address is bound to one selected when ping starts.
-c count
Stop after sending count ECHO_REQUEST packets. With deadline option, ping waits for count ECHO_REPLY packets, until the timeout expires.
-d
Set the SO_DEBUG option on the socket being used. Essentially, this socket option is not used by Linux kernel.
-F flow label
Allocate and set 20 bit flow label on echo request packets. (Only ping6). If value is zero, kernel allocates random flow label.
-f
Flood ping. For every ECHO_REQUEST sent a period ”.” is printed, while for ever ECHO_REPLY received a backspace is printed. This provides a rapid display of how many packets are being dropped. If interval is not given, it sets interval to zero and outputs packets as fast as they come back or one hundred times per second, whichever is more. Only the super-user may use this option with zero interval.
-i interval
Wait interval seconds between sending each packet. The default is to wait for one second between each packet normally, or not to wait in flood mode. Only super-user may set interval to values less 0.2 seconds.
-I interface address
Set source address to specified interface address. Argument may be numeric IP address or name of device. When pinging IPv6 link-local address this option is required.
-l preload
If preload is specified, ping sends that many packets not waiting for reply. Only the super-user may select preload more than 3.
-L
Suppress loopback of multicast packets. This flag only applies if the ping destination is a multicast address.
-n
Numeric output only. No attempt will be made to lookup symbolic names for host addresses.
-p pattern
You may specify up to 16 ”pad” bytes to fill out the packet you send. This is useful for diagnosing data-dependent problems in a network. For example, -p ff will cause the sent packet to be filled with all ones.
-Q tos
Set Quality of Service -related bits in ICMP datagrams. tos can be either decimal or hex number. Traditionally (RFC1349), these have been interpreted as: 0 for reserved (currently being redefined as congestion control), 1-4 for Type of Service and 5-7 for Precedence. Possible settings for Type of Service are: minimal cost: 0x02, reliability: 0x04, throughput: 0x08, low delay: 0x10. Multiple TOS bits should not be set simultaneously. Possible settings for special Precedence range from priority (0x20) to net control (0xe0). You must be root (CAP_NET_ADMIN capability) to use Critical or higher precedence value. You cannot set bit 0x01 (reserved) unless ECN has been enabled in the kernel. In RFC2474, these fields has been redefined as 8-bit Differentiated Services (DS), consisting of: bits 0-1 of separate data (ECN will be used, here), and bits 2-7 of Differentiated Services Codepoint (DSCP).
-q
Quiet output. Nothing is displayed except the summary lines at startup time and when finished.
-R
Record route. Includes the RECORD_ROUTE option in the ECHO_REQUEST packet and displays the route buffer on returned packets. Note that the IP header is only large enough for nine such routes. Many hosts ignore or discard this option.
-r
Bypass the normal routing tables and send directly to a host on an attached interface. If the host is not on a directly-attached network, an error is returned. This option can be used to ping a local host through an interface that has no route through it provided the option -I is also used.
-s packetsize
Specifies the number of data bytes to be sent. The default is 56, which translates into 64 ICMP data bytes when combined with the 8 bytes of ICMP header data.
-S sndbuf
Set socket sndbuf. If not specified, it is selected to buffer not more than one packet.
-t ttl
Set the IP Time to Live.
-T timestamp option
Set special IP timestamp options. timestamp option may be either tsonly (only timestamps), tsandaddr (timestamps and addresses) or tsprespec host1 [host2 [host3 [host4]]] (timestamp prespecified hops).
-M hint
Select Path MTU Discovery strategy. hint may be either do (prohibit fragmentation, even local one), want (do PMTU discovery, fragment locally when packet size is large), or dont (do not set DF flag).
-U
Print full user-to-user latency (the old behaviour). Normally ping prints network round trip time, which can be different f.e. due to DNS failures.
-v
Verbose output.
-V
Show version and exit.
-w deadline
Specify a timeout, in seconds, before ping exits regardless of how many packets have been sent or received. In this case ping does not stop after count packet are sent, it waits either for deadline expire or until count probes are answered or for some error notification from network.
-W timeout
Time to wait for a response, in seconds. The option affects only timeout in absense of any responses, otherwise ping waits for two RTTs.

OpenSource library- conclusion

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

Following the guidance from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/ it is somehow simple. Most of the rules are already implemented, other are easy to implement into a DevOps Continous Integration workflow( such as Azure DevOps) and others are hardly one half a hour.

It will be nice if we have a badge for this – I will consider making this some day ….

OpenSource library- Breaking changes

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

Following guidance from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/breaking-changes

Nr

Recomandation

AOP Roslyn

1

DO think about how your library will be used. What effect will breaking changes have on applications and libraries that use it?

2

DO minimize breaking changes when developing a low-level .NET library.

3

CONSIDER publishing a major rewrite of a library as a new NuGet package.

4

CONSIDER leaving new features off by default, if they affect existing users, and let developers opt in to the feature with a setting.

5

DO NOT change an assembly name.

6

DO NOT add, remove, or change the strong naming key.

7

CONSIDER using abstract base classes instead of interfaces.

8

CONSIDER placing the ObsoleteAttribute on types and members that you intend to remove. The attribute should have instructions for updating code to no longer use the obsolete API.

9

CONSIDER keeping types and methods with the ObsoleteAttribute indefinitely in low and middle-level libraries.

Unfortunately, AOP Roslyn is not in the stage of breaking changes. But I have had another library, Exporter, and I have had made  3:  CONSIDER publishing a major rewrite of a library as a new NuGet package

OpenSource library-versioning

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

Following recommendations from https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/versioning

Nr

Recomandation

AOP Roslyn

1

CONSIDER using SemVer 2.0.0 to version your NuGet package.

NO

2

DO use the NuGet package version in public documentation as it’s the version number that users will commonly see.

Yes

3

DO include a pre-release suffix when releasing a non-stable package.

No

4

CONSIDER only including a major version in the AssemblyVersion

Yes

5

CONSIDER keeping the major version number of the AssemblyVersion and the NuGet package version in sync.

Yes

6

DO NOT have a fixed AssemblyVersion

Yes

7

CONSIDER including a continuous integration build number as the AssemblyFileVersion revision

Not needed

8

AVOID setting the assembly informational version yourself.

Yes

For 1: I do not like SemVer. It is putting some pressure on the developer of the OpenSource. So I decide to follow Calendar versioning https://calver.org/ 

For 2: Yes, it is normal.

For 3: No, I do not like pore-release.

For 4: Yes – the year is major

For 5: Yes, done by CI process

For 6: Yes, done by CI in Calendar Versioning

For 7: NO. And , because of Calendar versioning, it is already done, if I do not publish 2 versions in the same day

For 8: Do nothing – and it is done.

OpenSource library- publishing

Following the rules at https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/publish-nuget-package

Nr

Recomandation

AOP Roslyn

1

DO publish stable packages and pre-release packages you want community feedback on to NuGet.org.

Done

2

CONSIDER publishing pre-release packages to a MyGet feed from a continuous integration build.

No

3

CONSIDER testing packages in your development environment using a local feed or MyGet. Check the package works then publish it to NuGet.org.

Yes

4

DO use a Microsoft account to sign in to NuGet.

Yes

5

DO enable two-factor authentication for accessing NuGet.

Yes

6

DO enable email notification when a package is published.

Yes

For 1: Done already. However, I do not like pre-release packages

For 2: Too much hassle for a single developer. Using instead NuGet

For 3: Yes , I have already a build.bat to do this

For 4: Yes.(NuGet allows only that now)

For 5 : Yes

For 6: Yes.

OpenSource library- Source Link

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

The documentation at https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/sourcelink says to enable source link.


Nr

Recomandation

AOP Roslyn

1

CONSIDER using SourceLink to add source control metadata to your assemblies and NuGet packages.

Modified(1)

2

CONSIDER including symbol files (*.pdb) in the NuGet package.

Done already(2)

For (1) : I have followed the instructions at https://github.com/dotnet/sourcelink/blob/master/README.md

For(2): It was done already by csproj configuration.

OpenSource library–Dependencies

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

Now trying to respect what it says at https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/dependencies .

Nr

Recomandation

AOP Roslyn

1

DO review your .NET library for unnecessary dependencies.

Done manually(1)

2

DO NOT have NuGet package references with no minimum version

Done already(2)

3

AVOID NuGet package references that demand an exact version

Done already(2)

4

AVOID NuGet package references with a version upper limit

Done already(2)

5

CONSIDER referencing shared source packages for small, internal pieces of functionality

N/A(5)

6

CONSIDER making your package a shared source package if it provides small, internal pieces of functionality.

N/A(5)

7

DO reference shared source packages with PrivateAssets=”All”.

N/A(5)

8

DO NOT have shared source package types in your public API.

N/A(5)

9

DO NOT publish shared source packages to NuGet.org.

N/A(5)

For (1): Reviewing .NET library for unnecessary dependencies is practically a manual process. Could be a dotnet global tool – but for the moment I just inspected the .csproj for references and see that all are ncessary

For (2): As I read from documentation “Typically, the package reference version in the project file is the minimum version and there’s no maximum.” .So doing nothing I am at the good point

For (5), I usually put a new dll or NuGet package – I do not share code source. So this is done also without friction.

OpenSource library–Strong naming

The strong naming is something that I have not have done usually, so it will be interesting following https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming .

Nr

Recomandation

AOP Roslyn

1

CONSIDER strong naming your library’s assemblies.

Not –see below

2

CONSIDER adding the strong naming key to your source control system.

easy- not

3

CONSIDER incrementing the assembly version
on only major version changes to help
users reduce binding redirects, and how often they’re updated.

not

4

DO NOT add, remove, or change the strong naming key.

easy- not

5

DO NOT publish strong-named and non-strong-named versions of your library.

easy – not

I have tried to add signing – it is pretty easy in Visual Studio to generate a new pfx fiel to sign code. However, when compiling, it requires all dependencies to be signed

CSC : error CS8002: Referenced assembly ‘PortableConsoleLibs, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null’ does not have a strong name. [C:\projects\aop-with-roslyn\AOPRoslyn\aopCmd\aop.csproj]

So , if one of your referenced libraries is not code signed, it is a big no

The other requirements are pretty easy..

OpenSource library – Cross-platform targeting

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

At https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/cross-platform-targeting there are the recommendations  for Cross platform. Let’s see what needs to be done for https://github.com/ignatandrei/AOP_With_Roslyn

Let’s see:

 

Nr Recommandation AOP Roslyn
1 DO start with including a netstandard2.0 target. Done – the main dll, AOPRoslyn, is already .netstandard2,0
2 AVOID including a netstandard1.x target. Not needed
3 DO include a netstandard2.0 target if you require a netstandard1.x target. Not needed
4 DO NOT include a .NET Standard target if the library relies on a platform-specific app model. Not needed
5 CONSIDER targeting .NET implementations in addition to .NET Standard. Not needed
6 AVOID using multi-targeting with .NET Standard if your source code is the same for all targets. Not needed
7 CONSIDER adding a target for net461 when you’re offering a netstandard2.0 target. OK> see later point 9

 

8 DO distribute your library using a NuGet package. Done

https://www.nuget.org/packages/dotnet-aop

 

9 DO use a project file’s TargetFrameworks property when multi-targeting Struggle to implement/ partially done – modified AOPRoslyn.csproj
10 CONSIDER using MSBuild.Sdk.Extras when multi-targeting for UWP and Xamarin as it greatly simplifies your project file. Not needed
11 DO NOT include a Portable Class Library (PCL) target. OK
12 DO NOT include targets for .NET platforms that are no longer supported. Not needed

I tried to modify to include

<TargetFrameworks>netstandard2.0;net461</TargetFrameworks>

( Attention: Framework, not Framework)

First , you should publish the .csproj

dotnet publish <path to csproj>

should be modified with -f=”netstandard2.0″

Then , each dependency should support it :

error NU1202: Package PortableConsoleLibs 1.0.0 is not compatible with net461 (.NETFramework,Version=v4.6.1). Package PortableConsoleLibs 1.0.0 supports: netcoreapp2.0 (.NETCoreApp,Version=v2.0)

So you should contact the owners to support it – or re-compile the sources, if you have.

So I will stick with

“DO NOT include targets for .NET platforms that are no longer supported.” including NET461.

Conclusion: 11 / 12 it is a good score.

Implement Open-source library guidance

Part 1

Implement Open-source library guidance

Part 2

OpenSource library – Cross-platform targeting

Part 3

OpenSource library-Dependencies

Part 4

OpenSource library- Source Link

Part 5

OpenSource library-versioning

Part 6

OpenSource library- Breaking changes

Part 7

OpenSource library- conclusion

I have written previously a booklet about “Making Open Source Component from idea to deploy With examples from .NET Core” .

Now  Microsoft and contributors make a library guidance for OpenSource projects at https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/  . I will take as a working point my component, https://github.com/ignatandrei/AOP_With_Roslyn , and see where it goes and how many things I already implemented.

The items are:

Cross-platform targeting   
Strong naming   
NuGet and open-source libraries   
Dependencies   
SourceLink   
Publishing   
Versioning   

I will implement each one in one blog post

Andrei Ignat weekly software news(mostly .NET)

* indicates required

Please select all the ways you would like to hear from me:

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please visit our website.

We use Mailchimp as our marketing platform. By clicking below to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing. Learn more about Mailchimp's privacy practices here.