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.