0

I'm on a C# project, and since it uses Sharepoint I'm working on a MS Server 2008.

The project compiles and runs fine on server, so I thought it was time for deployment, and created a Installer Project, provided by Visual Studio itself.

When I run the installer then the program on server, it works flawlessly. But when I do that on my local machine, it says a COM reference is missing or something.

The fact is that this project indeed references a Visual Basic DLL provided by my company, and I just don't understand why the installer won't copy/register it by itself. It managed to get some other needed DLL well and copied it to the installation folder (like Microsoft.IdentityModel.dll, Microsoft.SharePoint.Client.dll...).

Any hint on what I should do to have it working? I do not have access to the "copy local" property of the referenced DLL (it's greyed).

Edit: some pictures, maybe it'll help:

http://hpics.li/2f6acc4

http://hpics.li/86e8b11

http://hpics.li/6697314

Edit 2: So it's a bit more complicated that I thought. In fact, when I simply reference the original DLL (which is GestionClevb6.dll), I end up getting the "unregistered class" error in my program. But if I reference the generated Interop.GestionClevb6.dll, I notice another DLL being added to the deployment project (a dependency I guess). Oh yeah. So I have two DLL in the end, GestionClevb6.dll and the new one, DLL_Licence.dll, and a brand new bug: "Exception de HRESULT : 0x800AC352."

Kilazur
  • 3,089
  • 1
  • 22
  • 48

1 Answers1

2

The error about a COM reference missing means that your project references a COM class, but on the system you're trying to run the program that COM class is not registered.

You need to make the setup register the COM-DLL in the course of the setup process. It will not be done automatically! Otherwise, if the COM-DLL has not been registered, you'll get this error. I suppose that on the server where it works, the DLL has been registered before.

don't understand why the installer won't copy/register it by itself.

How should the installer know that it is a COM DLL that must be registered?

It managed to get some other needed DLL well and copied it to the installation folder (like Microsoft.IdentityModel.dll, Microsoft.SharePoint.Client.dll...

These are managed DLLs directly referenced by your project. They don't have to be registered. Also, as these are managed referenced DLLs they will be copied as part of the "Project Output" if the "Copy Local" property for the reference is configured accordingly.

This, however, does not work for COM-DLLs. There's no "Copy Local" property for COM-references as it wouldn't help anyway - DLLs containing COM classes need to be registered. Copying alone doesn't register them.

Thorsten Dittmar
  • 55,956
  • 8
  • 91
  • 139
  • The fact is that I added a copy of the DLL in the installer, having the option to register it, and it obviously didn't change a thing, except I had the dll after setup. How can I do what you say? – Kilazur Apr 16 '14 at 10:21
  • http://stackoverflow.com/questions/3087063/use-visual-studio-setup-project-to-automatically-register-and-gac-a-com-interop – Thorsten Dittmar Apr 16 '14 at 10:25
  • That easy uh... BTW I can't register it to GAC, it doesn't have a strong name. – Kilazur Apr 16 '14 at 10:32
  • I know. Ignore that part. The important answer is *It can also register the assembly like Regasm.exe does. Set the Register property of the project output reference to vsdrpCOM.* – Thorsten Dittmar Apr 16 '14 at 10:44
  • That didn't do it, I must have skipped a step somewhere. I did set this property to vsdrpCOM for the item Main Output of MyProjectName (Release x86) (well, that might not be the actual name, I'm french) under my setup project in my solution. Do I have to do something else? – Kilazur Apr 16 '14 at 12:10
  • No, you need to set this property for the DLL file, which you probably must manually add to the installer project. – Thorsten Dittmar Apr 16 '14 at 12:47
  • Ok, so that has been done already (several times in fact) and didn't work. That was the first thing I did before coming to SO; yet my DLL is copied to the install folder, but not registered. – Kilazur Apr 16 '14 at 12:52
  • I don't think that the installation folder is the correct place for a shared DLL. Copy it to System32. Another thought: Is the DLL 32-bit or 64-bit? That makes a difference, you know? Maybe the DLL *is* registered, but due to your application being executed in 64-bit mode it doesn't "find" it (if the application is compiled as ANYCPU). What happens if you register the DLL manually? Does it work then? If you unregister it, does it stop working? If you checked all that, come back and report what happened. – Thorsten Dittmar Apr 16 '14 at 13:16