App doesn't stop to breakpoint

TinyCLR OS
1

Does anyone know why I can this message
App deployment isok. App runs as expected but I doesn’t stop to break point
I tried to delete the app and tried again but no luck
Any idea’s ?

thanks

image

2

Strange! Any steps for us to try to repro on our end?

3

Did you maybe compile or flash a Release version of the code?
Could you post the output log from a Rebuild-All? Both the ‘build’ and ‘TinyCLR Device Deployment’ text please.

Update: You might also try unchecking “Enable Just My Code” and “Require source files to exactly match the original version” in Tools-Options->Debugging, just as an experiment. You’ll want to change those back later

4

No, I just created a new app.
Not a lot of code so far. Just a neopixel and a sonar but as mentionned, code runs fine…

I tried to unchecked the Enable Just My Code and Require source files but I got the same

Below is the output log for a Rebuild All
Build

image
image766×157 7.64 KB

TinyClr Device Deployment

image
image1496×523 19.2 KB

5

Well, it definitely built and deployed the debug bits. There’s really only a few things that can go wrong - for instance not finding the pdb’s; or not having matching checksums; or not having the file included in the project (if you are in ‘Show All Files’ mode, it will show up in Solution Explorer but not be compiled). I don’t see anything weird in those log images, so I am suspecting something environmental (e.g., in your dev environment).

These are my best-guess next steps:

  1. Make sure that Debug->Options->Debugging->Symbols has “Load all modules” checked.
  2. Check that you have pdb files adjacent to your dll files (in the same dir) and that they have the same timestamp as the dll or exe.
  3. Run ILDasm on one of your .exe (or dll if that code is in a class lib) and make sure you see your compiled code in there.
  4. Try deleting your .csproj.user file, rebuild, and then re-apply your breakpoint.
  5. Erasing your flash and reflashing the TinyCLR firmware and app never hurts.
  6. If that doesn’t do it, try Tools->Import and Export Settings. Export your current settings. Then select Reset All Settings. Try your project again. If that doesn’t fix it, you can re-import the settings you saved.

If you want, you could send GHI or me a copy of your project or a minimal example that repros the problem and I can see if it reproduces for me

6

I have recreated a new project the same way as before.
Added the needed dll’s
Copy the code (all in program.cs at this point) in the new app
And it works fine …

Regarding the original project, Points 1,2 are ok.
I didn’t delete the .csproj but I compared the two with UltraCompare. Except for ProjectGuid, all values are the same.
I didn’t try ILDasm as I am not sure about the options to use here
I tried to erase the app, reflash but it doesn’t help
Note the others project runs fine.
I can send you the project if you want to have a look. I just need your email address

Thanks for your help

7

I’m curious, so yes please, you can send to mcalsyn@pervasive.digital

As for ildasm, you can run it from a VS command window with “ildasm filename.exe”. Also works on dlls. You will see a treeview with all the namespaces, classes, and class members laid out. If you can’t find the class or member function where you are trying to set the breakpoint, then it never got compiled.

Anyway, if you get a chance, please do forward it on. I am always looking for new additions to my menagerie of engineering oddities.

8

Thanks for sending the files Philippe. I found the problem and it’s one for the books (and by that, I mean we better document it :smiley: ).

Your assembly name has an accented character in it. There’s nothing wrong with that - any unicode character is legal, however, that accepted character is breaking the debug symbol matching. That’s a bug, and I have entered it as : Assemblies with diacritical marks in their name cannot be debugged · Issue #735 · ghi-electronics/TinyCLR-Libraries · GitHub

9

Is that a GHI bug or Microsoft? :grin:

10

I see the compiled code with ILDasm (thanks for the tip with the quote)

1 Like
11

@Gus_Issa - almost certainly an MS bug in the original netmf code, but probably not a hard one to fix. Probably just a botched string compare somewhere.

1 Like
12

Thanks Martin, for looking at this. I normally never use accented char for project name. But this project was created for building a robot toy for my grandson (Théo). Always good to know why a system is not working as expected :slight_smile:

2 Likes