7
Vote

POSTPONED: Debugging Assemblies via Reflection can not be accomplished without a weak reference

description

In the event of loading dynamic assemblies from an external source such as a Netduino with an SD card, Visual Studio is unable to reference the PDB file. Normally it is supposed to look in the directory of the dll or PE file but in this case the external assembly location is off of the memory card. When viewing the modules at runtime after the assembly is loaded, the symbol status shows 'No symbol loaded'. If you point the symbol reference to the PDB file you receive "A matching symbol file was not found in this folder." This is untrue for the following reason...
 
If the assembly that calls the external assembly via SD card were to have a weak reference of that external assembly locally, it will in fact accept the PDB file and debug the external assembly on the memory card. But this is NOT dynamic loading any more is it?

file attachments

comments

Bendage wrote Sep 12, 2012 at 2:30 AM

Any review on this?

lorenzte wrote Sep 12, 2012 at 5:18 PM

We will try and fix this issue for 4.3

ZachLibby wrote Sep 18, 2012 at 6:56 PM

This is actually a little more complicated than it seems. The problem is that our PE files do not contain a timestamp. This is the same problem we have with the VS debug attach feature: you can attach to a device, but when VS inspects the assemblies on the device it cannot match them with the PDB because the timestamp is not correct. To fix this we may have to change the layout of our PE files. I am not sure if the fix is worth the risk in this case. Deployment works because behaves differently by matching the DLL with the PDB before deploying the PE files. We may be able to investigate this further and see if we can come up with a different solution, but for now it does not look likely. BTW, adding the weak refrence probably works because you are deploying the assembly and loading it twice.

chrisw_secretlabs wrote Sep 19, 2012 at 5:38 PM

Zach -- thanks for all your research on this. I just realized that there are several use cases (in a new upcoming NETMF-based platform we're working on) where this type of debugging will be necessary for developers. We're willing to help thoroughly test it out.

lorenzte wrote Sep 20, 2012 at 4:49 PM

We do recognize that this is an important scenario and we will address it. We will not be able to fix this for the 4.3 release.

wrote Sep 25, 2012 at 8:06 PM

We will not fix this for the v4.3 release.