ImaginaryRealities.CommonLibrary
2.0.1
dotnet add package ImaginaryRealities.CommonLibrary --version 2.0.1
NuGet\Install-Package ImaginaryRealities.CommonLibrary -Version 2.0.1
<PackageReference Include="ImaginaryRealities.CommonLibrary" Version="2.0.1" />
paket add ImaginaryRealities.CommonLibrary --version 2.0.1
#r "nuget: ImaginaryRealities.CommonLibrary, 2.0.1"
// Install ImaginaryRealities.CommonLibrary as a Cake Addin
#addin nuget:?package=ImaginaryRealities.CommonLibrary&version=2.0.1
// Install ImaginaryRealities.CommonLibrary as a Cake Tool
#tool nuget:?package=ImaginaryRealities.CommonLibrary&version=2.0.1
The Common Library contains classes and components that are reused often by ImaginaryRealities for developing our software products.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET Framework | net40 is compatible. net40-client is compatible. net403 was computed. net45 is compatible. net451 was computed. net452 was computed. net46 was computed. net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
This package has no dependencies.
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version 2.0.1
I removed the strong naming key from the framework assemblies.
I reviewed the pros and cons of strong naming and decided that
it doesn't fit in with the intended use of the framework and
that the benefits to strong naming were non-existent.
I changed the implementation of the Process Monitor integration
code. The code now uses .NET safe handles instead of raw
handles which should lead to less risk of handle leaks
(although there was no evidence to suggest that there was a
problem before; I just decided it was a better practice). I
also fixed/updated some of the unit tests and increased code
coverage.
I created the ProcessMonitorException class. Exceptions that
are reported by the Process Monitor framework will throw this
exception instead of raw Exception objects.
I updated the SemanticVersionNumber class to use version 2.0.0
of the Semantic Versioning Specification. The big change here
is that the build number is no longer considered when comparing
version numbers. Also, the algorithm for comparing pre-release
version numbers was altered to match a change in the
specification. Pre-release identifiers that are numbers have a
lower precedence than alphanumeric identifiers.