This year’s WinDays conference is just few weeks away! If you have a chance, attend it and we’ll see on thursday, April 25th in Umag, Croatia.

As previous year, I’ll be giving a workshop (this year: 3 hours) about Lync Client/Server development. With some additions to new Lync Server 2013, and what it brings to developers. Come and join!

http://www.windays.hr/raspored/predavanje/0602982e-f499-e211-b448-02bfc0a89f37

Hello everyone,

today I’ll write about on how to migrate your existing Lync 2010 code for usage with new Lync Server 2013.

Luckily, nothing much to be done here, since Lync Client 2010 API is fully compatible with the new server. Therefore, you can just start your application (whether it is a WPF controls / automation, or Silverlight CWA) and it should run smoothly. I have tested my existing integration project on different platforms using ‘old’ Lync Client 2010 API (I referenced namely Microsoft.Lync.Model.dll, Microsoft.Lync.Utilities.dll, and Microsoft.Office.Uc.dll) on several platforms (OS, processor, Lync server and client versions) and here are my findings:

- Vista 64bit (domain with Lync server 2010) – connecting to Lync client 2010 – both 32bit and 64bit apps works
- Win7 32bit (domain with Lync server 2010) – connecting to Lync client 2010 – 32bit works, 64bit don’t
- Win7 32bit (domain with Lync server 2010) – connecting to Lync client 2013 – 32bit works, 64bit don’t
- Win7 64bit (domain with Lync server 2013) – connecting to Lync client 2010 – both 32bit and 64bit apps work
- Win7 64bit (domain with Lync server 2013) – connecting to Lync client 2013 – 64bit works, 32bit don’t
- Win7 32bit (domain with Lync server 2013) – connecting to Lync client 2010 – 32bit works, 64bit don’t
- Win7 32bit (domain with Lync server 2013) – connecting to Lync client 2013 – 32bit works, 64bit don’t

I’ve also recompiled the project with new Lync Client SDK Preview, but it won’t work with Lync Client 2010 version, so I’ll skip it for the time being. New SDK can’t connect to the old Lync Client app, and our customers still use it, so I won’t be using it soon. But, it is worth noticing its potentials, especially if you plan to use some of the new features it has, such as:

- Resource sharing,
- Lync on-line meeting control, and
- Lync persistent chat room (previously: group chat) participation.

More info at: http://msdn.microsoft.com/en-us/library/lync/jj265327.aspx

The one thing that HAS changed with new Lync Client application is its process name. Previously, (from OCS version onward) it was named ‘communicator.exe’, and now, the client app is named’ lync.exe’. So, if you use some sort of tracking whether client process is running (as I do), make sure you update this functionality accordingly.

Kind regards,
Ratko.

today I’ll talk about one issue with Lync Client API you already might come across in doing initialization of LyncClient object in your custom app.

The problem appears when you handle the LyncClient object reference and, for some reason (albeight communicator is gracefully ended or focibly shut down), the object become ‘unavailable’. If you subscribed to the ClientDisconnected event, it will be fired now. This would be the indication to try to initialize the object again when Lync is back, since the reference becomes useless. Actually, if you try to initialize the object again with:

m_lyncClient = null;
m_lyncClient = LyncClient.GetClient();

you will get either: an exception of one of the lync’ defined types (e.g. ClientNotFoundException), or: the client object will go into the Invalid state. This latter case seems to be the problem to handle.

This case arises when you handle Lync client object on another threads (i.e. worker threads), which is quite normal, since polling for Lync connection via timer and/or operating with Lync client API via wrapper class acting like a ‘model’ (in case of MVVM) is usual thing to do. In this case, Lync Client API doesn’t know how to find the right reference and it just goes into invalid state. The resolution is to find the right thread from where the original reference is created, and this would be in most cases, the very main (UI) thread. If you use Lync controls or start to call the API from some UI element, this would be the thread from where you started to use the API. So, the only thing to do in this case, is to check for the invalid state (a suitable place would be in your re-initialization code) and dispose all resources bound to API, together with the object itself (it doesn’t have a Dispose method, so you just set it to a null value):

try
{
m_lyncClient = null;
m_lyncClient = LyncClient.GetClient();

// we must check the invalid state, since this is the indication of lost reference and malicious lync object
if (m_lyncClient.State == ClientState.Invalid)
{
// Note: disposing of the original reference must happen on the main thread!
App.Current.Dispatcher.Invoke(new Action(() => {

// release main Lync API object (next time, correct reference will be created)
Dispose();
}));
}
else
{
SubscribeToLyncEvents();
}
}
catch (ClientNotFoundException cnfEx)
{
…
}
catch (COMException cEx)
{
…
}
catch (NullReferenceException nrEx)
{
…
}

After you’ve done that, initialize the API object again and you’ll be good to go.

Kind regards,
Ratko.