Debugging Assemblies loaded via Reflection
Posted 09 August 2012 - 10:23 PM
Posted 10 August 2012 - 06:05 AM
Just to clarify--are you stating that MF can debug assemblies loaded via reflection...and are asking why it can do this?
In regular framework assemblies loaded via reflection are debugable. Why can the MF debugger break inside of these DLLs?
Posted 10 August 2012 - 03:20 PM
Posted 10 August 2012 - 04:17 PM
Posted 10 August 2012 - 05:23 PM
Posted 10 August 2012 - 06:24 PM
Yes, one project is what you have today (Production) and one new one (debug) that just references the library as a standard .dll
You have 2 projects and the ND startup is 'referencing' your library?
Your deployment grabs the library project and loads it to the flash chip? How are you referencing the library at this point? Standard reference or reflection?
Standard reference, just like any other .dll you include. Yes, at deploy time the .dll will be sent to the flash at the same time as your exe because it is just another .dll.
(At the risk of confusing the issue: an alternative approach might be..)
To make it easier to code, another alternative is to add a "library" subdirectory in this new (call it debug) project and add your library source as links into this subdirectory. That way the compiler knows to recompile the changed "library" code along with your program on any changes at build time. This way you are not dealing with two projects (one to build the dll and one to build your debug program) The downside is that you have to manage "who is calling who" to make sure you don't break your dll by referencing something that will become out of scope in your production build.
Nothing different. I am sure you are doing this now. I just load the assembly and call the starting method.
What exactly are you doing here differently in your calling startup assembly?
Posted 10 August 2012 - 07:20 PM
Posted 11 August 2012 - 09:47 AM
Posted 13 August 2012 - 04:30 PM
To debug into a DLL, Visual Studio uses the DLL's corresponding PDB files (found in your project's bin\debug folder). When you deploy an application to your Netduino, Visual Studio knows where to locate these PDB files. When you dynamically load a compressed .PE assembly, I'm guessing that Visual Basic has no idea where to find the source or PDB (debugging info).
More info on PDBs:
If you need to debug the .PE assembly, can you add just that assembly's project to your solution and then create some weak link to it (such as creating of some object within it)...so that NETMF loads your class? If so, it might then be possible to debug into that DLL (since you'll be debugging the deployed PE rather than the one on the SD card).
It would be really cool to add a feature to Visual Studio which let the developer select the DLL/PDB for a .PE loaded dynamically at runtime. There may be a way to do this today but if there's not, I recommend requesting it as a new feature at netmf.codeplex.com.
Posted 13 August 2012 - 05:36 PM
There it shows which symbol file (pdb) is being used to debug the dll and it can be changed manually. In my case though it receives a "No symbols loaded" status. When I directly point to the pdb file in the le build directory it says "A matching symbol file was not found in this folder." Well that is impossible because I'm looking right at it and the date/time stamps match with the PDB file and the PE file.
Posted 13 August 2012 - 05:43 PM
Posted 13 August 2012 - 06:42 PM
Posted 13 August 2012 - 07:33 PM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users