Does anyone know of a Visual Studio extension that will decompile assemblies and allows you to view code in Visual Studio for a given class instead of having to leave VS and use ILSpy or other "external" reflection tools? I Know Resharper also has a reflection tool but it would be nice if you could kick it off within VS.
Newer versions of Visual Studio 2017 now include an experimental feature called navigation to decompiled sources. It requires you to explicitly enable it (and restart Visual Studio), but once you do, you can see decompiled source code for assemblies your code references.
For instance, if you put your caret (text cursor) over the name of a method in a method call and press F12 (by default) it will open a new tab right in the IDE that shows the decompiled source code for that method. Microsoft says this uses ILSpy behind the scenes, but this is a lot more convenient and doesn't require you installing anything new.
I Know Resharper also has a reflection tool but it would be nice if you could kick it off within VS.
You can. With the cursor on an identifier, choose ReSharper | Navigate | Navigate To... (the keyboard shortcut in the VS scheme is Alt+`), and choose Decompiled Sources.
This uses the same decompilation engine as dotPeek, the standalone tool.
Note that within such a decompiled source, you must continue to use this same navigation method to follow definitions, as F12 or Ctrl+click will go back to the Object Browser.
Assuming the default short-cut keys where pressing F12 while a class/method is in-focus, you can set ReSharper to automatically decompile the reference. This ends up working great and it's as if the external assembly reference was like any other class in your source solution.
Example of source you are directed to when pressing F12 while focused on new HttpClient()
I suggest you to use .NET Reflector which has a built-in VS integration for assemblies decompilation and is far, far better than Resharper. Have a look at this page for further knowledge.
http://ilspy.net/ is free and Open Source. And has a plugin for Visual Studio.
Related
Edit: Vidual Studio Code and Visual Studio are 2 different things. Yes it's confusing but I know that VS has this feature, I'm asking about VS code.
Is there some extension/setting that makes Visual Studio Code's c# have Intellisense for all available namespaces, including those that were not yet imported, and then imports them when selected?
Example: Collections are not yet imported and I want to type IEnumerable and import it. Being the average programmer this is quite tedious and I might screw up the spelling or capitalization, and then have to press ctrl+.. I would like to just be able to type "ienu" and then IEnumerable would pop up and would be autocompleted and auto imported.
This feature exists for Typescript in VScode (thanks to an extension), and even for C# but in Visual Studio with the Resharper extension.
I have searched everywhere for this feature but it seems to me like it doesn't exist. It honestly feels insane to code without this.
If you use "C# extension" for VSCode (this https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp)
you can try follow next steps:
Right click on C# extension
"Extension settings"
In opened "Settings" tab, add import in search area
Enable Checkbox
(Screenshot of this step)
Enjoy autoimport without "special" extension (Screenshot)
I just went ahead and made the extension:
https://marketplace.visualstudio.com/items?itemName=Fudge.auto-using#overview
Currently it supports only the base C# libraries but I can make it use additional nugget libraries as well if there is demand for that.
As of 24/11/2020 the official C# extension supports this feature, see other answer.
There are some sort of solution for your problem that might help if you write the complete key word and don't want to write the using system or any library you can just put cursor on your key word and press alt+enter it will automatically add the library .but if you are not using library and want to auto complete key word of that library it's possible with re-sharper. you can also use Ctrl+space if your visual studio is not giving you auto recommendation
what do I have to do to jump to the right class not the metadata?
in visual studio 2010 while working on c# code I right click on some code to jump to "Go To Definition"
sometimes shows the right class where my object is define and sometimes show me the Metadata not the right class...
why is this ?
thanks for your help
It only shows you the source code of a class if that class is available in your solution. If you're referencing a project whose source you have, you can add it to the solution as a project reference, and "Go To Definition" should behave as you'd expect. If you're referencing a compiled DLL, "Go To Definition" will only display metadata.
if you added references to other project than F12 will go to the actual source code but for the DLL it will go to the meta data if defind
Visual Studio will go to the metadata when the reference is a DLL or an EXE - it doesn't "know" about the source code.
It will go to the source code when you have references a project.
As others have said, Visual Studio cannot show you the actual source code for an assembly that you only have in compiled form (i.e. .exe or .dll). If you really need to see how something was implemented, then you can use Reflector to decompile it for you, though the resulting code will probably be less intelligible than the original (no comments, variable names will be lost, etc.).
I have a .exe app which I want to understand better - I can see it in reflector
Is there any way to get reflector to create a VS project with the code so I can view it properly in Visual Studio?
Nothing special is needed, it is built into Reflector, albeit not very discoverable. Right-click the assembly in the left pane and choose Export. You'll get a chance to change the output directory. Click OK and Reflector starts decompiling the code, creating a source file for each individual class. And creates a .csproj file which you can open in Visual Studio.
Check out Jason Bock's FileGenerator, it might be what you are looking for.
I've used Denis Bauer's Reflector.FileDisassembler http://www.denisbauer.com/NETTools/FileDisassembler.aspx. It works well enough to compile and step through the code.
Yea there is, but it doesn't come cheap
http://www.remotesoft.com/salamander/
I have used it to decompile assembly, but I've never used the feature to decompile it into a project so can't give you a review on that. The quality of the decompiler will match the one in reflector.
They also be some legal issues associated with decompiling exe into project - and source for recompilation, so use it with care.
I'm building (read: trying to build) a Visual Studio integration package, which contains some custom highlighting and intellisense. The language part is working fine, the package is being loaded in the IDE, installing on non-SDK machines without problems.
However, here's one annoying thing I can't get to work. I want to see my package details in the about box (which shows all the installed packages like Resharper), ditto for the splash screen.
According to the documentation, the method to do this is to implement the 'IVsInstalledProduct' interface. I did this, following the instructions on MSDN, but it simply doesn't work! When I put breakpoints on the methods it seems like they're never called. Hopefully there's anyone here who can enlighten me on why this doesn't work like it is supposed to.
Note:
I also ran devenv.exe /ranu /rootsuffix Exp /setup from the VS2008 command prompt, as recommended in other articles about this.
Did you register your extension under the HKLM\Software\Microsoft\VisualStudio\versionNumber\InstalledProducts registry key?
If it's a managed package, don't forget to apply the [InstalledProductRegistration] attribute to it, which will handle the creation of that registry key.
I am using a third-party DLL. For some particular cases, a function in the DLL is throwing an exception. Is it possible to debug the DLL in the Visual Studio?
After the answer from Andrew Rollings, I am able to view the code, but is there any easy way to debug through the code in Visual Studio?
If the DLL is in a .NET language, you can decompile it using a tool like .NET Reflector and then debug against the source code.
Or you could ask the vendor if source code is available. That's probably the easiest way.
Building on Andrew's answer, you just treat the decompiled source code as a new library within your project and set breakpoints in the source. Remove all references to the 3rd party DLL so that it is the decompiled code that is executing.
Other things:
You may be breaking the law by decompiling the code, or breaching a licensing agreement with the 3rd party vendor. Make sure to review this with someone.
You will want to make sure that you remove references to your decompiled version if you are shipping to other developers, or checking into a larger source tree. Easy to forget this!
There are two methods I've come across:
1) Accessing the DLL project from the using project.
This involves building the DLL in a separate instance of Visual Studio and then accessing the DLL through a different project in Visual Studio (this assumes you have the source code).
There a number of ways to accomplish this:
You can add Trace.WriteLine
statements in the DLL that will show
up in the 'Output' window in Visual Studio.
You can add System.Diagnostics.Debugger.Break() statements to the DLL code. When
running the calling project in Visual Studio,
program execution will stop there.
From here you can add access the
call stack (including all function
calls in DLL itself) and set break
points (although the icon for
the breakpoint will appear disabled
and the hover text for the break
point will read "The breakpoint will
not currently be hit. No symbols
have been loaded for this document").
If the DLL is throwing an exception (which you can see from
the 'Output' window if the exception
is caught and handled by the DLL)
you can tell Visual Studio to always break when
that type of exception is thrown.
Hit Ctrl + Alt + E, find the type of
exception being thrown, and click
the 'Throw' column for that
exception. From here it is exactly
as if you had used
System.Diagnostics.Debugger.Break()
(see above).
2) Attaching a using process to the DLL project.
This involved hooking the Visual Studio debugger into a running process.
Open the DLL project in Visual Studio.
Run an application that uses the DLL (this
application can't be run from
another instance of Visual Studio since the
process will already have a debugger
attached to it).
From here you can add break points and step through
the DLL code loaded in Visual Studio (although
the break point will appear disabled
the same as in method 1).
Something that has worked for me with debugging a couple of third-party libraries as well as .NET itself is WinDbg. It is an awesome debugger from Microsoft that I have used to troubleshoot some sticky problems that were occuring deep inside the framework.
You need to use the Son of Strike (SOS) extensions if it is a managed DLL. It can debug native also. You will need to know a bit about callstacks and assembly/CIL instructions to be good at using it. You should be able to determine the exception and what is causing it. We have used WinDbg/SOS to find for instance that in HttpWebResponse, if you are using Gzip compression to download a page and the server returns a bad Gzip header, .NET runs the decompression in the threadpool and a crash will take out your process. Happy debugging.
One more option we should mention here is dotPeek 1.2 (a free decompiler from creators of ReSharper). Here is a nice post describing how to configure VS symbol server and dotPeek 1.2 to debug decompiled code from VisualStudio: http://blog.jetbrains.com/dotnet/2014/04/09/introducing-dotpeek-1-2-early-access-program
As Cesar Reyes mentioned in Stack Overflow question Visual Studio - Attach source code to reference, ReSharper 5 (and later) has this capability.
.NET Reflector 6 comes with a Visual Studio Addin that lets you use Visual Studio's step-through-debugging on assemblies that you don't have the source code for.
Have a look at this blog post:
http://www.simple-talk.com/community/blogs/alex/archive/2009/09/22/74919.aspx for more details.
This is still a very early build. So no guarantee that it'll work, and it might break your visual studio configuration or project configuration. Make sure you have backups (or source control) for any projects you use this on.
Download here:
http://www.red-gate.com/MessageBoard/viewforum.php?f=109
I thought .NET Reflector got some debugging plugins. That'd be a so much better idea because decompiling and recompiling code generally fails, and you need to do so many changes in the code to fix it.
Give .NET Reflector debugger a try. It might help you a lot.