Get decompiled code source for an external symbol from DLL for analysis

[SENya1990]

Dear Roslyn team,

I would like to know if there is a way to get code sources for external symbols defined in DLLs.

I am writing an inter-procedural analyzer that needs to step into called APIs. This works fine for calls to the code that is declared in the same solution. However, for the external symbols Roslyn can't obtain sources.

At the same time, Visual Studio's "Go To Definition" command can go to the decompiled sources, if the decompilation is enabled in VS settings. The decompiled code is recognized by Roslyn, I can get AST and semantic model from the opened document with the decompiled code. Therefore, I wonder if I can somehow get the decompiled sources in my analyzer at least for some cases.

Thanks in advance.

[jasonmalinowski]

We get the decompiled sources by calling into ILSpy which has a library for doing so. So you could (theoretically) call into that if you'd like. That said...decompilation isn't always accurate and potentially quite slow which would not be a wise idea to put in an analyzer. What type of analyzer are you trying to build?

[SENya1990]

@jasonmalinowski thank you for the answer!

My analyzer is a regular Roslyn analyzers run from VS. I also have a console app to run it in CI, but its main usage scenario is still to display errors in VS.

My employer develops a complex application with its own customization platform which is used by partners to write plugins that reference application dlls.

The analysis checks that several forbidden APIs are not called in some special places in the code. Usually, these special places are methods and I need to check that all APIs called in their bodies also do not call forbidden APIs.

When my analyzer runs on an application plugin, I would like for it to be able to step into application dlls to check that forbidden APIs are not called inside application dlls.

here is a simplified example. Suppose that it is forbidden to call File.Open API from some special places (let it be SpecialMethod) in the plugin. So, my analyzer starts from a SpecialMethod in the plugin, and sees, that in this method the Helper.SomeMethod API from the external application dll is called.

This Helper.SomeMethod internally may call File.Open API. It isn't wrong to call File.Open API inside the helper itself, because the helper may be called from the place which allows calls to the File.Open API. But this means that Helper.SomeMethod can't be called from SpecialMethod because this will lead to a call to the File.Open.

This is why I want to be able to get sources from external dlls in order to step into them. I hoped that VS has some ready to use functionality since it already has the decompilation feature. If the performance is very bad, then perhaps I shouldn't go after this feature.

[jasonmalinowski]

Roslyn analyzers would be best tailored for not the analysis on the final binary, but rather for your partners writing the plugins themselves. For example, you'd write that analyzer directly, and it'd run on their machines while they are developing to help keep them on the right track. This of course doesn't ensure that the resulting plugin DLL is compliant (after all a partner could have disabled the warning, etc.).

But for analyzing a built DLL, Roslyn doesn't help you here. You'd want to look at other projects like ILSpy, or metadata readers, or something else for analyzing method bodies. That sort of analysis is explicitly something Roslyn doesn't do. The IDE feature you're seeing of decompilation is just us calling into ILSpy's library -- we just take their binaries and ship it as a part of Visual Studio.

[jasonmalinowski]

You might be able to do something where you have ILSpy decompile a binary and feed it back to a Roslyn analyzer; I'm not aware of somebody having done that before but maybe somebody has.

[SENya1990]

You might be able to do something where you have ILSpy decompile a binary and feed it back to a Roslyn analyzer; I'm not aware of somebody having done that before but maybe somebody has.

Thanks! Seems like this is the answer I'm looking for. Is there any public code in Roslyn calling ILSpy that I can use as an example?

[SENya1990]

@jasonmalinowski you misunderstood me a little.

For example, you'd write that analyzer directly, and it'd run on their machines while they are developing to help keep them on the right track. This of course doesn't ensure that the resulting plugin DLL is compliant (after all a partner could have disabled the warning, etc.).

That's exactly how it works. Partners develop their plugins in VS as a regular solutions with projects. My analyzer works while they write code. The thing is, their plugins reference a large set of external DLLs, the customization platform. This platform is shipped as a set of DLLs, without the source code. The analyzer works on the plugin source code in VS on local machines of partner developers. It may see a call of some external API from a DLL that belongs to the customization platform.

The analysis goal is to prevent the usage of some forbidden APIs from special methods in the code. The calls to external APIs also should be checked for the presence of calls to forbidden APIs. So, the analyzer should do the inter-procedural analysis and step into such calls. If they contain such calls, then the calls to these external APIs should be reported as errors.

And that's where the issue appears. There is no problem to make inter-procedural analysis and step into API calls for APIs declared in the same solution. We have source code for such APIs inside the solution. However, there is a problem with stepping into external APIs from DLLs because there is no source code there.

[jasonmalinowski]

