goalasebo.blogg.se - How to debug in visual studio 2012 with dll reference

#HOW TO DEBUG IN VISUAL STUDIO 2012 WITH DLL REFERENCE .DLL#
#HOW TO DEBUG IN VISUAL STUDIO 2012 WITH DLL REFERENCE CODE#

So, there is a BitmapSelector that, if you load the version of the assembly that belongs to Visual Studio 2010 (v4.0_10.0.0.0_b03f5f7f11d50a3a sub-folder), didn't exist. NET Reflector (v4.0_11.0.0.0_b03f5f7f11d50a3a sub-folder), if you search for “DocumentOutline“, you get the type that contains the feature, which has an AddComponent method with the hint to solve the problem: Once you have loaded the version of the assembly that belongs to Visual Studio 2012 in. NET Reflector can't do for you: to guess which Visual Studio assembly contains some feature.

#HOW TO DEBUG IN VISUAL STUDIO 2012 WITH DLL REFERENCE .DLL#

This happens to be .dll (in the folder C:\Windows\Microsoft.NET\assembly\GAC_MSIL\). In Visual Studio 2012 RTM Microsoft fixed that problem using some approach, but which one? To discover which, I decompiled the Visual Studio assembly that contains the Document Outline feature. But that of course broke the Document Outline feature of Visual Studio 2010, showing the bitmaps of Visual Studio 2012 (gray) rather than the colored ones. I knew that in a previous beta the bitmaps of the 4.0.0.0 were gray. NET Reflector you will see that the bitmaps are the colored ones of previous versions: While adapting my add-in to the Dark / Light themes introduced by Visual Studio 2012 I wondered how the Document Outline got the gray bitmaps of components of 4.0.0.0, for example the MonthCalendar: My MZ-Tools 7.0 add-in for Visual Studio provides a Control Explorer feature that is basically an enhanced version of the Document Outline built-in feature of Visual Studio. Visual Studio assemblies are stored in the GAC 2.0 (C:\Windows\assembly), GAC 4.0 (C:\Windows\Microsoft.NET\assembly) and in the Common7\IDE folder (and the PrivateAssemblies and PublicAssemblies sub-folders).

#HOW TO DEBUG IN VISUAL STUDIO 2012 WITH DLL REFERENCE CODE#

Although Visual Studio was born as a native C++ application, with each release more and more of its code became managed (.NET). The first scenario is to decompile Visual Studio assemblies. NET Framework and you can even debug its assemblies, but it hasn't done the same with Visual Studio assemblies. Microsoft has released the source code of the. I mean: you may have the source code of a Visual Studio assembly with some complex logic, and it is difficult to guess which branches are actually executed for certain cases.

To guess which code path inside a method is actually used at run-time.

To understand how Visual Studio does some kind of things, because you need to do the same or similar ones in your own extension.

In this guest post I will explain why.ĭeveloping a somewhat complex Visual Studio extension, there are two scenarios where you may desire to have the Visual Studio source code and even to debug its assemblies: NET Reflector to understand the internals of Visual Studio assemblies since many years ago, and I consider it an invaluable tool for developers of Visual Studio extensions (add-ins, packages, etc.). NET Reflector to understand and debug Visual Studio assembliesĪs a developer of Visual Studio add-ins, I have been using. We liked it, and asked him to tell us a bit more… Using. NET Reflector to understand and debug Visual Studio assembliesīy Roger Hart and Carlos Quintero, October 30th, 2012Ĭarlos Quintero (MVP, and developer of MZ-Tools) recently wrote a blog post on debugging into Visual Studio's assemblies. NET Reflector To Understand And Debug Visual Studio Assemblies