2

What we did:

We have created a C# class library project to talk to external webservices. When we check "register for COM interop" this DLL is automatically registered and ready for use on the PC where the registration occurred. The Navision client on that PC can then use an "automation" variable to find this DLL and use it.

What's the problem?

We need to rollout this DLL to the production environment. We're working with an RDP solution where the navision client runs on 2 RDP servers which our users use. This means that we only need to be able to deploy the DLL to these 2 servers. We have tried the following 2 solutions we've found here and on several blog posts:

  • Drag the DLL to C:\windows\assembly (as administrator)
  • Use the REGASM to register the DLL (REGASM ourDll.dll /tlb:ourDll.dll)

After having executed these we've found the DLL in Navision which we tried to initialize using a CREATE command:

CLEAR(ourDll);
CREATE(ourDll);
IF ISCLEAR(ourDll) THEN
    CREATE(ourDll);

But after this we receive the following error (translated version):

This message is for C/AL programmers:

Could not create an instance of the OLE control or Automation Server identified by Automation Server with identification GUID={guid} 1.0:{guid}:'ourDll'.Consume

Verify if the OLE-control or Automation server was correctly installed and registered.

After this we tried to run GACUTIL /i ourDll.dll which installed our DLL into the GAC but the result remains the same. Since we've done this there's an errormessage:

The text is too long for the buffer.

However this error doesn't seem to stop navision of compiling. The error message on run stays the same as above.

IvanL
  • 2,475
  • 1
  • 26
  • 39
  • I suggest you don't put the assembly in the GAC (no drag to windows\assembly, no GACUTIL), but use REGASM with the /codebase option instead. Also make sure the bitness of the COM C# DLL is compatible with the bitness of the Navision client (32-bit vs 64-bit) – Simon Mourier Jun 13 '13 at 09:11

3 Answers3

1

We were able to resolve this and sharing the final resolution here so that people who get into the same situation might not need to spend the many hours we put into this:

The problem was not the guids or interfaces but the used verson of REGASM of the .NET Framework.

Since the target framework was 3.5 we assumed that the version of REGASM also had to be <= 3.5, also we assumed that we had to use the REGASM of the 64-bit Framework. However after a good amount of trial and error it appeared that the version we had to use was the 32bit v4 REGASM (see our used .bat file for registration below), this resolved all issues and our DLL is now happily being used in the Navision client.

SET GACUTIL="C:\Program Files (X86)\Microsoft SDKs\Windows\v7.0A\bin\gacutil.exe"
SET REGASM="C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\regasm.exe"
%REGASM% OurDll.dll /tlb:OurDll.tlb
%GACUTIL% /i OurDll.dll
IvanL
  • 2,475
  • 1
  • 26
  • 39
  • Even this solution did not work on production navision client, on the developer side it works fine, why? – M. A. Jun 17 '14 at 18:54
0

Assuming you are using NAV 2009 R2, or 2013: When you register it globally, then it is accessible by the IDE. To actually let the NAV service tier use the assembly, you also need to put a copy of it in C:\Program Files\Microsoft Dynamics NAV\70\Service\Add-ins

Allanrbo
  • 2,278
  • 1
  • 23
  • 27
0

In my case I missed the /codebase option. So to register the assembly I needed to use the /codebase option and the /tlb option.

See this post: What does "Register for COM Interop" actually do?

Community
  • 1
  • 1
Viktor
  • 679
  • 6
  • 21