I'd say the reasonable approach is if you own the analyzer and you also own the "customization platform" there, then have a tool that figures out which methods are problematic in which contexts and feed that to the analyzer to know. Or have a source generator generate attributes on the problematic members which the analyzer can see.

If you don't control that platform though then I don't have a good answer for you other than "reconsider your design" since the only way you can then analyze methods from this other library is to potentially chase through what it might call, and that becomes hugely thorny. Roslyn intentionally excluded supporting this sort of scenario because of the complexity it brings.

[jasonmalinowski]

That said, if you were needing a full analysis here, then you might be much better off having a command line tool that does the analysis but doing it via metadata reading APIs, something like System.Reflection.Metadata or Mono.Cecil.

[SENya1990]

@jasonmalinowski thanks again for your suggestions.

I do not own the customization platform. I omitted some details previously for simplicity. The platform provides customization mechanisms of the functionality of original application to simplify the development of plugins. It is somewhat similar to IL weaving techniques and Harmony (https://github.com/pardeike/Harmony).

This means that it is close to impossible to manually annotate or collect problem APIs. The application is too big for that, it's written by many developers. With source generators it may be possible but again there are problems:

• This will probably increase the build time for the product (even if the annotation will be run only on build servers). This will affect the whole company work. It will be hard to justify this change just for the static analysis improvement.
• Again,I omitted some details previously for simplicity. I have more than one inter-procedural analysis. Most of them boil down to "forbid calls to certain APIs from a certain place". However, the details of the analysis will be different for each of them, it will require quite complex annotation.
• The customization platform allows for some partners to create their own large plugin solutions which can also be customized by their consumers. It will be hard to control that all of them annotated their code correctly.

[SENya1990]

First, short summary of my answer.
In my opinion, it would be more practical to drop the idea of analyzing external dlls than switching to Reflection or Mono.Cecil.
We actually have some reflection-based validations of plugins made at runtime, but, in my opinion, in this context they have too many downsides.

Here is the long explanation why I think that way.

1. Great UX

Roslyn displays errors directly in the code editor while you write the code. This is a huge feature for developers. Reading results from the command line app is far less convenient.

2. Speed of incremental analysis.

Roslyn diagnostics work incrementally on a modified solution and and the analysis via the command line app is not incremental. It will have to analyze the whole DLL, not a particular file. Therefore, it will take much more time.

This static analysis is also used by our application developers, they don't have the issue with external DLLs. I'm afraid that switching to a console app for analysis with all related downsides will make them very frustrated. I already have such application running during our testing in CI environment, so I have some experience with how long the analysis takes.

3. Binary/IL analysis downsides.

In addition to the downsides from switching analysis to the console app, the complete rewrite of the analysis with Reflection or Cecil also has its own downsides:

• I imagine that mapping error found in the IL code to the actual source code will be a very hard task, similar to decompilation. And without such mapping the analysis will be much less useful for developers
• Roslyn APIs are very convenient and simple to use for me. They work directly with C#. Roslyn allowed me to write even more complex analysis that tracks down the data passed to called APIs. I don't think I will be able to write IL analyzer with the same level of efficiency.
  Frankly, I'm not an IL expert, and so it will be a much more complex task for me.
• There is a lot of analysis code to rewrite now, it will require a lot of resources. These resources won't be spend on other analysis features, so it doesn't look like it will worth it.
• The simple straightforward nature of Roslyn has another advantage. My analysis is an open-source project, there are external contributors from partner developers who write some diagnostics under guidance. I doubt, there will be such contributors with IL analyzers due to the difficulties related with this task.

[jasonmalinowski]

I imagine that mapping error found in the IL code to the actual source code will be a very hard task, similar to decompilation. And without such mapping the analysis will be much less useful for developers

I'd expect that to be easier than looking at decompiled source, actually -- ILSpy's decompilation has a bunch of heuristics to "undo" where code appears to be versus where it actually is -- things like lambdas and such mean the compiler creates lots of hidden types and members.

As one more possible suggestion: have the console app walk the customization platform via metadata reading to build the list of problematic methods, and have it spit out a file with the list in some form. They can check that file into their repo. Then have your analyzer consume that list, which is easy to do and means the expensive metadata reading (and computing "this method calls that method, and that method is the evil one") is done up front.

[SENya1990]

@jasonmalinowski thanks again for the information and the ideas. I would say, that I now have an interesting idea for experiments with IlSPy.
I will close this question now. If there is a public code in Roslyn that calls IlSpy, then I will be very grateful if you can provide a reference to it.

[jasonmalinowski]

Take a look here: https://github.com/dotnet/roslyn/blob/b6ed7a5f13a3f00e7edf8cc4fab0d4524251f056/src/LanguageServer/Protocol/Features/DecompiledSource/CSharpCodeDecompilerDecompilationService.cs