Develop Reference

Create an instance of a component with CLSID COM's {...} from IClassFactory failed due to the following error: 800a01ad

I have a classLibrary project written in c#.
I have an old dll (cares managing data in db) that my project reference to.
when I try to create object of class from that dll, I get error:
Create an instance of a component with CLSID COM's {...} from IClassFactory failed due to the following error: 800a01ad.
what I tried:
1. execute regsvr32 command from cmd - got success but it still does not work.
2. using regAsm command to register the dll - got success but it still does not work.
the target framework is framework 2.0.

The factory has problems to create the com object.
In most cases there are missing dll's, which need to be loaded when the object is created.
Is that COM server implemented in C# or is it a native COM server?
If it's dotnet, you can use fuslogvw for finding the missing assembly.
If not, take a dll dependency walker.

test if com dll is registered using its path

hi i got a com/activeX and i want to know if its registered. I know NOTHING about the file except it is a com/dll that needs to be checked.
How to check if a COM component (EXE/DLL file) is registered or not (using .NET)?
How to check COM dll is registered or not with C#?
and so on tell me to search based on guid. but I failed to find explanation of hwo to find GUID

If you don't know at least one of its CLSID guids then you cannot find out. Nor could you ever use the component so testing for something you can't use isn't terribly useful.
If this is an ActiveX component then you can learn more about it by looking at its type library. Which is usually embedded in the DLL as a resource. Check that first with Visual Studio's File + Open + File, select the DLL. If you see a TYPELIB resource then you're ahead. From the Visual Studio Command Line prompt, run oleview.exe. File + View Typelib and select the DLL. You'll see the interfaces and coclasses defined in the type library. Pick one of the guids of a coclass to test for.
Another way to find out is by using Regedit.exe and use Edit + Find. Type the name of the DLL. When it finds a key named "LocalServer32" then you found the CLSID key.
Another way to find out is by running a program that uses the component and observe the trace produced by SysInternals' ProcMon utility. You'll see the program searching the CLSID key and read the LocalServer32 key. With the disadvantage that the tool tends to drown you in data.

How to deploy a COM

I just finished building my new COM project (C#, .NET 3.5). This project will be called by a VFP application. It's working great on my development machine, but now I need to know how to deploy it on the user's machine. Click Once isn't available for this kind of project, so I guess I'm stuck with manually distributing the DLL.
So, where should I put the DLL and how do I register it?
BTW, the 3.5 framework is already installed on the user's machine.
TIA

I've really never used RegSvr32 with .Net assemblies, rather I use the regasm with the /codebase option:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\regasm.exe /codebase mydll.dll
You can also use the /tlb option to export the type library and register it.
Of course the easiest way, just create an installer with vstudio and it will do this for you.

Creating a Description of the COM class and Interfaces
.Net assemblies don't include information in Type Library compatible format. So it is necessary for the programmer to run one of two .Net-supplied utilities to extract the assembly description of a class into a Type Library file.
One utility is TLBEXP.EXE, the .Net Type Library Exporter. This command line utility takes as input the name of an assembly DLL file to be converted to a Type Library. The programmer can also specify the name of a Type Library file to be created.
tlbexp ComServer.dll /out:ComServer.tlb
Assembly exported to C:\Magellan\Source\Output\Debug\ComServer.tlb
Once a Type Library has been created, it can be referenced by a COM client to obtain the information necessary for the COM client to bind to the interfaces of the COM class, and activate the COM class at runtime.
Registration of the COM Class and Interfaces
For a COM class to be accessible by the client at runtime, the COM infrastructure must know how to locate the code that implements the COM class. The following command accomplishes this:
regasm ComServer.dll
Your DLL can be put anywhere you wish, but a good choice is C:\Program Files\MyApplication.
http://www.csharphelp.com/archives/archive190.html

Find COM DLL path from Com Interop Assembly

I am trying to write a wrapper around a legacy COM object and install the wrapper into the GAC. The goal would be to automate the setup of specific configuration information the component requires, and make a common strongly typed interface for all of my applications to use.
My solution thus far is to keep an XML configuration file in the same directory as the original COM DLL, and load the configuration in the class constructor. Unfortunately, I have been unable to find the location of the registered COM dll...
How do I get the full file path of the COM dll referenced by a COM object interop dll?

Presumably you could get the GuidAttribute or CoClassAttribute values from the interop DLL that map to the CLSID and IID values of your COM DLL. Then you can look up the appropriate DLL path in the registry.

Once you've created an object from the respective COM server, its DLL must have been loaded. Assuming that the underlying COM server is implemented in "mycomserver.dll", you could use P/Invoke and call GetModuleHandle( "mycomserver.dll" ) -- that gives you the path of the DLL.

If you know the CLSID of the COM dll, you can check if there's a key with that CLSID on HKEY_CLASSES_ROOT\CLSID\{CLSID-of-your-COM-component} or HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{CLSID-of-your-COM-component} (Wow6432Node => 32-bit COM registered on a 64-bit machine)
If the key is there, it means that the COM component is registered. Then look at the default value inside the sub-key InprocServer32
e.g.
HKEY_CLASSES_ROOT\CLSID\{12345678-9012-3456-7890-123456789012}\InprocServer32
HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{12345678-9012-3456-7890-123456789012}\InprocServer32
If helps, here is a reference example of how to open these keys using C# (you'd just have to check for the value in InprocServer32): How to check COM dll is registered or not with C#?

Just reflect the AddIn class.
var t = typeof(ThisAddIn);
var path = t.Assembly.CodeBase;

Why does regasm.exe register my c# assembly with the wrong GUID?

I've got a c# assembly which I'm invoking via COM from a Delphi (win32 native) application.
This works on all the machines I've tested it on, except one.
The problem is that the Delphi application gets "Class not registered" when trying to create the COM object.
Now, when I look in the registry under HKEY_CLASSES_ROOT\DelphiToCSharp\CLSID, the GUID listed there is not the same as the assembly Guid in AssemblyInfo.cs. It should be the same - it IS the same on all the other computers where it's installed.
I have tried regasm /unregister delphitocsharp.dll, and that removes the registry key. Then if I do regasm delphitocsharp.dll, the registry key returns, but the GUID is the same as before (ie. wrong), and Delphi still gets "Class not registered".
DelphiToCSharp.dll on the working machine is identical (verified with md5) to the version on the non-working machine.
All I can think of is that an old version of the dll was registered before, and there still exists some remnant of that file which is making regasm confused.
How can I fix or at least further diagnose this issue?

The GUID in AssemblyInfo becomes the "Type-Library" GUID and usually is not what you'd be looking for. I'm going to assume you're trying to access a class, and you need to define a Guid attribute and ComVisible for the class. For example:
[Guid("00001111-2222-3333-4444-555566667777"), ComVisible(true)]
public class MyCOMRegisteredClass
If you don't, then the class either a) won't be registered, or b) if you've defined COMVisible(true) at the assembly level, will be assigned a guid that .NET bakes up for you.

Maybe you have an old version of the assembly somewhere? Maybe in the GAC? Regasm is probably picking that up and using it.

Most probably you have a copy of the same (old version) dll somewhere on your system, search disk for copies of the same file and remove (backup) them manually before registering the new copy.