Ensure.That has been around for quite some time (2011-08-23). With the new release (v7.0.0) there are some changes, e.g. targeting .NET Standard 1.1 & 2.0 as well as .NET4.5.1 and a new contextual API. But it's also time to finally deprecate the old API lurking around in there, namely the Ensure.That flavor. So instead of:
Ensure.That(myValue, nameof(myValue)).IsNotNullOrEmpty();
You should instead start using one of the flavors shown below.
Using contextual validation
Ensure.String.IsNotNullOrWhiteSpace(myString);
Ensure.String.IsNotNullOrWhiteSpace(myString, nameof(myArg));
the value is passed through so that you e.g. can assign it to a field:
_field1 = Ensure.String.IsNotNullOrWhiteSpace(myString);
_field2 = Ensure.String.IsNotNullOrWhiteSpace(myString, nameof(myArg));
Using static simple methods
EnsureArg.IsNotNullOrWhiteSpace(myString);
EnsureArg.IsNotNullOrWhiteSpace(myString, nameof(myArg));
the value is passed through so that you e.g. can assign it to a field:
_field1 = EnsureArg.IsNotNullOrWhiteSpace(myString);
_field2 = EnsureArg.IsNotNullOrWhiteSpace(myString, nameof(myArg));
Why am I removing it?
One reason is: "I don't use that flavor my self anymore and do not want to maintain three flavors.". The reason for me not using it is that the Ensure.That construct creates a new instance of Param<T> or Param every time you call it. Maybe this isn't that big of an deal for a few calls, but used in a loop where lots of values are being passed to a method that operates on these values after validating the input args... So, with this in mind, it's been marked as Obsolete generating a warning and will be removed in the next major version.
Another reason is, that the Ensure.That(..., ...) flavor allowed you to extend exception messages etc. Even throw completely other exceptions. This kind of goes against the intentions of being a simple and somewhat opinionated and just be about argument validation. The exception messages should be good enough. If not, feel free to issue a pull request. They are intended for devs/ops in logs etc. not for bubbling up to end users.
Feel free to disagree. And if you strongly disagree, feel free to fork, adapt and publish under a new name.
Cheers,
//Daniel