NAV 2013 R2 Could not locate control add-in library for..

justinaspetravicius

Hi,

while trying to run page with a Hello World add-in using this guide: http://blogs.msdn.com/b/nav/archive/201 ... %20Blog%29 I get this message:

Could not locate control add-in library for <...>

I'm using Microsoft Dynamics NAV 2013 R2 (7.10.36836). I've tried doing this with Visual Studio 2010/2012/2013 and tried different .NET versions: 3.5, 4.0, 4.5

Is there something else with add-in registration within NAV except add-in name from c# code and public key that I do not know about?

Add-ins already registered in the demo database works fine. But this custom one Hello World - doesn't.

I hope you could help me sort this out, because it's really annoying not to know if it's NAV problem (because in R2 over the week we found 4 bugs already and reported them to MS) or my problem.

p.s. I've also posted this question on StackOverflow: http://stackoverflow.com/questions/2411 ... -not-found

kine

In most cases the problem is that the addin libraries/files are not placed in the Addin folder on the server (and in correct service folder if you have e.g. more versions...).

justinaspetravicius

kine wrote:

In most cases the problem is that the addin libraries/files are not placed in the Addin folder on the server (and in correct service folder if you have e.g. more versions...).

Am. Well, my mentioned guide says that you only need to place the .dll in the Program Files (x86) RTC/add ins folder. After your comment I've also copied it to Program Files Services/add ins folder, but still nothing, NAV says it can't find the library.

I have Nav 60, 70 and 71. So I don't see any problems with copying to the right directory, because all version are put into directories accordingly.

justinaspetravicius

kine wrote:

In most cases the problem is that the addin libraries/files are not placed in the Addin folder on the server (and in correct service folder if you have e.g. more versions...).

Nope, that is not the problem. Add in is placed in two places:

Program Files (x86) -> Microsoft Dynamics NAV -> 71 -> Role Tailored Client -> Add-ins -> HelloWorld.dll
Program Files -> Microsoft Dynamics NAV -> 71 -> Service -> Add-ins -> HelloWorld.dll

And that's about it.

I've found some unregistered Add-ins in RTC -> Add-ins folder. Tried guessing name for registration in NAV by file name, I guess it worked, because I get a different type of error now (THIS IS NOT WITH HelloWorld, but with Microsoft.Dynamics.NL.Digipoortservice.dll)

So with this one .dll I get this error:

The resource for control add-in <..> is not invalid

Does that mean that my HelloWorld is somehow corrupted? Should I have done something within Visual Studio wrong?

Bgestel

I got the same message today

The resource for control add-in <..> is not invalid.

It got me scratching my head for a while. #-o

In i end i found the problem. When you import a .net dll containing your add-in via the control add in page. You get this error. The import function is only intended to be used with the jQuery type add-ins.

So if you run into this error and are trying to run a .net add-in , hit the delete butten in the control add in page.

PConijn

I have had something similar in NAV 2015. We added a control add-in to a page and it gave the same message. We had added the control add-in dll to the add-in folder on the server.

Compiling or designing fixed the issue, but you can hardly ask your users to do that. The issue could also be solved by placing the dll in the client add-in folder, but that would negate the wonderful new structure Microsoft designed for NAV2015.

It turned out that the add-in folder containing the dll was not copied to the temp folder and thus the control add-in on the page could not find it.

We solved this by creating a DotNet variable for the control add-in. In the properties, we set the variables to run on the client. Finally, we instantiated the variable in the OnInit trigger on the page (this runs before the controls are loaded) and then we simply cleared it again.

By instantiating the variable client-side, we managed to force the download to the user's temp folder and the control add-in then worked just fine.

We also determined that if the file is already present, it will not re-force the download, so in that, it acts more like a fail-safe.

It may not be the most elegant solution, but it will work if you are running into this issue.

OnInit()
netMyAddIn := netMyAddIn.MyAddInConstructor;
CLEAR(netMyAddIn);