Decompiling a .NET Framework v4.5 executable "not .NET assembly file" in dotPeek but executable runs fine

Question

A client has burned bridges with their previous dev and I'm trying to extract source code from what's left of their payroll executable, unfortunately as a web dev I do not have much experience with the .NET framework.

EDIT: Our client legally owns the software but did not ask for source code, the developers aren't responding to our communications. My intention of asking this question on SO was not for legal advice (we've got people handling that) but for any options available for decompilation.

I have decompiled executables with JetBrains dotPeek successfully before, however they all ran the .Net Framework v2.0/v4.5 frameworks. The client's payroll executable I'm working with at the moment runs .Net Core v4.5 which is not recognised by dotPeek, ILSpy or other C# decompilation software I've run as a .NET assembly file.

After a little research, I believe .Net Core was recently open sourced... however I'm not sure how I can proceed through the decompilation process, or if it is even possible at this point. Any recommendations?

Note: I will accept an answer along the lines of "it is impossible to decompile, but have you tried X, Y, Z first?". I need to let the client know if it can be done or not since we're running a tight schedule.

Some clarification of what I did: Opened program.exe in dotPeek, right-click properties is giving me this:

It claims "Not .NET assembly file", but I can run the executable fine.

EDIT: Is it possible to extract more information from the executable so I can narrow down another method to decompile?

I suspect .NET decompilers aren't going to help here.

Answer 1

The developer asked a legitimate programming question on a development website and deserves an educated response. Not unwanted legal advice. There are many legitimate reasons for decompiling a dll.

When dotnetpeak suggest that a file was developed using ".Net Core v4.5" and has no MVID it would suggest that the file is missing a CLR header.

If you decompile the file back to assembly you will probably find identifying markers that the file was developed in VB6.

Find a good VB6 de-compiler and you'll probably be able to de-compile the program without much of an issue. Unfortunately you can't fully de-compile vb6 back to source-code, but you can get a pretty good understanding of how the application was constructed.