Catch ArgumentException as well as BadImageFormatException when failing because of libraries without resources

[Forgind]

This was a heinous bug to repro.

Using VS 17.0.0+, create a blank UWP app with target platform version 16299 or 17134. Build Debug/x86.
If that doesn't work, clean and build again.
If that doesn't work, clean and build again.

It should work every time, but from my testing, every other clean-build cycle succeeds even following identical steps. Every other build clean-build cycle fails with a message saying an attempt was made to load a file with incorrect format. This is normally a BadImageFormatException and caught (see comment above), but it seems that with dev 17, that is sometimes (always?) wrapped in an ArgumentException and not caught. This fixes that problem by catching both.

Maybe we should verify that the ArgumentException mentions BadImageFormatException before just continuing?

Testing: Several attempted repros in a row succeeded. It had been pretty reliably failing every other time, so that was a shift.

[rainersigwald]

I'm concerned that this isn't the full root cause. What is different in dev17? Have you falsified the caching hypothesis I proposed offline?

[rainersigwald]

Is there something where we can test an InnerException to validate that this is really the case?

[rainersigwald]

We looked at this and found https://referencesource.microsoft.com/#mscorlib/system/reflection/module.cs,857

[Forgind]

Incorporated, thanks!

[Forgind]

The repro seems complicated by every other clean-build cycle succeeds even following identical steps. Not sure what could cause that—marcpopMSFT suggested maybe creating a cache then invalidating it on subsequent builds, but if you create a cache, you should use it in the same step, and if you invalidate a cache, you shouldn't use that cache.

That the error message explicitly says it's a BadImageFormatException (even though it's an ArgumentException) and that we were previously catching BadImageFormatExceptions makes me fairly confident it's just a slight change in what error is being thrown. Furthermore, I tried cleaning and building several times with the blanket catch (ArgumentException) and the more specialized one I now have, and in both cases, the rate of failure went from 50% to 0% (in my tests), which suggests the same.

[rainersigwald]

Let's go ahead with this since we (sorta) said we'd get it in for preview2.

(I still want to know what's up with the intermittent failure/toggle behavior, but this change looks good independent of that.)