CuttingEdge.Conditions

Version [Version Number] ([Friendly Version Number]) [Release Date]

Version 1.0.4.0 (v1.0) 2009-08-27
	General description:
		This first stable release has had a major face lift and several minor bug fixes. The API has changed 
		considerably and therefore this release is both binary and code incompatible with the previous beta. 
		Great change is the possibility to run CuttingEdge.Conditions on machines that do not have .NET 3.5 
		installed. While the assembly itself is still dependent on System.Core (.NET 3.5), users can safely 
		add it to their .NET 2.0 projects (as long as the C# 3.0 or VB9 compilers are used).
		
	Bug Fixes:
		-Evaluate(null) threw a NullReferenceException for work item 10545.
		 When the ValidationExtensions.Evaluate<T>(Expression<Func<T, bool>>) overload was called with a null
		 reference for the Expression argument, the method threw a NullReferenceException, while we expected
		 an ArgumentException or PostconditionException. The code was fixed and two unit tests are added to
		 prevent regression.
		-StackOverflowException was thrown when self-referencing collections were supplied for work item 10509.
		 When building an exception message, the library uses the supplied parameters of the validation
		 methods. The parameter was transformed to a string representation, which uses recursive calls to 
		 transform collections to it's string representation. Supplying a collection that referenced itself
		 caused a StackOverflowException. This method now checks it's recursive depth to prevent such an
		 exception.
		-Behavior of Contains, ContainsAll, and ContainsAny overloads changed for work item 10480.
		 The overloads of the Contains, ContainsAll, and ContainsAny methods for collections had inconsistent
		 behavior. While some overloads used the ICollection<T>.Contains or IList.Contains method of the
		 validated collection, others iterated the collection itself to determine whether a
		 collection contained the specified value. This resulted in different behavior on some collections
		 that did not use default equality. The behavior is now fixed, but it comes with some costs. Using
		 those methods on ordered sets (like HashSet<T> and SortedList<T>) is now slower than before.
		-The internal CollectionHelper class had a dependency on the .NET 3.5 type HashSet<T>. This dependency
		 is removed and it's now more likely that CuttingEdge.Conditions can be used in .NET 2.0 projects.
		 You'd still need C# 3.0 though. The library has now only one method that you can not call without
		 .NET 3.5 installed: the Evaluate(Expression<Func<T, bool>>) method.
		
	Code changes:
		-[BREAKING CHANGE] Change extensibility of ConditionValidator<T> for work item 10543.
		 Removed the ConditionValidator<T>.BuildException method overloads and renamed the Throw method
		 to ThrowExceptions with multiple overloads. The library now calls these overloads, which makes it
		 extending the library easier and more consistent.
		-[BREAKING CHANGE] Otherwise<T> methods removed from ConditionValidator<T> for work item 10535.
		 Removed code: OtherwiseValidator, the ConditionsValidator<T>.Otherwise<E> method, exception message
		 for the OtherwiseValidator removed from the string resources, and unit tests for the Otherwise method.
		 Usage of the Otherwise method has been removed from the xml comments.
		 For more information on this change see: http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=58.
		-[BREAKING CHANGE] Remove extension method behavior of Requires() and Ensures() methods for item 10514.
		 This change meant changes to xml comments, unit tests and code snippets.
		 For more information on this change see: http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=57.
		-[BREAKING CHANGE] Validator<T> renamed to ConditionValidator<T> for work item 10511.
		 The type name Validator<T> was too general and didn't exactly describe the intend of this type. It's 
		 name conflicted with other frameworks that use this same name, such as Enterprise Library Validation
		 Application Block and NHibernate. The type is renamed to 'ConditionValidator<T>'. This name better 
		 describes it's intend and it is less likely to cause naming conflicts with other frameworks.
		-[BREAKING CHANGE] The overload Validator<T>.Otherwise<TException>(string) has been removed for work
		 item 10497.
		 The Otherwise method allows a user to specify the type of exception that has to be thrown. This
		 second overload allows specifying an alternative exception message, but it's behavior was counter-
		 intuitive.	It replaced any message that was supplied in a validation method. Best solution was to
		 completely remove this overload from the library. This makes the library more consistent and easier
		 to use.		 
		-A TraceListener class called ‘UnitTestTraceListener’ has been added to the UnitTest project and 
		 configured to be the default trace listener in the project's app.config. The trace listener ensures
		 that calls to Debug.Assert(false), Trace.Assert(false), Debug.Fail(), and Trace.Fail(), from within
		 the tested assembly are routed to the Microsoft.VisualStudio.TestTools.UnitTesting.Assert.Fail
		 method. Debug.Assert is now used in the SR.GetStringInternal method.
		-[BREAKING CHANGE] One overload of entry point method 'Ensures' has been removed.
		 The overload Condition.Ensures<T>(T value, string argumentName, string additionalMessage) has been
		 removed. Because of this change, the EnsuresValidator has been adjusted and some unit tests have
		 been removed. The overload has become redundant in version 1.0.2.0, after overload methods where
		 added with a 'conditionDescription' parameter of type string for all extension methods.
	

Version 1.0.3.0 (v1.0 beta 3) 2009-03-15
	General description:
		This released has some breaking changes to allow better support for languages other than C# (VB.NET
		for instance, wasn't supported well). Therefore, the old release is both binary and code incompatible.
		Still, C# users shouldn't expect to make any changes to their code.
	
	Bug Fixes:
		-Added an [Obsolete] attribute to the Equals(object) method of the Validator<T> class. The Equals 
		 method is not meant to be used by framework users and the compiler will now show a warning with the
		 message ''This method is not part of the validation framework. Please use the IsEqualTo method.'
		 which indicates clearly that the user should use the IsEqualTo method.	

	Code changes:
		-[BREAKING CHANGE] Entry point methods 'Requires' and 'Ensures' moved to a more meaningful class,
		 named 'Condition'. This leads to a more intuitive API for languages that do not support extension
		 methods on all type of objects such as VB.NET, which does not support extension methods on arguments
		 of the System.Object.


Version 1.0.2.0 (v1.0 beta 2) 2008-12-20
	General description:
		This release has several breaking changes. Therefore, the old release can not be swapped with this 
		release, without a recompilation. However, there is just one change in behavior users should pay
		attention to: The ValidatorExtension.IsOfType(Type) method now throws an Exception when the given
		argument is a null reference.

	Bug Fixes:
		-[BREAKING CHANGE] The ValidatorExtensions.IsOfType<T>(Type) method succeeded when the supplied value
		 was null. The method was actually written for the following typical use case:
			"if (!(param is Type)) throw new ArgumentException();". The use case would actually throw an
		 exception when 'param' is a null reference. The IsOfType<T> method now behaves correctly.

		-RequiresValidator didn't generate correct exception messages.
		 When the exception message didn't contain additional information, the 'condition' was used, but
		 wasn't concatenated with a dot. This resulted in a sentence without a dot.
		 
		-Several string methods threw an exception with an invalid exception message.
		 Methods 'StartsWith', 'DoesNotStartWith', 'Contains', 'DoesNotContain', 'EndsWith' and 
		 'DoesNotEndWith' threw an exception message like this: 
			"value does not contain {'h', 'e', 'l', 'l', 'o'}"
		 The message should have been formed as follows:
			"value does not contain 'hello'"
	
	Code changes:
		-Overload methods added with a 'conditionDescription' parameter of type string for all extension 
		methods and unit tests added to support these new overloads.
		
		-[BREAKING CHANGE] The public Validator<T>.ArgumentName field is changed to a read only property.
		 This property was designed as field to ensure the best performance. However, the value is exclusively
		 used in exceptional cases (when exceptions are thrown). Therefore, violating the Framework Design
		 Guidelines wasn't a valid excuse.
		 
		-Extra 'IsTrue' and 'IsFalse' methods added according to work item 7143.
		 These method overloads allow validating Boolean and Nullable<Boolean> values.
		 see http://www.codeplex.com/conditions/WorkItem/View.aspx?WorkItemId=7143 for this work item.		 
		 
		-Extra method overloads added for most primitive CLR types to increase performance.
		 Method overloads for Byte, DateTime, Decimal, Double, Int16, Int32, Int64 and Single added for the
		 methods in the 'Compare' group. You could expect a 50% performance improvement on average, when
		 the new overloads are used (no code has to be changed, just recompile).
		 
		-Validation<T> class is now extendable.
		 Developers can now inherit from Validator<T>. This allows them to define other entry point methods
		 (like Requires() and Ensures()) that integrate with the existing extension methods.
		 
		-Otherwise<TException> method overloads added.
		 The Validation<T> class now has two instance methods that return an internal 
		 OtherwiseValidator<T, TUncheckedException> class. These two overloads allow the user to specify
		 a custom exception to be thrown, because Requires and Ensures only allow ArgumentException and
		 PostconditionException to be thrown.
		 
		-Evaluate(bool condition, string description) overload added according to work item 7469.
		 see: http://www.codeplex.com/conditions/WorkItem/View.aspx?WorkItemId=7469
		 
	Changes to project and solutions:
		-Unused references removed from CuttingEdge.Conditions project.
		 The only references that are used by the project are System and System.Core. Others are removed.
		 
		-Release build of CuttingEdge.Conditions project doesn't build a .pdb file anymore.
		 Loosing the .pdb file enables developers to have a local copy of the project on their machine, and
		 include the release build of CuttingEdge.Conditions.dll to their own project, without jumping into
		 CuttingEdge.Conditions' source code every time a precondition validation failed.


Version 1.0.1.0 (v1.0 beta 1) 2008-07-11
	General description:
		Initial release.