I have a .net dll. For some reasons I have registered it for COM. I tried a lot of options to debug the code of this dll but nothing has worked. Someone please suggest a way to debug the code of COM registered .net assembly.
You'll need to debug the client, either by starting it from the debugger or by attaching to the running process. You'll need to have managed debugging enabled. You'll need to have the .pdb file accessible to the debugger (in all cases where I've done this, the .pdb file is in the same folder as the COM component).
Related
In Visual Studio (C#), ticking 'Register for COM interop' updates the Windows environment such that my Visual Studio project, its dependent Visual Studio projects (in same solution) & dependent DLL files are all available for another COM-consuming application on the same machine. This COM-consuming application works with no issue.
If I want the same COM objects to be available to a consuming application on another machine, what must I do?
I assume I still build with the same flag set (so that the DLL files have COM content)? I assume I must register the COM DLL file (e.g. regasm) - Unfortunately this doesn't work - do I register every DLL file that I am constructing & every DLL file library they reference?
Please make no assumptions about my COM knowledge.
You don't quite provide enough information to answer with certainty, but there are enough hints to guess at what you are doing.
When your client app asks for the COM object, the .NET runtime is invoked and it locates the COM-exposing assembly DLL from the information stored by RegAsm (specifically by the /codebase parameter). But after that, it's all .NET assembly loading rules - including the loading of dependencies.
If your COM assembly has dependencies, the dependent assemblies must be locatable from the client process. It doesn't matter whether the dependencies are in the same folder as the COM DLL - the one loading those dependencies is the process, not your COM DLL. The .NET runtime uses a process called Fusion to decide where to look for .NET assemblies.
You have two practical choices:
Put the COM DLL, its dependencies and the client EXE all in the same folder. This works if there is only one client, and you control the client (so, don't do this if the client is IIS, for example). It's the simplest solution.
Give all the .NET components a strong name and deploy them to the GAC1. You still have to run RegAsm; but don't use the /codebase argument.
It is also possible to customize the Fusion rules by giving the client app a manifest with the proper entries, but that's too much of a hassle. The other options are more practical.
If this doesn't describe your problem, then I would use a combination of SysInternals' (now Microsoft's) Process Monitor and the .NET fusion log functionality to look into where the process is seeking the different DLLs.
1Technically you don't have to put the main COM DLL in the GAC, but it makes no sense to use /codebase for the COM DLL when you have to deal with GAC anyway. At that point you might as well put them all in the GAC
I have a COM DLL (MyWrapper), with a COM ATL Object (class) defined inside. This COM dll is basically to be an interface between my WPF .exe and native MFC DLLs.
Everything works perfectly fine until I put the COM DLL in my source control to check in the code. I put the Pre and post build events to copy the DLL to our desired location. when I compiled I got the error.
Unable to register the dll. Try enabling per user redirection
I enabled the option in linker. The DLL compiled and copied to the directory successfully. Then I tried to add the reference to the WPF project, it gave me the following error
A reference to MyWrapper.dll" could not be added. Please make sure that the file is accessible and that it is a valid assembly or COM component
When I remove the pre/post build events and then add the reference, everything works great. I loaded the DLL in Dependency walker it shows IESHIMS.dll is missing.
I have tried to register the DLL using regsvr32 but that returns an error:
The module 'MyWrapper.dll' was loaded but the call to DllRegisterserver failed with error code 0x80070715.
I have admin rights on my machine and am running Visual Studio as administrator.
In the postBuild events, I created a Proxy dll of the COM and added that dll in my WPF application. This solved my problem.
I've written an event handler for sharepoint 2010 site using visual studio 2010 . I had attached a breakpoint to the code and followed the process which i had done in visual studio 2008.
It is to use the Attach to process option and select the w3wp option.
The event gets attached but the breakpoint is not firing.
I ve checked the site collection and checked the MAnage site settings to see if the event handler is enabled. It is enabled. I tried to disable and enable it again. Even now its not firing.
Also i tried to clean the build solution and re built it . The debugger is not firing.
Do post a reply
Thanks in advance
Baradhwaj.PC
Here are a few things to check:
Are you attached to the correct process?
Using appcmd.exe list wp on the server (IIS7+) can be a useful way to determine which process ID belongs to which App pool. If you attach to the wrong process ID, even if it is the right name, the breakpoint won't fire.
Are your PDB's installed with the .dll's?
When I use GAC-based deployments, I often use a PowerShell script to copy my PDB files into the GAC folder where the assembly lives, usually something like C:\WINDOWS\assembly\GAC_MSIL\MYLibrary\1.0.0.0_publickeytoken.
When using bin-based deployments, it is sufficient to ensure the pdb is also in the bin folder.
While debugging, check the "Modules" debug window.
Find your assembly to determine whether debug symbols were loaded. If they are not, read the reason why. Note that you may need to invoke your code at least once for the assembly to get loaded.
Sometimes, it might mention that the pdb version doesn't match the assembly. This might happen if you built and deployed without pushing out a new pdb, even if you made no changes to the code. If this occurs, just redeploy a freshly-built assembly and pdb.
Are the PDB files in the path in which you are debugging? Without the PDB files, I think Visual Studio will be unable to link your code to the breakpoints.
I'm having problems with a dll that I downloaded from somewhere. How can I look inside the dll to debug it?
You don't say, but if it's a .NET assembly dll you could use the disassembly tool in Reflector to view reversed source code.
If it doesn't have debug information then it's no use (usually DLLs are shipped in the "Release" version - which usually means that Debug information is not available). In order to actually debug you must also have the sources.
You can use a program like DLL Export Viewer to view DLL files.
But as lulian pointed out you can not debug it, unless you have sources or pdb file...
If it is a managed dll you can debug it with .NET Reflector Even without the symbols and without the source code. There you can
Decompile third-party assemblies from within VS
Step through decompiled assemblies and use all the debugging techniques
you would use on your own code
I use a 3rd party DLL in my VB.NET project (VS2005) that responds to slow and give wrong values in debug mode. In run-time mode everything works as expected.
I do understand that there are something going on in the debug mode which makes the DLL communication slow. This behavior makes it hard to debug the application correctly.
Is there any way to force VS to communicate with the DLL in "run-time" mode during debugging but let the rest of the project be in control of the debugger?
I found a setting that resolved my issue:
Project Properties > Debug > Enable Debuggers > select "Enable unmanaged code debugging".
Now the DLL communication flowed smoothly. The DLL I use is a middleware between my app and a USB device. There is no Debug/Release version of the DLL.
Change the debug DLL for the release one, either by switching files or by telling the linker/build process to only use the release one, but like the comment above I'd suspect there's some funky stuff going on in both.