13 replies to this topic

[Bendage]

There are some great articles written on how to load a DLL from a memory card through MF. The problem is, every time you have a bug you need to pull the card out, compile, copy, reinsert, and retest. When you are dealing with rather large DLL plugins it is rather cumbersome repeating this 50x a day. In regular framework assemblies loaded via reflection are debugable. Why can the MF debugger break inside of these DLLs?

[Chris Walker]

Hi Bendage,

In regular framework assemblies loaded via reflection are debugable. Why can the MF debugger break inside of these DLLs?

Just to clarify--are you stating that MF can debug assemblies loaded via reflection...and are asking why it can do this?

Chris

[Bendage]

Hi Chris, No. I'm saying that the full Windows framework can load assemblies via reflection and the code from the external dll can be stepped through. Not so (or at least I can't figure out how to) with micro framework when you load the dll onto the SD card. It steps over any code called inside the assembly. If per say the debugger just won't allow that (there must be a way)... then how might I at least push out the dll onto the flash chip with the rest of the build and load it from there? Doubt it is possible but sure would be a lot easier than having to pull the SD card and load the assembly every build (50x a day). Thanks for inquiring about clarity. I had a really cool project I invested a ton of hours in last year and walked away out of frustration.

[AxelG]

I may not understand the question, but I have done this in the past to help debug: I create a simple program that includes the .dll as a library. I then flash this to the ND as a single program (no loading assemblies from sd) I do all of my debugging there as normal. When I am ready to deploy in Production, I just deploy the obj/Release/le/*.pe (Associated to my .dll) to SD and load my "bootloader" program through regular deployment. There is about 3k to 4k of overhead for doing it this way (including a .dll with your main program) until you load your final assembly. Maybe?

[Bendage]

Axel, Thank you for your reply. Let me try to understand the way your app is set up... "I create a simple program that includes the .dll as a library." - You have 2 projects and the ND startup is 'referencing' your library? "I then flash this to the ND as a single program (no loading assemblies from sd) I do all of my debugging there as normal." - 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? "When I am ready to deploy in Production, I just deploy the obj/Release/le/*.pe (Associated to my .dll) to SD and load my "bootloader" program through regular deployment." - What exactly are you doing here differently in your calling startup assembly?

[AxelG]

You have 2 projects and the ND startup is 'referencing' your library?

Yes, one project is what you have today (Production) and one new one (debug) that just references the library as a standard .dll

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.

What exactly are you doing here differently in your calling startup assembly?

Nothing different. I am sure you are doing this now. I just load the assembly and call the starting method.

[Bendage]

I like your idea. There is one problem. The dlls I am referencing through reflection are in fact being called by a dll library... a rather complex one that is being called/referenced by the start up project. If I make a separate library engine, one for debugging and one for production, it makes this tool harder to use by other developers which negates the whole project together... http://forums.netdui...h__1#entry27177 Take a look at this and you can understand that these reflection dlls are actually plugins based on a plugin interface.

[Chris Walker]

Hi Bendage, 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: http://www.wintellec...-must-know.aspx 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. Chris

[Bendage]

Extremely helpful!!!! A weak reference to the the dynamic dll in the startup project did the trick. Though not a smooth way of doing it, the dlls are now debugable. And you are right, an option to specify where the debugger can find those PBX files for an external dll would be very beneficial.

Thanks Chris!!!!

Game on!

Hi Bendage,

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:
http://www.wintellec...-must-know.aspx

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.

Chris

[Bendage]

After doing a little more research, once the dll is loaded from the memory card on the Debug menu, choose Windows, and then click Modules.

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.

What gives?

[Chris Walker]

Hi Bendage, Is this a DLL that was dynamically loaded (as a .PE) or one that you made a weak reference to in Visual Studio? If it's a dynamically-loaded .PE file, the data which links the PDB to the DLL (or rather the DLL to the PE) may be unavailable. Or this may be a good feature request for NETMF vNext. Chris

[Bendage]

Ya it was dynamically loaded. But here is the thing... if I "weak reference" it, AND dynamically load via reflection it points to the same pdb file that says "Matching symbol file not found" and will let me debug via reflection. It appears something can be done to make this better but not 'hooked up" in NETMF I guess This way is all fine and dandy I guess for me but I want to publish this Console engine and developers will have to launch the source of the engine to debug their plugins. That is kind of lame.

[Chris Walker]

Hi Bendage, Can you write up a feature request at netmf.codeplex.com on this? This may or may not be an easy feature to implement, but it would be a really awesome new feature for Visual Studio or .NET MF vNext. Chris

[Bendage]

Done... http://netmf.codeple...m/workitem/1737