Serialized Declarations used by the unit test do not match the "production" declarations.

[comintern]

At some point, changes were made in either the ComReflection namespace that changed the declarations returned by the ReferencedDeclarationsCollector. The serialized libraries that are used by the unit tests were not updated. This means that any unit test that relies on a set of SerializableDeclarations is now suspect.

When I attempted to update them for PR #4189, I was greeted with 34 failing tests and hundreds of lines spamming the output window like these:

2018-07-15 19:15:39.7880;WARN;Rubberduck.Parsing.Symbols.TypeAnnotationPass;Failed to resolve type MsoSyncEventType;
2018-07-15 19:15:39.8040;WARN;Rubberduck.Parsing.Symbols.TypeAnnotationPass;Failed to resolve type MsoScreenSize;
2018-07-15 19:15:39.8040;WARN;Rubberduck.Parsing.Symbols.TypeAnnotationPass;Failed to resolve type MsoEncoding;
2018-07-15 19:15:39.8040;WARN;Rubberduck.Parsing.Symbols.TypeAnnotationPass;Failed to resolve type MsoTargetBrowser;
...

I do not get the same warnings when I run RD from Excel or in a debugger. So... it's difficult to tell if the unit tests are bad or if they actually should be failing. I suspect that it is a mix of both. For example, the serialized set that I just created likely would have failed tests covering the Excel.Application resolver problem in #4096

The current, up to date declaration set can be downloaded for testing from this link on Dropbox. These are the ones that I would have PR'd included with #4189.

I probably should have realized what was going on when I opened #4182, so take a look at that issue also.

[bclothier]

Instead of serializing declarations, would it be better to maintain .idl files, which can be compiled without a backing implementation. That then can be unit-tested without going stale since we now have to actually load the type library and can reliably load it since we are now generating it ourselves?

For contributors that don't have C++ build tools (and therefore MIDL compiler), the tests can be set up to fall into inconclusive state. However, AppVeyor has MIDL so we can rely on it to always test those.

[comintern]

@bclothier That's probably not a bad idea at all, especially given the way we're currently using them in the tests. What makes that an even better idea is that we could finally write unit tests for the ComReflection namespace.

[MDoerner]

Dumb question: do the library paths for the freshly serialized declarations agree with those specified in the MockVbeBuilder?

I think, if you update the serialized declarations by new ones generated with a different location of the libraries, the values in the MockVbeBuilder have to be updated as well.

[comintern]

@MDoerner Not a dumb question (and yes, I'm an idiot) - they're different. I'll update after work and if everything is kosher I'll get the tests updated and open a new issue for @bclothier 's suggestion.

[comintern]

Pathed fix and new declarations inbound, removing critical, can't find the [comintern-is-moron] tag.