COM object (.tlb) is in proc or out of proc - com

We have a C# project that generates .tlb file which is used in C++ code. C++ code accesses the methods of the C# code through this tlb file.
Could anyone please tell if .tlb is in-proc or out-of-proc COM object.
What I have read so far is - dll files are result of in-proc COM and exe files are result of out-of-proc COM.
Please clarify.
Thanks

Related

How to low-level debug a COM DLL (Firefox plugin) method via C++ code without debug info?

Given the following:
the 32-bit DLL code file of some old Firefox plugin (i.e. a DLL containing among other a Typelib, XSD and XSL entries), without source code or debug info, originally coded in C++ and compiled with Visual Studio,
the name and parameters of an exported function/method in this DLL (a function of the Firefox plugin, accessable in JS code),
Visual Studio Community 2013 running on Windows 7,
experience in C++ development, but not with COM or Firefox,
experience with debugging Intel assembler code,
a code license which does not prohibit disassembling the DLL,
I would like to do this: Load the DLL into some C++ code, and step on CPU level into the code of the function to find out what it exactly does.
Can you give me any hint on where to start and how get this done? I guess the DLL may need some Firefox-specific initialization before I can call the function which I would like to debug. Could this be done with the Firefox SDK, without source code and debug info for the DLL? Or may I succeed in "nakedly" loading the DLL, finding the entry point of the - rather simple - function (how?) and calling it?
Thanks for any hints.
If no pdb file or source code, it is hard for you to debug the dll file, since the debugger loads debugging information from the PDB file and uses it to locate symbols or relate current execution state of a program source code. Visual Studio uses PDB files as its primary file format for debugging information during debugging. If no those files, you couldn't debug that library.
Update:
We are dynamically loading a dll to one project using LoadLibrary() function, but if you want to step into your dll file, it really require the pdb file. A simple sample is that you could create and place one pdb file in the same folder as one simple custom dll library project located. I think Visual Studio will automatically search the directory and load them, you could find the information in your Debug modules windows.
The following case is not the same issue as yours, but it also shared us that it would load the pdb file if the dll file was really called by one project/process:
Does winbase::LoadLibrary() load .pdbs?

How to pass configuration to AppDomain from Visual FoxPro application

I made COM visible .NET DLL in C# which refers an external DLL and the external DLL reads app.config from current AppDomain. However my DLL is called from Visual FoxPro 9 so it misses content of app.config from my project.
Does Foxpro have something like app.config in .NET? I just need pass configuration to the external library via AppDomain from FoxPro.
VFP doesn't have separate AppDomains like .Net. However, if you put your DLL in the same folder where your VFP executable is, then your AppDomain.CurrentDomain.BaseDirectory is the folder where VFP executable is (IOW it is the same as VFP's justpath(Application.ServerName)). ie:
string path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "app.config");
Also App.config is just a plain xml file. You can read and process its contents as you wish from within VFP.
VPF creates .exe file. Just create .exe.config file with the same content as dll.config.

COM access to VB.Net dll without strong name signing

I'm converting a VB6 dll to VB.Net using Visual Studio 2008 Express. I want to use the same .dll to integrate with Excel via Excel-DNA, but also to be available via COM (I need to be able to call it from VBScript and VBA).
If I leave the assembly unsigned, I have access to all of the ExcelDNA functionality but no COM access.
If I sign the assembly with a strong name, then when I try to build the .dll I get the following error:
Unable to emit assembly: Referenced assembly 'ExcelDna.Integration' does not have a strong name
What are my options?
You don't have to strong-name a [ComVisible] assembly. It is only required when you want to install it in the GAC. Not strictly necessary although not a bad idea to fight DLL Hell. You need to register it with Regasm.exe using the /codebase option. Visual Studio already does that automatically, although the option might be missing in the Express edition.
Fixing the second problem shouldn't be hard either. Just rebuild the Excel-DNA solution from the source code you can download from Codeplex.
Excel-DNA has an option to expose your .NET classes to COM directly, so you can use them directly from VBA as regular COM classes.
To do this your class must be ComVisible (or the whole assembly must be ComVisible), and you must mark the ExternalLibrary as ComServer='true' in the .dna file, something like:
<DnaLibrary RuntimeVersion='v4.0' />
<ExternalLibrary Path='MyAddIn.dll' ComServer='true' />
</DnaLibrary>
Then you have some options for registration:
either call "Regsvr32.exe MyAddInDna.xll"
or in the AutoOpen of your add-in, call ExcelDna.Integration.ComServer.RegisterServer()
Both of these set the registry entries so that the .xll file becomes the COM server for your classes. You can then access them late-bound from VBA, with CreateObject("MyNameSpace.MyClass").
You need another step to set up a type library (to give you intellisense in VBA). For this you generate the type library with tlbexp.exe. The regsvr32 / ComServer.RegisterServer call will find the type library and register it too.
You can also pack the .dll into your .xll file (adding a pack='true' attribute to the ExternalLibrary tag) and the type library will also be packed if present, and registered from the resource in the .xll file when you call Regsvr32.exe
So the end result could be a single file .xll add-in that is both an Excel Add-In with UDFs, ribbons, RTD servers and also a COM server that you can access from VBA.
More info in the discussions here: http://exceldna.codeplex.com/discussions/252721 and here: http://groups.google.com/group/exceldna/browse_frm/thread/4c5a71efbe96d885.

