System.FormatException

Not sure if still relevant, but I recently ran into this same issue and was able to solve it by calling a different method to add the header information:

var http = new HttpClient();
http.DefaultRequestHeaders.TryAddWithoutValidation("Authorization", "key=XXX");

By Antonio. Read the original answer on Stack Overflow.

You need to add the Time separator to your string. Try this:

TimeSpan ts = XmlConvert.ToTimeSpan("PT72H");

See the duration specification - http://www.w3.org/TR/xmlschema-2/#duration

3.2.6.1 Lexical representation
The lexical representation for duration is the [ISO 8601] extended format PnYn MnDTnH nMnS, where nY represents the number of years, nM the number of months, nD the number of days, 'T' is the date/time separator, nH the number of hours, nM the number of minutes and nS the number of seconds. The number of seconds can include decimal digits to arbitrary precision.

Edit/Update based on comments

As there was some question as to why the string P2M2W5D would not be considered a valid TimeSpan since W is part of the ISO 8601 standard, I wanted to add this update so that if someone runs across that issue they don't have to read through the comments to get the answer. The issue, both for the original string in question P72H and P2M2W5D is that the string must conform to the W3C XML Schema (see the documentation for XmlConvert.ToTimeSpan). When we look at the W3C XML Schema (link above), it references back to the ISO 8601 standard, and in particular to section 5.5.3.2.1 which gives the reason why W is not a valid character in the XML Schema:

Since weeks have no defined carry-over point (52 or 53), weeks should not be used in these applications

By pstrjds. Read the original answer on Stack Overflow.

I've got it. And yes, it's a bug.

The problem is that there are two levels of string.Format going on here.

The first level of formatting is something like:

string template  = string.Format("Expected: {0}; Actual: {1}; Message: {2}",
                                 expected, actual, message);

Then we use string.Format with the parameters you've supplied:

string finalMessage = string.Format(template, parameters);

(Obviously there's cultures being provided, and some sort of sanitization... but not enough.)

That looks fine - unless the expected and actual values themselves end up with braces in, after being converted to a string - which they do for Size. For example, your first size ends up being converted to:

{Width=0, Height=0}

So the second level of formatting is something like:

string.Format("Expected: {Width=0, Height=0}; Actual: {Width=1, Height=1 }; " +
              "Message = Failed expected {0} actually is {1}", struct1, struct2);

... and that's what's failing. Ouch.

Indeed, we can prove this really easily by fooling the formatting to use our parameters for the expected and actual parts:

var x = "{0}";
var y = "{1}";
Assert.AreEqual<object>(x, y, "What a surprise!", "foo", "bar");

The result is:

Assert.AreEqual failed. Expected:<foo>. Actual:<bar>. What a surprise!

Clearly broken, as we weren't expecting foo nor was the actual value bar!

Basically this is like a SQL injection attack, but in the rather less scary context of string.Format.

As a workaround, you can use string.Formatas StriplingWarrior suggests. That avoids the second level of formatting being performed on the result of formatting with the actual/expected values.

By Jon Skeet. Read the original answer on Stack Overflow.

Try this instead:

Assert.That(() => Int32.Parse("abc"), Throws.Exception.TypeOf<FormatException>());

Basically you need to pass a delegate to Assert.That, just like the documentation in your link states (note that I've used a lambda expression here, but it should be the same).

By Klaus Byskov Pedersen. Read the original answer on Stack Overflow.