WP7 emulator + Microsoft.Advertising.Mobile.Xna.dll = 'System.IO.FileLoadException' occurred in mscorlib.dll

Question

I've downloaded Microsoft Advertising SDK for WP7, added reference to Windows Phone Game project, and now when I'm trying to run the game I get this in Output:

'taskhost.exe' (Managed): Loaded 'mscorlib.dll'
'taskhost.exe' (Managed): Loaded 'System.Windows.RuntimeHost.dll'
'taskhost.exe' (Managed): Loaded 'System.dll'
'taskhost.exe' (Managed): Loaded 'System.Windows.dll'
'taskhost.exe' (Managed): Loaded 'System.Xml.dll'
'taskhost.exe' (Managed): Loaded '\Applications\Install\B2719AD1-5A3C-40BE-A114-7E56C19E22D6\Install\TheGame.dll', Symbols loaded.
A first chance exception of type 'System.IO.FileLoadException' occurred in mscorlib.dll
The thread '<No Name>' (0xd4b004e) has exited with code 0 (0x0).
The program '[229048418] taskhost.exe: Managed' has exited with code 0 (0x0).

If the reference is removed, game launches normally again.

What might be the possible solution to fix this?

Answer 1

Does your application actually fail to run, or does it just print that message to the output window and continue (there's no timestamps in the output window, alas, so I can't tell how much time elapsed between the first-chance message and the program-is-exiting message)?

First-chance exception messages like that aren't always indicative of a problem that needs to be solved, especially if they occur in code that isn't yours (unfortunately).

If you are crashing, I've seen this issue (and a fix for it) regarding WP7 development tools and another external assembly (not the Advertising SDK directly, but perhaps it's a related problem that could be solved with the same steps).

Other things you might try include turning on "break on throw" for all managed exceptions and disabling "Just my code" in the Options section of Visual Studio to see if you can break into the debugger when the exception is thrown -- this will let you examine the exception's FileName property and determine exactly which assembly isn't loaded -- this exception is thrown generally when the CLR finds an assembly but can't get it to load for whatever reason.

It's possible you won't be able to trap the exception if if occurs too deeply in code that belongs to the CLR loader, in which case you may need to use WinDbg or load the SOS.dll directly into VS to trap and print the exception (look into sxe clr in WinDbg and !pe from SOS).