I have four different solutions: two C/C++ libraries, a C++/CLI wrapper which uses those libraries and a WPF project.
How can I debug my libraries when they are called by my WPF Project?
When you want to debug anything you call that is outside your solution, you need to help Visual Studio find the debugger information. If you just link to a library it can run code but you can't do step by step debugging becuse you're only linking binaries and not source code.
For debugging external libraries, you need two things:
link the library files compiled in debug mode
tell Visual Studio where to find the .pdb files (which contain useful information for debugging).
To make sure the .pdb files are loaded correctly, you can go in your project options then Debugging->Symbols and then select the directory where the .pdb files from your library are. Visual Studio will put the .pdb files in the release directory usually (default settings).
Important note: that since you are using a wrapper over the libraries, you need to make sure that the wrapper itself is also doing this (or you will only be able to debug the wrapper).
Related
So i have one C# desktop application that references a C++ dll. This dll project was developped by other persons, it can't be compiled on visual studio, I use NMake with the parameter -DCMAKE_BUILB=Debug to generate the .dll & .PDB files. I copied the files on the C# project reference folder and enabled Debugging of Unmanaged Code in the project properties. So im actualy able to debug unmanaged code from the dll. My issue is that i can't inspect any of the object nor the variables im lokking in the unmanaged code side. The visual studio contextual inspector doen't show when I passe my mouse on the objects/variables & when trying to add a spy it's not better. I need to see the values of the objects/variables from the unmanaged code to make sure it doen't do anything wrong.
Note : a coworker of mine had already opened a thread here How add spy on Visual studio using unmanaged code
But sadly the thread was closed for lack of details, so I tried to add more details to describe the issue.
Pls don't close this one
Inspect unmanaged C++ objects/variables on Visual studio 2017
Suggestion
Update 1
Please make sure that you have installed the C++ development and C# development workload in VS Installer. That's all the premises.
1) when you reference the path of the dll, make sure that the pdb file already exists under the reference folder(the folder where you referenced the dll) and then use DLLImport node to import the c++ functions.
2) Tools-->Options-->Debugging-->General-->check the option Used Managed Compatibility Mode
3) Right-click on your C# project-->Properties---> Debugging-->check the option Enable native code debugging
Also, check Allow unsafe code option under Build.
4) also, if your c++ dll is built with x64 platform, you should also use x64 platform to debug your c# main project.
In addition, you can refer to this similar issue for more detailed info.
I have a .NET application debug folder but not the complete visual studio solution. I am trying to generate a wix installer from this.
Things tried:
I created a project called setup using WIX toolset.
In my .net solution, there are now two projects, the main project helloWorld and the wix project setup. Inside the setup I added the reference of helloWorld and it worked fine. I am able to create the installer for my helloWorld project.
Here, I added the reference of the application project for which we want to generate the installer.
Problem:
As I have only application's - debug folder(i.e the application's .exe , .exe.config and other files) and not the complete visual solution. I am not able to generate the WIX installer from it.
Question:
Is it possible to generate WIX installer from debug folder without having the complete visual studio solution?
If possible, are there any document or things I can try?
Redistributing Debug Binaries: Debug versions of binaries should not be redistributed for several reasons (technical, security, legal, practical, etc...).
Technically: First of all, they require their own complement of debug runtime DLLs in order to run and these debug files are not present on normal, non-developer computers with standard runtime components installed. Debug dlls often have an extra "d" in their file name: mfcm140d.dll versus mfcm140.dll for example (look for them on a PC with Visual Studio installed).
Legally: Redistributing debug binaries for standard runtime components is actually illegal - it violates EULAs with regards to what is redistributable (normally). And no, this is not a trifle - don't do it.
Security: Debug binaries also contain a lot of debugging symbols and in .NET assemblies a lot of meta information that should generally not be sent to others. You would have to ask someone else for the full technical details.
Practical: Several practical issues too. For one thing: don't underestimate the confusion involved in redistributing debug versions of files. Creating an internal setup with debug binaries to test on computers set up with debug runtimes could work for internal QA though. Just wait for someone to send that to a customer or for someone to upload it for download on your web-site (by mistake).
For debugging purposes some people redistribute *.pdb files - "Program DataBase" - along with their software - instead of debug dlls. More on PDB files.
Hello WiX: With the above stated, adding debug dlls to a setup is no different from adding release files. There is a WiX Visual Studio Hello World example here. It should show you the basics of compiling a working setup with WiX and Visual Studio. There are also a bunch of quick start tips for WiX here (many links to samples).
Some Links:
install VC++ Debug Runtime Distributable (debugging purposes ONLY)
MFC100d.dll Issue in VS2010
I'm making a load of code bits that will eventually be used in another C# program long term, but I may want to use it in various other apps, and I need to use it easily now as it gradually develops. So I've written a few C#.net DLLs in Visual Studio Express 2017. Two of which reference a 3rd-party DLL (one of which was installed by other software, one of which I just pointed at in Visual Studio), and one of my DLLs references my other 2 DLLs. I've ticked the boxes to COM register my ones and I'm now happily using them from Excel/VBA.
But how do I install it on another Win10 machine in simple steps though, so I can use the same spreadsheets and automation on those computers? (preferably with some explanation of what the steps are actually doing?) I haven't had any luck with the other options I've googled, maybe they're not "idiot proof" enough for me, or my DLLs have dependencies on other DLLs, or I'm getting them from the wrong place.
I assume these are 64-bit DLLs (they're complied for 'Any CPU') so I
want to copy them into the 64-bit place (syswow64)? Or should they go
in system32 as well?
I guess I get them from my 'release', not 'debug' folders?
I also have .pdb and .tlb as well as .dll. Do I need these? Maybe they're the missing piece of the jigsaw?
What's the difference between regsvr and regasm and what should I be using? (Or both).
Also is there a simple way to make a DLL copying and COM registering installer app? And if yes, does that still apply if it's VS Express
2017?
Thanks for the help!
I'm beginning the work of moving an internal class library (.net framework, C#) to a series of nuget .net standard packages, which we will also serve internally. I'm in the research phase.
And I am attempting to research using the VS (2017) debugger and working to create our conventions for where debug versions of the packages (with symbols) will be and where the release versions (without symbols) will be.
I build a small dummy .net standard package in one solution, and have used nuget add to place it in a file share. And I have successfully consumed it in a different solution.
However, when I try to step into the code in the consuming solution, somehow, visual studio is doing something smart and actually stepping me into the source at its ORIGINAL location. Which is fine in some ways of thinking about it, but I want to simulate the situation of a different developer on a different machine consuming the package and not having that original source available, such that the only way to step into packaged code would be to consume a debug version with symbols. But visual studio is foiling me by figuring out the original source location and I don't see how it is doing that.
How can I get VS to be "dumber" so I can simulate on my machine what it would be to consume packages on another machine that didn't have this package source?
Thanks in advance.
How can I get VS to be "dumber" so I can simulate on my machine what it would be to consume packages on another machine that didn't have this package source?
You can try to specify the Symbols of that .net standard project to exclude from automatic loading.
Detail:
As we know:
The Program database (.pdb) files, also called symbol files, map
identifiers and statements in your project's source code to
corresponding identifiers and instructions in compiled apps.
Symbol files also show the location of the source files, and
optionally, the server to retrieve them from.
And the default setting of symbols loading for debugging in Visual Studio is that Load all modules:
That is the reason why Visual Studio smart and actually stepping your into the source at its ORIGINAL location.
So, to resolve this issue, we need to disable Visual Studio "Load all modules", we could specify excluded modules for your .net standard project.
To accomplish this, click the link on that window, then add the name of your .net standard:
Then Visual Studio get to be "dumber", not find the ORIGINAL location.
Hope this helps.
I want to add Scintilla to my project, because I want to make my own HTML editor.
Visual Studio doesn't want to add a reference to SciLexer.dll and SciLexer64.dll.
I've dont everything in the installation instructions.
I'm using Windows 7 64 bit and Visual Studio 2012.
It's pretty clear in the documentation. You want to reference only ScintillaNET.dll in your project, and ensure that SciLexer.dll and SciLexer64.dll are somewhere in your path. The ScintillaNET.dll is a wrapper around the two other unmanaged DLL's, and used P/Invoke to call them.
This means that you need to ensure that the unmanaged DLL's are deployed with your application.