-
-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ability to disable automatic loading of assemblies #2893
Comments
You can scope search to a specific assembly using |
That's useful but not a solution. This auto-load behavior also occurs when simply browsing assemblies/types. |
This would be nice, I rarely if ever need the reference assemblies that are automatically opened in the tree view. If I do need one of them I can double-click. If ILSpy needs to load reference assemblies to do its job, perhaps don't add to the UI unless explicitly added. |
This will always be the case. However, not adding these assemblies to the list will make diagnosis of problems related to wrong or missing references even more difficult. Many issues reported to us are simply solved by clearing the assembly list and trying again. Invisible references won't improve this. If we add this functionality the quality of the decompiled will decrease if references cannot be found in the current list. |
Perhaps rather than block the loading of assemblies, an option can be added to hide external assemblies unless the user drills into an external type (e.g., by clicking, for example, a Open to other ideas too! |
I already have stated in my above comment that hiding references will not be considered a solution. This will cause more confusion than it will help you. |
I'm confused how you think implementing a solution I suggested would confuse me. My workflow does not need these references to be visible and I'm just brainstorming different solutions. If the team is not interested in the problem, that's cool. Feel free to close the issue. |
Copy of the commit message: "This setting is honored by all functionality that triggers a decompilation run. It is ignored by features that load assemblies as their primary function. For example, using the "Load Dependencies" feature will still resolve and load assemblies from the file-system. The same happens when you double-click on an assembly reference in the tree view. It will be resolved and loaded. Note that disabling automatic assembly load will cause the decompiler to potentially not be able to resolve types from references that have not been added manually and the quality of the decompiled code will be inferior as a result." If you come across any unexpected behavior when using this feature, please report it to us. Thanks! |
This setting is honored by all functionality that triggers a decompilation run. It is ignored by features that load assemblies as their primary function. For example, using the "Load Dependencies" feature will still resolve and load assemblies from the file-system. The same happens when you double-click on an assembly reference in the tree view. It will be resolved and loaded. Note that disabling automatic assembly load will cause the decompiler to potentially not be able to resolve types from references that have not been added manually and the quality of the decompiled code will be inferior as a result.
During normal usage, ILSpy detects and resolves external types and loads assemblies into the Assemblies pane. In some scenarios (e.g. working with Win32 metadata), however, this is an annoyance. The assemblies automatically loaded into ILSpy have their types exposed to search, quietly affecting search results and causing confusion.
Describe the solution you'd like
It would be great if ILSpy included an override for this behavior--that is, have a way to disable the automatic loading of assemblies in all scenarios.
Additional context
Examples of customer confusion
microsoft/win32metadata#1442 (comment)
microsoft/win32metadata#271 (comment)
The text was updated successfully, but these errors were encountered: