DotNetVault 1.0.0.1

dotnet add package DotNetVault --version 1.0.0.1
NuGet\Install-Package DotNetVault -Version 1.0.0.1
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="DotNetVault" Version="1.0.0.1" />
For projects that support PackageReference, copy this XML node into the project file to reference the package.
paket add DotNetVault --version 1.0.0.1
#r "nuget: DotNetVault, 1.0.0.1"
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
// Install DotNetVault as a Cake Addin
#addin nuget:?package=DotNetVault&version=1.0.0.1

// Install DotNetVault as a Cake Tool
#tool nuget:?package=DotNetVault&version=1.0.0.1

DotNetVault

Synchronization Library and Static Analyzer for C# 8.0+

CURRENT RELEASE: Version 1.0.0.1
LAST MAJOR NEW RELEASE Version 1.0

DotNetVault takes its inspiration from the synchronization mechanisms provided by Rust language and the Facebook Folly C++ synchronization library. These synchronization mechanisms observe that the mutex should own the data they protect. RAII destroys the lock when it goes out of scope – even if an exception is thrown or early return taken. DotNetVault provides mechanisms for RAII-based thread synchronization and actively prevents (at compile-time) resources protected by it from thread-unsafe or non-synchronized access.

Advantages:

Easy to Change Underlying Synchronization Mechanisms

DotNetVault uses a variety of different underlying synchronization mechanisms:

  • Monitor + Sync object
  • Atomics
  • ReaderWriterLockSlim

If you use them directly, and decide to switch to (or try) a different mechanism, it will require extensive refactoring DotNetVault simplifies the required refactoring. All vaults expose a common compile-time API.

Deadlock Avoidance