Using tlbexp.exe on a COM dll

I am trying to set up communication between Centura and a COM .dll. (Downloaded from http://download.resip.fr for a database import)
Centura requires a .tlb file to be able to communicate to this component. Normally I would use regasm /tlb to generate the .tlb but seeing as it is a COM .dll this is not possible.
I found that I could use tlbexp for .NET dll's: http://msdn.microsoft.com/en-us/library/hfzzah2c(v=vs.80).aspx
I tried this out, knowing it would probably fail (as I have COM .dll). I received this error:
TlbExp : error TX0000 : Could not load file or assembly 'file:///C:\Windows\system32\ResipBcb.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
Using Dependency Walker I noticed two .dll's missing. I found ieshims.dll online but I can't find the wer.dll. See this question.
I don't know if the tlbexp failure has anything to do with this file that is missing?
To sum up, my question is:
How do I get a .tlb from this .dll? I can't seem to find any way to extract the .tlb out of this COM .dll.
Best regards
Clint Cambier
What you are trying to do only works for .NET assemblies, not native COM servers. The type library for them is almost always embedded inside the DLL. In Visual Studio, use File + Open + File and select the DLL. Open the "TYPELIB" node, right-click the resource (usually 1), Export. Save it to, say, a project directory, use the .tlb filename extension.
TblExp and regasm are only valid on .NET assemblies, what you have is most likely a standard non .NET COM DLL. So neither of those two commands are valid on this DLL.
Standard COM objects are registered using regsvr32. Try running that against your DLL and see if it registers correctly. If it does you should see it listed in Centura's ActiveX explorer.

How to call functions of a COM DLL (In VC++) from a VC++ .EXE application?

I have a COM DLL (say, xyz.dll) coded in VC++. I want to create a calling EXE application (calling.exe) which will call the functions of the COM DLL (xyz.dll).
I followed the steps in the link http://www.codeproject.com/kb/DLL/XDllPt1.aspx.
But I am not able to connect the DLL and EXE and hence not able to call the functions of the COM DLL. I am totally new to COM and VC++ programming. Can anyone kindly help me with.
I am using Visual Studio 2005.
These are the exact steps I followed--------
STEP 1: Created a solution having the DLL project (xyz.dll) project and a caller application Project (calling.exe) of template MFC Application (Dialog based). Made this calling.exe as the startup project..
STEP 2: Went to the properties by right clicking on the calling.exe Project in solution explorer. Configuration properties --> C/C++ --> General--> Additional Include Directives and added the path to the DLL Project..
Step 3: Again Right Click on the calling.exe application Project went to Properties--> Configuration properties --> Linker --> Input --> Additional Dependencies and added the path to the .Lib file for the built DLL Project.
STEP 4: Right click on calling.exe application Project, Properties --> Common Properties --> References --> Added reference to the DLL.
STEP 5: Copied the xyz.dll file to the application project directory.
STEP 6: My DLL has many header files and its corresponding source files. So, Added all the header files present in the DLL Project to my calling.exe application program. Within the OnInitDialog() function present in one of the .CPP program of the calling.exe application, I called the functions of DLL.
Just the statements
Cx objname;
objname.func();
Here Cx is the name of the class in the DLL.
I did not do any changes with the configuration settings of the EXISTING DLL project because it is The DLL which is already prepared by an expert and I am writing just the calling applaction to call the functions present in this DLL.
THANKS IN ADVANCE.
The instructions you've followed are for calling functions in an ordinary DLL, not a COM DLL. To access a COM DLL you need to go through COM.
You don't link to the DLL's lib file or include any headers, and you don't need to move the DLL.
First, make sure the DLL is registered by running regsvr32 on it.
regsvr32 "c:\..\..\xyz.dll" ; insert the correct path
Then add an #import directive to your project's stdafx.h, containing the path to the DLL.
#import "c:\..\..\xyz.dll" // insert the correct path
Right click stdafx.cpp in the file view and choose compile.
This will generate the wrapper "smart pointer" classes you need to access your DLL.
The smart pointer classes have the same names as the interfaces in your DLL, but with "Ptr" on the end.
Look at the file with a .tlh extension and the same name as your DLL in your Debug directory. It begins with a C++ namespace declaration.
This is the namespace in which the objects you are going to create from the DLL reside.
Say the namespace is XYZ and you want to instantiate a Cx object, which exposes the Ix interface.
You would do:
try {
XYZ::IxPtr obj;
obj.CreateInstance(__uuidof(XYZ::Cx));
obj->func();
} catch (_com_error e) {
printf("Error: %S\n", e.Description());
printf("Error: %S\n", e.ErrorMessage());
}
You can then continue to use it just like an ordinary pointer.
You don't delete it when you have finished with it though, it will be destroyed automatically when it goes out of scope.