0

I have a system in production that started having problems. The code targets .NET Framework 4.5.2. I have the following issues:

  • there is no formalized build and deployment process. So I don't know which version of the code is deployed
  • Judging from comparing the available source with decompiled DLLs from production, I don't seem to have a match on any branch. It looks like someone made a version outside source control and manually derployed it
  • people who worked on the system have left the company years ago, and nobody who's left has any knowledge of the system

I've been trying to restore the code by decompiling the dlls, with plans to add logging and hot-swap the dll to trace the issue.

I have problems with some of the dlls (3 projects out of 11, maybe 10 classes in total). For some of the classes the decompiler produces a lot of code that looks like this:

  [AsyncStateMachine(typeof(<AcceptSalesAgentLeadAssignment>d__9)), HttpPost]
        public Task<bool> AcceptSalesAgentLeadAssignment(SalesAgentWithLeadAssignmentsUpdateModel leadAssignment, string accountGuidAuth)
        {
            <AcceptSalesAgentLeadAssignment>d__9 d__;
            d__.leadAssignment = leadAssignment;
            d__.accountGuidAuth = accountGuidAuth;
            d__.<>t__builder = AsyncTaskMethodBuilder<bool>.Create();
            d__.<>1__state = -1;

From what I could find online this has to do with anonymous functions being present in the original source code. This in itself wouldn't be so bad, but the problem is this code is unbuildable. It's generating literally thousands of errors such as the following:

The name d__9 does not exist in the current context.

I have tried the following tools: JetBrains DotPeek, dnSpy, Telerik JustDecompile, .NET Reflector from redgate. They all produced this unbuildable code.

I don't need the resulting code to be fully human-readable. I just need to be able to produce dlls that are functionally identical to what's in production, so that I can gradually add log statements and trace the issue. I understand that the decompiler can't work out what the man-made code used to look like, but it should at least be able to produce something that's logically equivalent and buildable. Is there a way to achieve this?

Shaggydog
  • 3,456
  • 7
  • 33
  • 50
  • 2
    it's the [async state machine code](https://stackoverflow.com/questions/45216388/c-sharp-asyncstatemachine-decompile). – Andy Apr 27 '21 at 19:41
  • I would try to build existing code base and using [assembly diff](https://stackoverflow.com/a/652459/2501279) to figure out what has changed. If there are not that many changes maybe it would be easier to just reverse engineer the difference and backport it. – Guru Stron Apr 27 '21 at 20:02
  • Also for dotPeek try checking if [Show compiler-generated code](https://www.jetbrains.com/help/decompiler/Viewing_Compiler_Generated_Code.html) option is disabled. – Guru Stron Apr 27 '21 at 20:05
  • [ILSpy](https://github.com/icsharpcode/ILSpy) can decompile async state machines just fine. – madreflection Apr 27 '21 at 20:08

1 Answers1

1

Thanks to Andy's comment, I was pointed to a tool called IL Spy. It produced a code that was very clean and almost buildable. For some reason it couldn't handle using statements, and made a mess of switches. But that was an easy fix. Thanks Andy.

Shaggydog
  • 3,456
  • 7
  • 33
  • 50