[quote=“kisfa”]I believed that my c# code was compiled to some intermediate code ( like CIL?), which was then loaded on the Cobra,
[quote=“kisfa”]where it was compiled to native code by a jitter.
No - the current implementation of .NET Micro Framework does not have JIT, the CIL instructions are interpreted.
[quote=“kisfa”] If it is the case - I thought - I should be able to locate the intermediate code on the FEZ, and after downloading it, with some luck and by the use of ‘Reflector’ (or something similar) I can recover at least some of my source code.
Technically, you can do that, but it would take a considerable effort:
If you don’t have a hardware debugger (JTAG or similar) or the board does not expose debugging interface, you’d have to write a custom application do download the contents of the flash memory. It is possible to do it it .NET, have a look at Microsoft.SPOT.Debugger.Engine.ReadMemory() method in Microsoft.SPOT.Debugger.dll and how MFDeploy.exe uses it.
Then you would need to identify the assemblies in the flash memory - after compilation, the assemblies (.dll) are processed by a special NETMF tool MetaDataProcessor.exe, which optimizes the dlls for deployment: most of the identifier names are removed, strings are placed into special tables and the result is written into .pe file (*), which is then deployed into the flash memory area dedicated for ‘application deployment’ (as you can see in the flash memory map). During deployment, all referenced libraries that are not part of the firmware are written too, then the application. Unfortunately, the NETMF PE format is not documented, you’d need to learn about it from the source code (have a look at files in CLR\Tools\Parser directory).
(*) PE is rather unfortunate name, it is NOT the Portable Executable format.
Then you’d most likely need to create a proper .NET assembly .dll from the .pe file, so you could use one of the existing .NET de-compilers. Alternatively, you could extract just CIL bytecode and use ILdasm.
Then you’d stare at the (at that time rather old) code, scratching your head and trying to understand what was it meant to do, and which stupid developer could write code like that
Personal note: I know from my own experience how unpleasant it is to lose days or even weeks of development time, especially in a team. However, in most cases we never really needed to recover the lost code - we were able to write it again in surprisingly short time and usually in a better way, as we could learn from the mistakes we made earlier…