Control Add-ins and Version Compatibility

(Update, 20.4.2015: As it turns out – this post is not entirely accurate, as pointed out by Johannes Sebastian. Please read the next post to learn more about which parts are, and which aren’t correct.)

Control Add-ins written in C# are not cross-version compatible. You cannot use an assembly compiled for 2013 R2 with 2015 (or the opposite way around, or any other version combination for that matter) without recompiling it with correct extensibility framework assembly reference.

Control Add-ins written in JavaScript don’t have to be recompiled, are mostly interchangeable, and are (so far) guaranteed to be forward compatible. You can always use a version built for 2013 R2 in 2015. You can use a version built for 2015 in 2013 R2, but the opposite way around is only true if you don’t use any of the new JavaScript extensibility features not supported in earlier versions.

Vjeko

Vjeko has been writing code for living since 1995, and he has shared his knowledge and experience in presentations, articles, blogs, and elsewhere since 2002. Hopelessly curious, passionate about technology, avid language learner no matter human or computer.

This Post Has 12 Comments

  1. Johannes Sebastian

    Hi
    I’m sorry but this is not correct. I use the same compiled Add-in Control for versions 2013, R2 and 2015 in an ISV Add-on..

    1. Vjeko

      Control add-in or an assembly?

  2. Mark Brummel

    I have one that I use with various customers from 2009R2 all the way up to 2015.

    Maybe only when using events?

    1. Vjeko

      I’ll check and come back, this is confusing… you two say it works, and I know for a fact I had to recompile…

  3. Kamil Sacek (@MVPKine)

    If you are not includig the Microsoft DLLs in the Addin folder, than I think you can use it without recompile. If you are including them, you need to recompile to include the new dlls… but take it as a blind assumption, I had no time to confirm that…

    1. Vjeko

      My take on this is as follows: in .NET, every type in a strong-named assembly includes the version and the public key token in its type name, therefore it’s not enough to simply have a type in the same namespace. Since assemblies have different version, the types (classes/interfaces) that the control add-ins use are different between versions. I had to recompile them, and I did experience this issue. So, now I see two people who say it work, and you Kamil suggest that deploying assemblies would help. I’ll check and then post about it.

      1. Johannes Sebastian

        Control add-in or an assembly? – Yes I think Mark you must be referencing an assembly.

        2009 Control Add-ins will not work in 2013 since 2013 requires DotNet 4.0, IF I recall correctly!


        Also, this:
        https://msdn.microsoft.com/en-us/library/dn182544(v=nav.80).aspx

        “Control add-ins that are designed with Microsoft Dynamics NAV 2013 R2 or Microsoft Dynamics NAV 2015 using a .NET 4.5 assembly and a manifest file, can be used on all display targets. Control add-ins that were written for earlier versions, will still run on the Microsoft Dynamics NAV Windows client.”

        I can add that: A 2013 R2/2015 control add-in works fine in 2013. (Haven’t tried it on 2009)

        1. Vjeko

          Thanks for pointing out that my post was wrong. I’ve now spent quite some time analyzing what’s happening, what is, and what isn’t compatible. As a matter of fact, control add-ins written in 2009 will work without recompiling on new versions, even though they use new versions of .NET. Microsoft has done something inside NAV to allow cross-.NET framework references of assemblies in 2013+ so anything built for earlier versions continues working. However, backward compatibility does not work, anything built for 2015 does not work in 2013 R2, etc. This is the problem I experienced that made me post the “quick tip” post from yesterday. I didn’t bother to check for forward compatibility, and as it seems – forward compatibility fully works.

          Regarding the quote from the MSDN article you make, it is a bit fuzzy. You don’t actually need .NET 4.5 to write JavaScript control add-ins, most of mine were written with .NET 4.0. As a matter of fact, .NET version is completely irrelevant there, because it’s only needed by the Development Environment to understand the methods and events exposed by it.

          Anyway, thanks for the hint – if you didn’t leave the comment, I would never bothered to verify, and I wouldn’t really know the truth. Thanks!

          1. Johannes Sebastian

            You’re right, I am wrong about that.

            I am actually using the forward compatibility.
            See here
            http://bit.ly/1Horl53

            My add-in is built for 2013 it turns out. And Dotnet 4.0
            I Did update the naming for it to work with 2015, but its referencing 7.0.

            Anyway, thanks for sharing all of this!!

          2. Vjeko

            No problem. Please keep correcting me when I am wrong 🙂

        2. Vjeko

          By the way, are you sure about what you say here:

          I can add that: A 2013 R2/2015 control add-in works fine in 2013. (Haven’t tried it on 2009)

          ? I tried that as well, and I can’t make it work. 2013 runs 2009, 2009 SP1, and 2013, but not 2013 R2, or 2015. I’ve created the simplest of the simplest – my control simply shows creates a red button, and uses absolutely nothing else from the whole framework, and I’ve made 5 versions of the same control, compiled with 5 different NAV extensibility framework assembly references (2009 SP1, 2009 R2, 2013, 2013 R2, and 2015).

Leave a Reply