I have a program written in VB.Net (Visual Studio 2008) that uses a DLL written in Visual C++ by another developer. I'd like to be able to step in to the C++ code as my code makes calls to methods in the DLL. Since the DLL is it's own solution, I don't think it can be included in my solution/project. I tried putting the DLLs pdb file in the debug/bin directory with the rest of my build and pdb files. However, when I get to the point in stepping through my code, and it gets to the dll call, it just steps right over the dll code. Do I have to manually load symbols? Not sure what I'm doing wrong. Thanks.
There are 3 things you need to do here in order to debug this DLL. The first, as you mentioned, is to make sure the symbols for the native DLL is loaded,
The next is to enable unmanaged debugging since the DLL is native code. To do this
Right Click on the Project
Go to the Debug tab
Check the "Enable Unmanaged Debugging" check box
The last thing is to disable "Just My Code" for the project. I don't recall if this is strictly necessary when the second DLL is native. But in general it's good practice if you're debugging code which is not a part of your solution
Tools -> Options
Go to Debugging -> General
Uncheck "Enable Just my code"
Related
I am using writing in Visual Basic using Visual Studio 2013 and trying to use the debuger for code in a DLL that is outside of the working directory. The dll is a c++ project and the main app is a VB project.
How do I do that? In c++ it seems to be straight forward but not with VB.
Below is purely for background. I am interested in the question above in general and this is just the latest manifestation.
The full story: I am trying to debug the VB program and a DLL written in C++. I copied the the DLL into the working directory of the VB exe directory. But it gives me a tool tip at the break point in the DLL source code that reads "breakpoint will not currently be hit. No symbols loaded for this document." I am trying to figure out if that fixes the problem. If it does, it does. If it doesn't, it doesn't.
Pehaps you should p-invoke (enter link description here) to make a call and import that .dll. The other option would be to register dll in gac and make wrapper com for your library.
You should also add the library to your .NET application as follows:
xcopy "$(SolutionDir)DLL\$(ConfigurationName)"\*.dll "$(TargetDir)"*.* /Y
Project-->Properties-->Compile-->Build Events-->Post-build event command line pass the command.
I already did the process - Importing dll file in Dotpeek and Exporting Assembly to Project, Now I can modify dll file in VS 2015, but how to recompile the project and use recompiled dll file again in existing project.. I tried with building project in vs 2015 but it displays lots of compile time errors, Please help
Thanks :)
Rather unfortunately, there is no decompiler that will produce code that compiles for an assembly containing more than a couple of classes.
So you might want to try JustDecompile + Reflexil to do your edit. The advantage of this approach is that only the part you edit will get changed and the rest of the assembly will remain the same as original.
You can use dotPeek of Jetbrains, can open any DLL with it by just right-clicking the DLL and Open with dotPeek.
Once DLL is de-compile in dotPeek, right-click click on the DLL in the left sectoin and chose the option Export to Project.
It will open the entire DLL as a Class Library Project in Visual Studio in the case of .NET DLL.
You can modify the source code and recompile the DLLs.
I am not very sure about your requirement, I would advise you to Extend the DLLs method/operation into your project rather than doing an edit on the recompile on the DLL.
I have a project that I am developing that uses a third party COM library as a reference and I would like to build this project on a Visual Studio Team Services build client. My first idea is to create a MSBuild task that checks to see if the COM library is installed on the local computer and if it is not, go ahead and install it, but this seems like a really messy way to do this. I have searched around but it seems as though all the answers date back years and I can't seem to make the few I have found work in a VS 2013 project. How have other people solved this problem? Is there a cleaner way?
For reference I have also tried this solution, which looks really clean, to no avail.
I would go one of these routes:
Generate interop dll with tlbimp, add it to your project and reference it directly:
In VS command prompt, execute tlbimp.exe <your_dll> to generate the interop dll. You can specify the name with /out option.
put this dll somewhere with your code
reference it by going to Add reference > Browse and click Browse... to add the dll
Generate the tlb from COM dll , add it to the project and reference the tlb:
Generate the tlb (e.g. using OLE/COM Object viewer) or extract it from the dll resources,
put this tlb somewhere with your code
reference it by going to Add reference > COM and click Browse... to add the tlb reference to project
As #HansPassant noted in comments, this solution still relies on registry, but you can register it with regtlb, regtlib or similar tool, as a prebuild step, which should be easier than installing the server (though if it is just a dll, you could use regsvr32 to register it instead of full install). However, this is still more complex than the approach with interop dll
I have a DLL written in C# and set for COM visibility. I have it setup as a side-by-side assembly and can successfully deploy the application to client PCs registration free. My question is related to the development PC. Is it possible to compile against the DLL in a similar registration-free manner or is registration required on the development machine? I have tried adding the DLL directly though the Project -> References menu and get an error stating "Can't add a reference to the specific file." The DLL is sitting in the same directory as the .vbp file and I have tried adding the DLL both with and without the client app manifest being present.
I have tried adding the DLL directly though the Project -> References menu
That adds a reference to a type library. A type library is a language-independent description of the types in a COM component, VB6 uses it to know how generate efficient code and to provide type checking and auto-completion. A type library is the exact equivalent of metadata in a .NET assembly.
Traditionally, and the way VB6 did it, the type library was embedded as a resource in a DLL. So you are probably used to picking a DLL in the dialog. That however doesn't work so well when the DLL is generated by C#, the type library can only be generated after the C# code is compiled. You have to pick the .tlb file in the VB6 dialog. The traditional way starts with the COM component being described in the IDL language, the type library can be generated before the code is compiled so can easily be embedded in the final DLL. It is technically possible to do it in C# as well, but the build steps are very laborious and painful, you essentially have to build the DLL twice with different build commands.
The type library for a C# library is normally generated in one of three ways:
Using Project + Properties, Build tab, "Register for COM interop" option. This requires VS to run elevated so it can write to the registry. You start VS elevated by right-clicking its shortcut and picking "Run as Administrator"
By running Regasm.exe, using the /tlb:filename option. An alternative for the 1st bullet and necessary if you don't want to run VS elevated for some reason. Using the /codebase option on your dev machine is also wise to make it work exactly like the 1st bullet and not require putting the DLL into the GAC with gacutil.exe
By running the Tlbexp.exe utility, the type library exporter for .NET assemblies. No registration is done, it only generates the .tlb file.
The first bullet is the normal choice and very desirable because you can never forget to update the type library this way. It is perfectly fine on a dev machine since you only really care about reg-free deployment on the user's machine. You probably got into trouble by not doing this anymore.
Using the 3rd choice is okay and more compatible with your goals, run Tlbexp from the Visual Studio Command Prompt. Just keep in mind that you have to do it again when you make changes to your C# code. Forgetting this once and losing clumps of head-hair trying to figure out why your C# changes don't seem to be effective or getting hard-to-diagnose error codes gives you lots of reasons to consider the 1st bullet again :) You can emulate the reg-free scenario by running Regasm.exe with the /uninstall option.
This is driving me crazy. I have developed a .NET COM DLL that is used by a VB6 DLL wrapper in order to update and replace some legacy functions in an application.
I am now trying to remove the requirement to use regasm on client machines so have worked out how to do that on a test DLL which all works fine.
I branched the DLL just in case and added an app.manifest file. Everything else worked out fine and I got it all working. The manifest is embedded and Visual Studio 2012 generates a mydll.dll.manifest file in the release folder.
Then I went back to the original trunk and added an app.manifest file (no point in merging as there were no code changes). I copied the contents of the branch into the app.manifest file and built the release version. The manifest is embedded in the DLL but no mydll.dll.manifest file is generated.
I know that it's not strictly necessary to have the mydll.dll.manifest file but I'd like things to be consistent (and for some reason the test process doesn't produce the same results with the trunk version) so how can I force it to be created?
This is a VB.NET DLL project so it doesn't have (or I can't find) the 'Generate Manifest' property drop down mentioned in the first answer here. How can I set this? Or is there a way to set it by editing the project file directly?
References:
Original walkthrough article and some corrections.
Overview by Junfeng Zhang in two articles plus a useful tool
You are making a fairly common mistake. A reg-free COM manifest helps an application find a COM server without looking in the registry to locate the DLL. Embedding the manifest in the DLL is like trying to solve the chicken and egg problem, Windows cannot possibly find that manifest if it cannot locate the DLL first.
The manifest needs to be part of the client app. Which is tricky since it is VB6, it doesn't support embedding manifests in its executables.
You could tinker with the mt.exe tool, an SDK utility that supports embedding manifests in an executable. You'd have to run it by hand after building the VB6 binaries. That's unfun and very likely to cause trouble when you forget. It is in general not a joyful tool to use, documentation is meager, incomplete and unhelpful, a chronic problem with manifests.
The fall back is a separate app.exe.manifest file, what Windows will look for next when it cannot find a manifest embedded in the executable. Where "app.exe" must be renamed to the name of the VB6 program. The EXE, not the DLL. This now also gives you a chance to avoid having to register the VB6 DLL, presumably what you really want if you truly want to make your program run reg-free. The disadvantage is that it will not work when you debug your VB6 program, wrong EXE. You'd also need a vb6.exe.manifest, located in the VB6 install directory.
Needless to say perhaps, very hard to get ahead with VB6 here. It just wasn't made to help you do this, they didn't have a time machine in 1998.
I have to admit that I don't know VB at all, but in the case of C++ and C# Visual Studio projects I previously had to resort to calling mt.exe in a post-build step in order to get the DLL manifest I wanted. Maybe that workaround would work in your case as well?