Custom Control Add-in error message

Denis_Vitse

Hi all,

I just made my first "Hello World" add-in for RTC and followed the procedure for registering through Nav Classic.

Even if I precisely followed the procedure, I have the well-know error message : the Page contains a control add-in that is not permitted. contact yourself or Mibuso but not Microsoft

Anyone knows why this thing is not recognized correctly? The public token is ok (got it with sn vs tool), the assembly is signed, the table client Add-in posess the right record and so on...

Any help appreciated...

Another question I have is why Nav recognized the Connect control that is in its own add-in folder sub-directory but doesn't find my assembly when I put it in its own subdirectory? When I put it in add-in root, then I get the previous message.

Thanks in advance and all the best

kine

Have you more RTC folders (more copies of the client)? Are you running the client from the correct folder?

Are you sure, that the addin is in the folder? Did you copy it as administrator? Isn't it only in the VirtualStore (if you are using Win7)?

Denis_Vitse

Hi Kine,

only one RTC,

running the client from def. install dir: %programfile%\\Microsoft Dynamics NAV\60\RoleTailored client,

the add-in is at root in folder add-ins: %programfile%\\Microsoft Dynamics NAV\60\RoleTailored\Add-ins. I tried in %programfile%\\Microsoft Dynamics NAV\60\RoleTailored\Add-ins\MyAddin but then Nav alerts it can't find registered component,

I am under Seven but I didn't copy it as admin (UAC disabled though),

Virtual Store? What do you mean by that? The file is physically in the directory. I could also try in the GAC...

Strange...
Is the assembly name under any implicit convention or something? I see that Connect is named like Microsoft.Dynamics.Nav.Client.<...>. Would that be a prerequisite?

Christian_Abeln

The error message (... is not permitted) says that the Add-in signature that has been selected in the ControlAddIn property of the field on the page does not have a matching entry in the ClientAddIns table.

If you have successfully registered the Add-in (manually or with the help of my Registration Tool) then you should try reselecting the Add-in in the ControlAddIn property of the field (in case you have changed the signature), compile the page and see if it works.

Hope that helps...

Denis_Vitse

Hi Christian,

it's really strange: I followed your advice and now, it looks like NAV permits the assembly.
This assembly is the NSpeech example you can find on the net. It basically overrides TextBox to complement its behavior and use some synthesizer to speech your text.
Problem is that now, when I request my customer card, NAV RTC crashes...
But this is possibly caused by the example itself. I'll chek in the logs.

Thanks for your help.

Denis_Vitse

Hmmm, do Microsoft Dynamics developpers know about catching Exceptions and logging the Exception call stack in Windows Logs?

I got an horrible Application Error Log telling me it failed in KERNELBASE.dll...

I guess I should def. try the "real" hello world example for once

Christian_Abeln

The Dynamics NAV RTC has some mechanics to catch certain exceptions. But we explicitely do not just catch / swollow any exception and show an error message / log errors- this is due to security reasons. Letting an application deliberately get into a error situation can be used to compromise the system state. Therefore, unexpected system states will let the RTC crash.
Yet typically an error log is created in the event log. This is sometimes not possible though, when the error information is only available in a different software system.
A good advice for Add-in developers therefore is to carefully implement Error & Exception handling in the Add-in code.

Denis_Vitse

... And thanks for you registration tool, Christian. Helpfull and it practically answered to my 2nd question.

As these are .NET assemblies, maybe you could enlighten me regarding registering/deploying assemblies with .NET applications in general:

When I program .NET stuff, I usually am contrained into putting assemblies at the root of app. dir or in the GAC.

How could someone do to put each assembly to its own specific directory and still be recognized when launching the application?

Denis_Vitse

Christian Abeln wrote:

A good advice for Add-in developers therefore is to carefully implement Error & Exception handling in the Add-in code.

I def. agree with this statement. That's the first thing I should have done in the plugin body.

Christian_Abeln

In regards to general loading of .Net assemblies: (This really is not NAV specific)

A .Net assembly can load other assemblies explicitely and use types from that other assembly. This is done through "Reflection", dynamic discovery and loading of types from assemblies in certain locations. NAV Add-ins mechanic uses this concept. In NAV we will in the future explicitely ignore assemblies with Add-ins that are in the GAC, but only load Add-ins from assemblies in the Add-in folder.

I an assembly references another assembly, then for the latter the standard .Net assembly resolver comes into place. Sometimes this is actually an issue for Add-ins in NAV RTC. If an Add-in assembly references another assembly, which in turn loads a third assembly from a specific place (like the application exe directory), then the distribution needs to take this behavior into account. This I have experienced with the WPF Toolkit, where I had to put the library WPFToolkit.dll into the RTC directory such that it would be picked up at runtime.

In special cases, a .Net component can hook into the assembly resolver and do its custom assembly resolving by setting up an event handler for AppDomain.CurrentDomain.AssemblyResolve. But be careful with that! An application requires certain permissions in order to do custom assembly resolving. Though my Add-in RegistrationTool for NAV makes use of this mechanic.

Denis_Vitse

Great info, Christian... And thanks for the tip regarding not using GAC for future compliancy purposes.