Merge pull request #32 from cpsusie/v1.0_master_issue_25

Update version number, readme.md and both release.txt files.

DotNetVault.sln

@@ -1,7 +1,7 @@
 
 Microsoft Visual Studio Solution File, Format Version 12.00
-# Visual Studio Version 16
-VisualStudioVersion = 16.0.29306.81
+# Visual Studio Version 17
+VisualStudioVersion = 17.0.31825.309
 MinimumVisualStudioVersion = 10.0.40219.1
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "DotNetVault", "DotNetVault\DotNetVault.csproj", "{200B0CCA-F625-4E3F-9CC3-00AE5A2E7579}"
 EndProject
@@ -17,6 +17,7 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution
 		license.txt = license.txt
 		README.md = README.md
 		readme.txt = readme.txt
+		RELEASE.txt = RELEASE.txt
 	EndProjectSection
 EndProject
 Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "VaultUnitTests", "VaultUnitTests\VaultUnitTests.csproj", "{D0598457-B37E-4416-AAEC-53973098507F}"

DotNetVault/DotNetVault.csproj

@@ -20,7 +20,7 @@
 
   <PropertyGroup>
     <PackageId>DotNetVault</PackageId>
-    <PackageVersion>1.0.0.0</PackageVersion>
+    <PackageVersion>1.0.0.1</PackageVersion>
     <Owners>CJM Screws, LLC</Owners>
     <Authors>Christopher Susie</Authors>
     <PackageProjectUrl>https://github.com/cpsusie/DotNetVault</PackageProjectUrl>
@@ -40,28 +40,24 @@
       A guided tour / quick start guide for this project's functionality can be found here: https://github.com/cpsusie/DotNetVault/blob/v0.2.5.x/Quick_Start_Functionality_Tour.md 
 </Description>
     <PackageReleaseNotes>
+      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](https://www.nuget.org/packages/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.
-      RELEASE NOTES VERSION 0.2.5.10-beta:
-      Beta release using beta verion (0.1.1.0-beta) of High Precision Timestamps.
-      RELEASE NOTES VERSION 0.2.5.9:
-      * Fixed bug from Issue 8, where a readonly field of unmanaged struct (or enum) in an otherwise vault-safe reference type was being identified as not readonly merely because the unmanaged type itself has writable fields.  This is incorrect because attaching the readonly qualifier to the field will prevent mutation of its writable fields ... or, at worst, cause any mutation to be written to a defensive copy.   This problem manifested itself with a nullable unmanaged enum type.
-      * Two unit tests added that originally failed but now pass after application of fix.
-      * Update example code project to demonstrate.
     </PackageReleaseNotes>
     <Copyright>Copyright © 2019-2021 CJM Screws, LLC</Copyright>
     <PackageTags>DotNetVault, analyzers, synchronization, thread-safety, threadsafe, deadlock, deadlock-prevention, threads, raii, multi-threaded</PackageTags>
     <NoPackageAnalysis>true</NoPackageAnalysis>
     <LangVersion>8.0</LangVersion>
-    <Version>1.0.0.0</Version>
+    <Version>1.0.0.1</Version>
     <AssemblyName>DotNetVault</AssemblyName>
     <RootNamespace>DotNetVault</RootNamespace>
     <Company>CJM Screws, LLC</Company>
-    <AssemblyVersion>1.0.0.0</AssemblyVersion>
-    <FileVersion>1.0.0.0</FileVersion>
+    <AssemblyVersion>1.0.0.1</AssemblyVersion>
+    <FileVersion>1.0.0.1</FileVersion>
     <PackageLicenseFile>license.txt</PackageLicenseFile>
     <RepositoryType>git</RepositoryType>
   </PropertyGroup>

DotNetVault/RELEASE.txt

@@ -1,9 +1,12 @@
-RELEASE NOTES FOR VERSION 1.0:
+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](https://www.nuget.org/packages/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 FOR 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.  T
+      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.  
 
 RELEASE NOTES VERSION 0.2.5.9:
      * Fixed bug from Issue 8, where a readonly field of unmanaged struct (or enum) in an otherwise vault-safe reference type was being identified as not readonly merely because the unmanaged type itself has writable fields.  This is incorrect because attaching the readonly qualifier to the field will prevent mutation of its writable fields ... or, at worst, cause any mutation to be written to a defensive copy.   This problem manifested itself with a nullable unmanaged enum type.

README.md

@@ -128,7 +128,11 @@ Essentially, when we have an immutable or **mutable** value type that we accessi
 ### **Development Roadmap** 
 
 #### *Release History*
-
+
+#### *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](https://www.nuget.org/packages/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).
+
 #### *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](https://github.com/cpsusie/DotNetVault/tree/v1.0) 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).

RELEASE.txt

@@ -1,4 +1,14 @@
-RELEASE NOTES VERSION 0.2.5.9:
+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](https://www.nuget.org/packages/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 FOR 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.  
+
+RELEASE NOTES VERSION 0.2.5.9:
      * Fixed bug from Issue 8, where a readonly field of unmanaged struct (or enum) in an otherwise vault-safe reference type was being identified as not readonly merely because the unmanaged type itself has writable fields.  This is incorrect because attaching the readonly qualifier to the field will prevent mutation of its writable fields ... or, at worst, cause any mutation to be written to a defensive copy.   This problem manifested itself with a nullable unmanaged enum type.
      * Two unit tests added that originally failed but now pass after application of fix.
      * Update example code project to demonstrate.