We are using a C++ visualizer which visualized the class content to DataTip using IDkmCustomVisualizer. Something what natvis already has but more advanced. The extension is written in C# and worked beautifully in VS 2017. Since we switched to VS 2019 it stopped working due to new mechanism introduced in VS 2019 (external process).
https://learn.microsoft.com/en-us/visualstudio/debugger/visual-cpp-custom-visualizer-compatibility?view=vs-2019
Of course if I disable the "Load debug symbols in external process (native only)" option in VS my extension starts to work. However our project is huge and we like the new external process mechanism.
I also tried to add WorkerProcessSupported="true" to my vsdconfigxml. Based on:
https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Worker-Process-Remoting
However my visualizer is not called. I was not even able to get work the provided C++ extension example:
https://github.com/Microsoft/ConcordExtensibilitySamples/wiki/Cpp-Custom-Visualizer-Sample
The Worker-Process-Remoting code mentioned to split my class. Unfortunately without any example/tutorial I'm not able to do it.
Any advice how to solve this?
Many thanks for any help :-)
Related
For a game engine called duality (https://duality.adamslair.net/) I want to make a solution template that will create the necessary projects and all the files needed for duality to function. This includes files and folders that are not part of a project themselves.
In order to achieve this iam trying to make a wizard that can generate the files/folder structure I need as I understood that templates alone are quite limited in this aspect. I followed this tutorial: https://msdn.microsoft.com/en-us/library/ms185301.aspx.
However when I debug this and try to create the solution it says it failed but not why or how. Breakpoints are not being hit either since the symbols are not loaded.
This is the error I get when trying to create a project using my template:
When I comment out the WizardExtension node in the vstemplate it works fine
So how do I change my project so that it does load the symbols and I can debug it? Iam using vs2017.
Included is my project:
DualityTemplate
Turns out it was because the platform was set to Any Cpu. When I changed this to x86 it worked without problems.
This is most likely cause by the extension deciding to run in 64 bit while visual studio is only 32 bit.
I'd like to do some "structural meta-programming" in C# (like in other languages as Smalltalk).
For doing so I'd like to script, using a REPL-like tool that should run "inside" VisualStudio. Doing so it would be possible to try ideas, execute refactorings programmatically, etc. from the VisualStudio itself and making use of the full meta-model capabilities it and ReSharper has.
I found that the tool "C# Interactive" allows to script in C# as a common REPL, but runs as a "separated process", not inside VisualStudio.
Is there an tool like "C# Interactive" that runs as VisualStudio/ReSharper plug-in? Any hint, idea, etc. will be welcome :-)
You can load Roslyn into your interactive session, then use its APIs to manipulate your code.
Create an MSBuildWorkspace, load your solution, then explore the Roslyn APIs to your heart's content.
No Visual Studio needed.
You may find my Visual Commander extension useful. The command code provides full access to the VS automation model and executes inside Visual Studio.
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.
It would be nice if it did both a list of methods to choose from and the list of potential input parameters. This was done for powershell and I was curious if there was any similar functionality implemented for emacs or vim?
Clarification:
A fellow developer I work with wants to use either vim or emacs for the low overhead without running visual studio. In essence he would like to be able to write tests, edit code in emacs or vim then just run NANT scripts to compile the code and run the tests. The only feature from Visual Studio he wants is code completion. The rest he can live without for 98-99 percent of the time.
You can use a vim editor emulator for Visual Studio.
http://www.viemu.com/
I haven't come across an emacs mode that would offer code completion suggestions based on "knowledge" of the API(s) that the user's environment is offering. To a lot of people this is an issue which prevents them from attempting to use Emacs or VIM when working with rich/large/unwieldy (delete as applicable) APIs.
However I am wondering how much of a problem this would present during day-to-day work. I've been using Emacs with C#-mode to crank out quite a lot of C# code. I also tend to run dabbrev-mode or pabbrev-mode, which tends to take care of the more common function and variable names I tend to use. To my eternal shame I have to admit that I tend to have a browser open on the MSDN website to look up the rest - those APIs that I don't use often enough to remember. Another potential helper that your colleague might want to look into is icicles, which may also be a step in the right direction. Neither of these libraries however will offer the full breadth of completion support that something the like Visual Studio IDE will offer. I'd see this as part of the trade-off when using a more efficient editor.
As an aside, if your colleague is working in a team and other members working on the same project are using Visual Studio, MSBuild might offer a better solution for building outside of VS than Nant as MSBuild reads the same solution and project files that VS uses (in fact a lot of the build work in VS2008 is handled by MSBuild). The syntax isn't too far away from Nant and with the community tasks added (which gives you NUnit integration etc) and it'll ensure that everybody is using very similar mechanisms to build the executables.
The furthest along completion I've seen for C# is at this blog, specifically at this post. (Blog link included for context and other Emacs posts.)
If you can live with dumb completion, you might be able to roll your own with tags and tag completion.
A previous stack on the same issue.
Your source code should be processed through the CEDET framework: http://cedet.sourceforge.net/
Then either use the example UIs bundled with cedet or else try any of these two:
- company-mode: http://nschum.de/src/emacs/company-mode
- completion-ui: http://www.dr-qubit.org/emacs.php
both supporting CEDET as a completion search backend.
apa!
for emacs and C# you can look at this tool : http://code.google.com/p/idebridge/
OmniSharp provides contextual intellisense for C# in vim.
Some of the suggestions in Eclipse Style Function Completions in Emacs for C, C++ and JAVA? may be relevant for emacs.
Not c# specific, but still.
I have found the http://code.google.com/p/csense this is an emacs c# intellisense/code sense. I found it from this blog post http://osdir.com/ml/emacs.sources/2007-11/msg00018.html, this may be close to the answer I was looking for.
After looking further it has not been updated since November 2007, looks stale to me.
For Vim, you can install insenvim. It support for the C# code completion.
After download the plugin you could install the installation file or install manually by following steps:
Copy the file cs_vis.vim into your $VIM\vimfiles\ftplugin directory.
Copy the file csft.dll into your $VIM_INTELLISENSE directory.
Copy CSVimHelper.dll,reg.bat to your $VIM_INTELLISENSE directory.
Run reg.bat to register the dlls. You need to set the directory gacutil.exe
in the path. You need the latest version of .NET SDK.
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.