3

I'm developing .NET application that draws some information on the screen. During the development it is very convenient to use Visual Studio's "Edit and Continue" feature, to make slight changes in code and have it immediately reflected on the screen. The problem is, the screen re-draw should be manually triggered, and I have no way of knowing when did "Edit and Continue" happen.

My app is actually a plugin of big third-party system and initialization (app launch) takes some time, so it's too costly to just stop debugging and restart on each small change. I would like to somehow "catch" the moment when the code has been changed in my running application, and trigger the screen refresh, so to have a "live refresh" of some sort.

The "Edit and Continue" mechanism apparently patches the code directly in memory, so monitoring the file changes on disk gives nothing. I even went so far to enumerate process' memory pages to detect changes in code section but... CLR process memory layout proved to be much complex (especially in debug mode) so that I couldn't find the working solution... In a "native" C++ app one could calculate the checksum of code section in memory periodically, but that isn't as simple in .NET app. Finding the changed code in memory is not easy because the CLR-generated x86 code is scattered over different pages (as opposed to "ordinary" native process).

I'm willing to go as far as to integrate some sort of Visual Studio interop solution, to use it's API to monitor that event... but with my (limited) research on VS SDK couldn't find an API that gives just that...

So... is there ANY way (even "hackish") to detect in my running application, when the "Edit and Continue" happens? There should be some CLR "event" that happens when Visual Studio injects modified code... or some other changes in a running application's memory (for example) that can be detected. Any sort of low-level manipulation (like API hooking) is acceptable, as long as it will work consistently.

Titan
  • 2,875
  • 5
  • 23
  • 34
  • No extensibility notifications for that, it is knowable only to [a debugger](https://learn.microsoft.com/en-us/dotnet/framework/unmanaged-api/debugging/icordebugmanagedcallback2-functionremapcomplete-method). That's one heck of a rabbit hole. – Hans Passant Mar 27 '19 at 16:13
  • 1
    @HansPassant, When VS does patching of the target process, does it update the IL bytecode present in the PE data directories (in memory), or does it just patch the x86 instructions on the fly (basically JIT-compiling changes without bothering to update PE metadata)? If the first is the case (which it should be), maybe I can find the location (by navigating through metadata streams in PE file) where IL is stored, and monitor its checksum? Do you think this is a viable option to spend time investigating? – Titan Mar 27 '19 at 16:30
  • 1
    Why is this not a super popular question? It seems like such an obvious thing to want ... Have you made any progress regarding this or did you just give up? – Paul Aug 13 '20 at 09:55

0 Answers0