Using DotNetVault, all access is subject to RAII, scoped-based lock acquisition and release. Failure to obtain a lock throws an exception --- there can be no mistake as to whether it is obtained. When a locks scope ends, it is released. By default, all lock acquisitions are timed -- you must explicitly and clearly use the differently and ominously named untimed acquisition methods if you wish to avoid the slight overhead imposed by timed acquisition. (Typically after using and heavily testing using the standard timed acquisition methods, ensuring there are no deadlocks, profiling and discovering a bottleneck caused by timed acquisition, and then switching to the untimed acquisition method in those identified bottlenecks. It is hard to deadlock accidentally in DotNetVault.

RAII (Scope-based) Lock Acquisition and Release:

Locks are stack-only objects (ref structs) and the integrated Roslyn analyzer forces you to declare the lock inline in a using statement or declaration, or it will cause a compilation error.

  • There is no danger of accidentally holding the lock open longer than its scope even in the presence of an exception or early return.
  • There is no danger of being able to access the protected resource if the lock is not obtained.
  • There is no danger of being able to access the protected resource after release.
Enforcement of Read-Only Access When Lock is Read-Only

ReaderWriterLockSlim is unique among the synchronization primitives employed by DotNetVault in allowing for multiple threads to hold read-only locks at the same time. DotNetVault not only prevents access to the underlying resource while the correct lock is not held, it also enforces that, while a read-only lock is held, the protected object cannot be mutated. This is also enforced statically, at compile-time.

Isolation of Protected Resources

Static enforcement prevents unsynchronized access to protected resources.

Resources For Learning To Use DotNetVault

Quick Start Guides
  1. A quick-start installation guide for installing the DotNetVault library and analyzer for use in Visual Studio 2019+ on Windows.
  2. A quick start installation guide for installing the DotNetVault library and analyzer for use in JetBrains Rider 2019.3.1+ (created on an Amazon Linux environment, presumably applicable to any platform supporting JetBrains Rider 2019.3.1+).
  3. A guided overview of the functionality of DotNetVault along with a test project available on Github in both source and compiled code.

Development Roadmap

Version 1.0.0.1

This version supplies fixes for issues 22 and 23 as merged in pull requests 24 and 26, respectively. Issue 22, was a problem where if a BasicMonitorVault was constructed without supplying an initial value, a LockAlreadyHeldThreadException would be thrown every time an attempt to acquire the lock was made. Issue 24 was a bug in the version of HighPrecisionTimeStamps used by DotNetVault's static analyzer on some frameworks on some systems. It was fixed by upgrading the version requirements for HighPrecisionTimeStamps (which can be downloaded in package form here and whose repository is here) to version 1.0.0.6+ from 1.0.0.1+. The pull request from the relevant bug fixed in HighPrecisionTimeStamps can be found here.

Version 1.0

This version represents the finalization of the work done in versions 0.2.5.x. Versions 1.0+ will remain usable (assuming C# 8 manually enabled) from a .NET Framework 4.8 or NetStandard 2.0 environment (as well as .NET Core 3.1 and .NET 5). No major new features will be added to this version. Development will remain open in the 1.0 branch primarily for refinements, bug fixes and documentation updates. If you are not upgrading your projects to .NET 5, continue to use releases numbered 1.0. Analyzer behavior will be updated only to close any encountered loopholes (or minor textual or formatting changes).

Version 0.2.5.x
  • Upgrading to new versions of Roslyn libraries, immutable collections and other minor dependency upgrades
  • Changing some of the formatting of analyzer diagnostics to comply with Roslyn authors' recommendations
  • Adding Monitor Vaults (using Monitor.Enter + sync object) as the synchronization mechanism
  • Adding ReadWrite Vaults (using ReaderWriterLockSlim) as their synchronization mechanism
  • Fixing flawed static analyzer rules
  • Adding new analyzer rules to close encountered loopholes in the ruleset that potentially allowed unsynchronized access to protected resource objects
  • Unit tests as appropriate for new functionality
  • Creation of quick start installation guides with test projects
  • Not including project PDF in the released package but instead providing an md document and a txt document with links to those documents in the GitHub repository
  • Significant updates to the formatting and content of project markdown documents
  • Adding Source Link and releasing a symbol package along with the nuget package for this project
  • Writing many test projects and demonstration projects to verify functionality, stress test and profile performance of the vaults
  • Adding a document serving as a guide to using large mutable value types generally and as a repository for shared mutable state
Future Features

They will be released starting at version 2.0. It is likely that the next version of DotNetVault will be targeting the upcoming unified framework version 5.0+ and not support prior versions of DotNet. The primary focus of development will be the code generation capabilities of the Roslyn platform planned for release with .NET version 5.0+. It is hoped to allow development and (to some extent) automated generation of customized vaults and their locked resource objects for users of this library.

See DotNetVault Description_v1.0.pdf which serves as the most complete design document for this project. Its latest draft version can be found here.

Product Compatible and additional computed target framework versions.
.NET net5.0 was computed.  net5.0-windows was computed.  net6.0 was computed.  net6.0-android was computed.  net6.0-ios was computed.  net6.0-maccatalyst was computed.  net6.0-macos was computed.  net6.0-tvos was computed.  net6.0-windows was computed.  net7.0 was computed.  net7.0-android was computed.  net7.0-ios was computed.  net7.0-maccatalyst was computed.  net7.0-macos was computed.  net7.0-tvos was computed.  net7.0-windows was computed.  net8.0 was computed.  net8.0-android was computed.  net8.0-browser was computed.  net8.0-ios was computed.  net8.0-maccatalyst was computed.  net8.0-macos was computed.  net8.0-tvos was computed.  net8.0-windows was computed. 
.NET Core netcoreapp2.0 was computed.  netcoreapp2.1 was computed.  netcoreapp2.2 was computed.  netcoreapp3.0 was computed.  netcoreapp3.1 was computed. 
.NET Standard netstandard2.0 is compatible.  netstandard2.1 was computed. 
.NET Framework net461 was computed.  net462 was computed.  net463 was computed.  net47 was computed.  net471 was computed.  net472 was computed.  net48 was computed.  net481 was computed. 
MonoAndroid monoandroid was computed. 
MonoMac monomac was computed. 
MonoTouch monotouch was computed. 
Tizen tizen40 was computed.  tizen60 was computed. 
Xamarin.iOS xamarinios was computed. 
Xamarin.Mac xamarinmac was computed. 
Xamarin.TVOS xamarintvos was computed. 
Xamarin.WatchOS xamarinwatchos was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last updated
1.0.0.1 474 10/30/2021
1.0.0 317 8/21/2021
0.2.5.18 315 8/13/2021
0.2.5.15-beta 246 8/8/2021
0.2.5.10-beta 202 8/5/2021
0.2.5.9 393 5/22/2021
0.2.5.8 355 12/14/2020
0.2.5.3 522 10/25/2020
0.2.5.1 429 10/14/2020
0.2.5 432 10/11/2020
0.2.2.12-beta 287 8/23/2020
0.2.2.1-beta 433 7/12/2020
0.2.1.22-beta 350 4/7/2020
0.2.1.9-alpha 442 3/15/2020
0.2.0.2-alpha 319 2/13/2020
0.1.5.4 523 2/17/2020
0.1.5.2 479 2/8/2020
0.1.5 475 2/2/2020
0.1.4.2-beta 562 2/1/2020
0.1.4.1-beta 535 1/26/2020
0.1.4-beta 489 1/21/2020
0.1.3.13-beta 513 1/11/2020
0.1.3.11-beta 558 1/8/2020
0.1.3.8-beta 651 1/4/2020
0.1.3.5-beta 551 1/1/2020

RELEASE NOTES FOR VERSION 1.0.0.1:
     This version supplies fixes for issues [22](https://github.com/cpsusie/DotNetVault/issues/22) and [23](https://github.com/cpsusie/DotNetVault/issues/23) as merged in pull requests [24](https://github.com/cpsusie/DotNetVault/pull/24) and [26](https://github.com/cpsusie/DotNetVault/pull/26), respectively. Issue 22, was a problem where if a BasicMonitorVault was constructed without supplying an initial value, a LockAlreadyHeldThreadException would be thrown every time an attempt to acquire the lock was made.  Issue 24 was a bug in the version of HighPrecisionTimeStamps used by DotNetVault's static analyzer on some frameworks on some systems.  It was fixed by upgrading the version requirements for HighPrecisionTimeStamps (which can be downloaded in package form [here](HighPrecisionTimeStamps) and whose repository is [here](https://github.com/cpsusie/High-Precision-Time-Stamps)) to version 1.0.0.6+ from 1.0.0.1+. The pull request from the relevant bug fixed in HighPrecisionTimeStamps can be found [here](https://github.com/cpsusie/High-Precision-Time-Stamps/pull/23).
     RELEASE NOTES VERSION 1.0:
     Official Release of DotNetVault.  See prior release notes for features.  This release updates the official documentation for this release version.
     RELEASE NOTES VERSION 0.2.5.18:
     Non-beta release using version 1.0 of High Precision Timestamps.  Originally beta tested via version 0.1.1.0-beta in DotNetVault version 0.2.5.10-beta et seq.  Dependency on HpTimestamps changed from included dll to a dependency on package.
     Also, added a new (minor) feature: the [ReportWhiteListLocationsAttribute], when applied to a struct or class, will emit a compiler warning giving you the path of the vaultsafewhitelist and the conditionally vault safe generic whitelist files.  This enables users on varied systems to locate these files.