CREATE function and automation objects

smalkmus

Hello,
I am trying to create an automation object so that I can communicate with a COM DLL. Previously, I was calling the create function like this:
ok := CREATE(myObject, TRUE, TRUE)

This worked fine but the performance on the RTC in a 3-tiered architecture was very slow. I changed the call to the create function so that the automation object would be created on the server instead of the client as follows:
ok := CREATE(myObject, TRUE, FALSE)

With this change, the performance on the RTC was much improved in a 2-tiered architecture but we recieve an error in the 3-tiered architecture:

This message is for C/AL programmers: Unable to create an instnce of Automation Server System.__ComObject with CLSID = ... Retrieving the COM class factory for component with CLSID ... failed due to the following error: 80040154..

How do I need to register my DLL in order for the COM objects to be created on the server? Do I need to put it in the bin folder on the server with the NAV service executable or just register it as a COM DLL using regasm and put it anywhere? Does it need to go in the GAC? I'm able to find a lot of documentation on how to work with Automation objects but I can't find anything that explains how the DLL should be deployed. Any help on this would be greatly appreciated!

wakestar

My guess is that you have to register the com object the same way on the server as you do on the client.
You use regasm for .net com-objects. regsvr32 for native com objects.
A good tool to investigate the problem is process monitor from sysinternals.
Just attach it to the executable on the service tier and look what's going wrong.

smalkmus

Hi Wakestar,
Thanks for the reply. The DLL is a .NET COM DLL. We were able to successfully register it using regasm but we still get that error. Is there something else that I might be missing?

I've used process monitor in the past to look at some performance metrics but I'm not sure how it could be used to troubleshoot a problem like this. Do you have any suggestions about what I could do with process manager to find out what's going wrong?

Thanks again for the help.

kine

Question is, what the COM is doing. If there are some visual things, than you cannot use it on server side. Of course, the server-side COMs are much faster, because there is less overhead. Another difference could be permission/account under which the COM is running.

smalkmus

Thanks a lot for the reply.

The COM DLL doesn't do anything visual, it's a web service wrapper. Since we can't access web services directly in NAV, we created a wrapper DLL for the service and expose it as COM.

You mentioned permission/account under which the COM is running. Do you mean that we need to give some read and/or execute permissions to the account that is running the NAV service on our COM DLL?

ara3n

one suggestion that you can try is to use the new exe NAV 2009 R2 and reference the DLL as dotNET type and then try and create it.

smalkmus

Thanks for the suggestion ara3n. I haven't had a chance to get my hands on NAV 2009 R2 yet and wasn't aware of this new feature, but that's great news to hear that we can directly consume .NET DLLs in NAV 2009 R2.

Unfortunately, this is a generic solution for NAV 2009 as well as NAV 4.0. The users of my solution will probably not upgrade to NAV 2009 R2 in a very timely fashion so until that time, I'll still need to figure out why the DLL isn't loading properly on the middle tier.

I found this article which consuming a a .NET dll on NAV 2009 R2. It mentions putting the DLL in the Service\Add-ins folder. Is there any similar documentation that anyone is aware of for NAV 2009 (pre-R2) which explains where a COM DLL needs to go on the service tier?

https://community.dynamics.com/product/nav/navtechnical/b/navericwauters/archive/2010/12/30/nav-2009-r2-net-interop-calling-a-web-service.aspx.
STEP 4: Deploy on RTC Environment

To be able to use this, the dll has to be available at the instance where the business logic is run. Therefore, you have to copy it it to the service tier "Add-Ins" folder, which is located in this map (or similar): C:\Program Files\Microsoft Dynamics NAV\60\Service\Add-ins

Copy the dll to that map as well...

ara3n

try and register it with -codebase parameter


regasm yourdll.dll -codebase

kine

if you are registering the library, it doesn't matter where it is. If you want to use it without registration, it must be placed into mentioned folder. Of course, this is for .net lib. COM lib must be registered...

wakestar

smalkmus wrote:

I've used process monitor in the past to look at some performance metrics but I'm not sure how it could be used to troubleshoot a problem like this. Do you have any suggestions about what I could do with process manager to find out what's going wrong?

The process monitor shows you registry activites. When you initiate a com-object, the registry is accessed in the background. The problem might me not exisiting registry entries or no permission access to certain registry entries or missing dll's... so you should not only look at the registry activies but also file activities in the process monitor.
Just to make sure we are talking about the same tool: http://technet.microsoft.com/en-us/sysi ... s/bb896645

Another tool which I use for com - related troubleshooting is com trace: http://www.blunck.se/comtrace.html
It sometimes gives you a bit more information.

wakestar

I just realized that I created a visual studio setup-project with the treemap - addin, which is also a .net com-object on the server side.

During the installation I put the following two files into the application folder ([ProgramFilesFolder][Manufacturer]\[ProductName])

Microsoft.Dynamics.Visualizations.TreeMap.DataBuilder.tlb
Microsoft.Dynamics.Visualizations.TreeMap.DataBuilder.dll

Plus, I told the setup project that the Microsoft.Dynamics.Visualizations.TreeMap.DataBuilder.dll should be registred during the installation. (Property registry = vsdraCOM)

Is there a tlb-file in your com-object output directory? If yes... deploy it also.

smalkmus

Thanks so much to everyone for the helpful replies!

I did make sure that my installation program is registering the DLL using the codebase option. I also confirmed that the DLL was being registered successfully by making sure that the TLB file was created correctly and by searching the registry for my DLL name and the classes that it exposes.

I believe I found the problem is not that the DLL was not registered properly but that because the DLL is a wrapper for a WCF service, it also has to include the WCF endpoint information in an application configuration file. The problem is that you can't specify that information in the MyDLL.dll.config file, it needs to be specified in the calling application's configuration file. In this case, for code running on the classic client, I need to include my DLL in the folder with the finsql.exe and put my endpoint settings in a file called finsql.exe.config. In the case of code running on the server, I needed to put the DLL in the Service folder and merge my endpoint settings into the Microsoft.Dynamics.NAV.Server.exe.config file. After doing that, my code is running successfully on the server through the RTC as well as on the client.

Thanks again for everyone's helpful input. It prodded me in the right direction to get to the solution.