Category: .NET Core

[Presentation]Angular + .NET Core => Applications for Mobile, Web and Desktop – Andrei Ignat

I was invited at http://apexvox.net/#schedule to present ] Angular + .NET Core => Applications for Mobile, Web and Desktop

It was very exciting to find so many people interested in .NET . And it was good to re-see old friends, like http://vunvulearadu.blogspot.com/2019/03/post-event-apexvox-cluj-napoca-2019.html , Daniel Costea, Ciprian Jichici and to make new ones

You can find the code and the presentation at https://github.com/ignatandrei/angNetCoreDemo/ .
If you need help, please contact me directly

Identify version for application and components for Backend(.NET Core) and FrontEnd(Angular)–part 2- backend

Part1 : Introduction and Concepts

Part 2: Obtaining BackEnd Components Version

Part 3: Obtaining FrontEnd Component Version and Final Library

Live Demo 

NPM component
Copy paste NET code

Identifying the version of the dll’s  used on the backend is fairly simple. All we need is to iterate into the current directory and find the version of the dlls.  It is just a simple controller that receives via Dependency Injection the path to the current directory. It is no harder than that code:

 

[HttpGet]

public FileVersionInfo[] GetVersions([FromServices] IHostingEnvironment hosting)

{

var dirPath = hosting.ContentRootPath;

var ret = new List<FileVersionInfo>();

var files = Directory.EnumerateFiles(dirPath, "*.dll", SearchOption.AllDirectories).Union(Directory.EnumerateFiles(dirPath, "*.exe", SearchOption.AllDirectories));



foreach (string item in files)

{

try

{

var info = FileVersionInfo.GetVersionInfo(item);

ret.Add(info);

 

}

catch (Exception)

{

//TODO: log

}

}

return ret.ToArray();

}

}

Identify version for application and components for Backend(.NET Core) and FrontEnd(Angular)–part 1- introduction

Part1 : Introduction and Concepts

Part 2: Obtaining BackEnd Components Version

Part 3: Obtaining FrontEnd Component Version and Final Library

Live Demo 

NPM component
Copy paste NET code

In our days recognizing fast the version of the software you deploy it is important ( very important , if you do not have a continuum upgrade strategy – like Chrome does or in my days , using Click Once ). More, you should be able to recognize what components you are using in the software.

This was very interesting for me ( see http://msprogrammer.serviciipeweb.ro/2014/10/13/tt-add-more-informations-net-version-build/  and http://msprogrammer.serviciipeweb.ro/2019/01/14/opensource-library-versioning/ ). However, this is not about how to version the application – but how to display the version for BackEnd and FrontEnd components.

So – we need a front-end HTML page ( or WPF, or WinForm or other front-end ) and 2 informations  : 1 for the components for the backend and one for the components for the front end .

I have made such a component – it is made for Angular and .NET Core. It can be adapted very easy for all others , by transforming the  Angular library to a WebComponent library and the WEB API .NET Core into node.js  HTTP Rest.

If you want to see the final product , please check the https://www.npmjs.com/package/versions-netcore-angular  and the  live demo at https://azurestankins.azurewebsites.net/about

You will see the version of .NET Components and Angular Components that we are using.

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.

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.