NAV 2009 .NET automation cant find assembly for custom config section

FrodeBreimo

Hello

I am writing a .NET dll to be used as an automation for NAV 2009 R2. It communicates with several web APIs that are configured in a .config file. The .config uses custom configuration classes (ConfigurationSection, ConfigurationElementCollection and ConfigurationElement), these classes and the .config file have been checked using a test app, and they are loaded fine. The configuration classes are in the same dll as the business classes.

The dll and all it's dependencies, including the .config file, have been copied into the classic\add-ins folder, and NAV is able to read the config file (I know this through debugging and the fact that the exception refers to a line number in the config file). The following exception occurs when the C# code tries to instantiate the custom configuration section:

The call to member Initialize failed. System.Configuration returned the following message:
An error occurred creating the configuration section handler for AdaptersSection: Could not load file or assembly 'Cenium.Nav.CIPAdapter' or one of its dependencies. The system cannot find the file specified. (C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins\Cenium.Nav.CIPAdapter.dll.config line 4)

The config file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name ="AdaptersSection" type="Cenium.Nav.Adapters.Internal.AdapterConfigurationSection, Cenium.Nav.CIPAdapter" />
</configSections>

<AdaptersSection>
<Adapters>
<Adapter name="CIP" adapterType="Cenium.Nav.Adapters.MessageAdapter" />
<Adapter name="CIS" adapterType="Cenium.Nav.Adapters.CISMessageAdapter" username="" domain="" password="" />
<Adapter name="CENIUM9" adapterType="Cenium.Nav.Adapters.Cenium9MessageAdapter" username="brefro" domain="CENIUMDOM" password="NotMyRealPassword" />
</Adapters>
</AdaptersSection>

</configuration>

I have tried including versioning info in the section type declaration, but that does not help. I have also tried using ProcessMonitor to see which file it is looking for, and where, but it didn't pick up anything.

Any help would be greatly appreciated

Slawek_Guzek

Hi,

To be honest the stackoverflow.com would be possibly much better place to ask this question as it seems it has nothing to do with NAV, but a lot with your C# or VB code

Slawek

FrodeBreimo

Thank you for your quick response.

I posted this here because everything loads perfectly fine in my C# test program, so the config file and classes are fine. It only fails when run from NAV.

I'm thinking it has something to do with the NAV environment/context in which the code is running, like NAV-relevant paths or access control or something. The assembly runs fine (from NAV) if I omit the config file and hardcode the values, but that is obviously not an acceptable solution.

AK

Does you NAV code run on the service tier or on the client? If it is the service tier, the path and file has to be accessible for it. You might also check the rights for accessing the path of the user the service tier is using.

Slawek_Guzek

You didn't posted any screenshots, and snippets of your code, just a sample of configuration file which is not even read by NAV by the way, but by the code inside your dll. That's not much information.

It would be a NAV related problem if your dll could not be loaded by the C/AL code, or NAV could not see some methods exposed by the automation object. Even then the fix would be to declare properly the object as COM component, to declare properly interfaces, or to register the dll in the system with correct version of regasm.

If NAV can load the automation object then you cannot do anything more in NAV. All what NAV does is calling the constructor when the object is instantiated, and further on it calls exposed methods and accessing properties. Any failure inside the dll, in any part, will come back to NAV as exception, and there is nothing you can do with it in NAV.

From your original description it looks like NAV can load your dll, the failing bit is somewhere inside your dll during loading your custom config file. That's why stackoverflow seemed to be a better source.

As far as I know NAV does not control in any way paths or assemblies the code inside the dll can access. The only restrictions are imposed by the security context of the account under which NAV session is run.

What you can do is to write a very simple piece of code in NAV starting the cmd.exe (you can use the SHELL('c:\windows\system32\cmd.exe') command). Spawned process will inhering permissions/environment settings from the parent NAV process. Test your dll with your test C# program inside this command session.

Slawek

FrodeBreimo

Thanks Slawek, what you're saying makes a lot of sense. I will try your suggestion regarding cmd.exe to test it out. Thanks again.