Mysterious "DotNet Interoperability" Category in the Add-in table

EvR

Hi all,

Does anyone know what is up with the add-in category type 'DotNet Interoperability'?



What does this do? Can we import .net assemblies in the same way as we all do with JavaScript addin resources? Does this mean we don't have to copy custom .net assemblies to all our NST's anymore? What is this undocumented category and how does it work?

Gr, Erik

wakestar

EvR wrote: »

What does this do? Can we import .net assemblies in the same way as we all do with JavaScript addin resources? Does this mean we don't have to copy custom .net assemblies to all our NST's anymore? What is this undocumented category and how does it work?

I'm pretty sure it's documented somewhere but I cannot find the link right now.
Anyway...

When you operate in the Cloud (Managed Services for instance) you don't (and shouldn't) have permission to write to the file system (except temp folder). So Microsoft introduced a mechanism to deploy your DotNet assemblies out of the database. At runtime they get extracted from the Add-in table and stored in some temp folder. So yes... you can use this table to let NAV deploy your assemblies. In case your DotNet assembly uses other 3rd-Party dlls... just pack all of them in one zip-file and import it into such a record with type 'DotNet Interop'.

EvR

Right, after some more testing it works.

Instead of the single package with all assemblies in it, with the name 'NavCommerce.Core', I've named it exactly the same as the assembly name. With the correct public key. And then it works!

So we need to add all our assemblies to the addin table, with the correct assembly names and public keys. This really makes installing a breeze!

wakestar

Right, in my case I have *one* zip with all of our DotNet - Assemblies (several .NET - Projects / Assemblies).
In the past this one zip - file was extracted to one folder under der AddIns - Folder on the service-tier.
Now I just create several records in this table with always the same *zip* file. For each assembly which gets called from NAV I have a record (with the correct name, public key, version).

EvR

No one?
The MSDN page on this subject is as useful as a 'lorem ipsum' page...

archer89

the msdn page for that topic: https://msdn.microsoft.com/en-us/library/hh895495(v=nav.90).aspx

category "DotNet Control Add-in": used for visual control add-ins
category "DotNet Interoperability": used for non visual .net assemblies, which extend the functionalities of dynamics nav (need no entry in addins table, but should also be saved to addins folder)

EvR

I know. But like I said, the MSDN pages on the topic are not helpful at all.
They don't explain anything.

wakestar

EvR wrote: »

What does this do? Can we import .net assemblies in the same way as we all do with JavaScript addin resources? Does this mean we don't have to copy custom .net assemblies to all our NST's anymore? What is this undocumented category and how does it work?

I'm pretty sure it's documented somewhere but I cannot find the link right now.
Anyway...

When you operate in the Cloud (Managed Services for instance) you don't (and shouldn't) have permission to write to the file system (except temp folder). So Microsoft introduced a mechanism to deploy your DotNet assemblies out of the database. At runtime they get extracted from the Add-in table and stored in some temp folder. So yes... you can use this table to let NAV deploy your assemblies. In case your DotNet assembly uses other 3rd-Party dlls... just pack all of them in one zip-file and import it into such a record with type 'DotNet Interop'.

EvR

Thanks very much for the reply.
I've actually tried this route. But as soon as NAV invokes a method that uses the assembly, it still throws the exception that the assembly cannot be found.

What I did:
- In our setup routine, create a new Add-in record of Category 'DotNet Interoperability'.
- The setup routine also downloads the resources (.zip file containing the assembly plus one referenced assembly Microsoft.WindowsAzure.Storage) and stores it in the Resource BLOB field. Both assemblies are signed.
- Restart the NAV service.

The add-in record contains the zip file because I can export it. Both files are present in the zip archive.


The exception:



Any suggestions?

Gr, Erik

EvR

Right, after some more testing it works.

Instead of the single package with all assemblies in it, with the name 'NavCommerce.Core', I've named it exactly the same as the assembly name. With the correct public key. And then it works!

So we need to add all our assemblies to the addin table, with the correct assembly names and public keys. This really makes installing a breeze!

wakestar

Right, in my case I have *one* zip with all of our DotNet - Assemblies (several .NET - Projects / Assemblies).
In the past this one zip - file was extracted to one folder under der AddIns - Folder on the service-tier.
Now I just create several records in this table with always the same *zip* file. For each assembly which gets called from NAV I have a record (with the correct name, public key, version).