Lync Server SDK, 2010 vs. 2013

In getting your Lync Server 2010 applications working and tested against Lync Server 2013, you might occasionally be tempted to cut corners. You might look for ways to avoid supporting multiple code bases, one for Lync Server 2010 and another for Lync Server 2013. Specifically, it might occur to you that, since the Lync Server SDK has barely changed at all from the 2010 to the 2013 version, maybe you can just run the existing version of your Lync Server SDK application, compiled against the 2010 version of the ServerAgent DLL, on Lync Server 2013 Front End Servers. After all, UCMA 3.0 applications can register against Lync Server 2013 Front End Servers, and there are only a handful of additions to the SDK in 2013, which you may not even need anyway. It’s worth a try, right?

Having tested this myself recently, I can tell you that it is definitely NOT worth a try, and I strongly suggest using the Lync Server 2010 SDK only with 2010 Front End Servers and the Lync Server 2013 SDK only with 2013 Front End Servers. Even though the functionality in the SDK has changed very little between versions, you have to keep in mind that the architecture of the Front End Server itself changed quite significantly in Lync Server 2013, with state information being stored differently, and different relationships between users and Front Ends, among other things. I suspect that this is why, even though the API seems to be mostly the same on the surface, it is not as backwards compatible as the few changes might lead you to believe. In my experience, not only does using the SDK with a different version of Lync Server lead to problems, but it leads to the kind of sneaky, difficult to troubleshoot problems and erratic behaviour that is every Lync developer’s nightmare.

See, if you run a managed SIP application compiled with the 2010 DLLs on a 2013 Front End Server, the application will likely start up just fine, and successfully establish communication with the registrar service. You may not suspect that anything is amiss until you run into trouble later.

In one instance I saw, the application then received dispatched requests, and the appropriate method in the managed code was executed, but the Request property in the event arguments was empty, so the application had no access to the request that had been dispatched. There was no exception or any other indication of why this was happening, but switching to the 2013 version of the ServerAgent DLL fixed the problem.

In another case, certain functions in the MSPL script loaded by the managed SIP application mysteriously caused stack overflows. Again, switching to the newer version of ServerAgent.dll cured the problem.

I haven’t yet tested going in the other direction (using the Lync Server 2013 SDK with 2010 Front End Servers), but given my experiences so far and knowing how the Front End Server role has changed between versions, I wouldn’t recommend trying it unless it’s out of sheer curiosity. It seems the best approach is to have two separate versions of your application, one using the 2010 version of the SDK and another using the 2013 version. Most likely you won’t need to make any code changes, just substitute one referenced DLL for the other.