Getting Started in Lync Development: Choosing The Right Tools

I like doing DIY. It’s totally different to what I do for work, it’s hands-on and the rewards are immediate and lasting.

It’s expensive though! Sometimes in the past, I’ve come up against a task that needs to be completed, and there’s a certain tool that’s been designed to complete that task, especially designed to do just that one thing. But I don’t have that tool.

I used to think “oh, I don’t need that! I can make do just fine, using just this old screwdriver and a bit of string”.

It turns out most tools were designed because you can’t make do just fine using substitute equipment. I would spend hours, getting more and more frustrated, or end up ruining whatever I was trying to do, because I was too cheap to go and purchase the proper tool.

Choosing the right tools for the job is important. It can save you time and frustration.

If you’re going to be doing Lync development, you need to make sure you’re choosing the right tools for the job. I’m here to help you with that. Use this post to make sure you’ve got everything ready to go, then dive in and start developing.

Different Jobs, Different Tools

As you know, there are different types of Lync Development, and each has a different set of requirements. The type of application you’re going to be building influences what applications and environments you’ll need.

Building CWEs or Client Desktop Applications

If you’re building Windows applications which will sit on user’s machines, or Conversation Window Extensions, then it’s your lucky day: this type of development requires the least amount of setup. You’ll need:

Lync Client – unless you’re building UI Suppressed applications, your user will need to have the Lync client installed and running whilst they use your application, and so will you whilst you’re developing.

Silverlight – if you’re building CWEs then you’ll be building Silverlight applications. You and your clients will need to have Silverlight installed. Any version after 4 should be fine.

Visual Studio – I’m going to recommend that if you’re going to be building a Microsoft application, using Microsoft Lync, which will run on a Microsoft Windows machine, you should be using Microsoft Visual Studio. Other IDEs are available, but this blog will assume you’re using VS 2013.

Lync Client SDK – this is the SDK which will allow your application to talk to Lync. You need to make sure you pick the right version of the SDK to match the version of the Lync client which you and your user’s have. If you need to target the Lync 2010 client, then you should use the Microsoft Lync 2010 SDK. If you only have to worry about the Lync 2013 client, download the Microsoft Lync 2013 SDK. If you are targeting both, use the 2010 client to ensure you don’t try and do anything which isn’t compatible with 2010.

Next Steps: Answering the Call : accepting incoming calls in Lync Client SDK, Tracking Lync conversation in code, more coming soon…

Building UCMA Applications

UCMA Applications are hosted within the Lync environment, not on your user’s machines, so the prerequisite list is a little longer than for client applications. You’ll need:

Visual Studio – or equivalent

A Lync Environment – depending on what sort of UCMA application you build will depend on whether you just need to be able to log into a Lync environment as a user, or whether you need more security clearance. First you need to choose between User and Application endpoints. If you’re only building User Endpoints you don’t need to do anything special. However, if you’re creating Application Endpoints then you’ll need to provision them, and for that you’ll need an Application Server (see below) and also enough permissions to create Lync objects such as Applications and ApplicationEndpoints (see below)

Application Server – only if you’re using Application Endpoints, the Application server is where you will be running your application. You won’t be able to run your code on your development machine because Trusted Applications (which is what applications that use Application Endpoints are) can only run within Application Servers. Your Lync admin should be able to help you with this. (Question for the audience: would a blog post on how to set up an application server be useful? How many developers end up having to do this?)

UCMA Managed API – this is the API which allows you to create applications using either User or Application Endpoints. For Lync 2010 server environments, download UCMA 3.0 API. For Lync 2013 server environments, download UCMA 4.0 API.

Good Logging – one of the side effects of code running on the Application Server is that you can’t really debug it. You have some options though, and good logging is one of them. You can get around the lack of debugging if your code is verbose about what it’s doing, and communicates errors to you properly.
If it’s a small environment, and you have the permissions to do so, you could provision your development machine as an Application Server, or install Visual Studio on the Application Server. This will give you the full Visual Studio experience for your application code, which could save you hours in frustration.
Finally, you can set up Remote Debugging on your code so that you can still debug it from your development machine.

next steps: Creating UCMA Applications with a UserApplication instance. Example: sending IMs, Walkthrough: Creating a UCMA Application & Application Endpoint, UCMA 101 Training Video, more coming soon…

Microsoft SIP Processing Language Scripts

MSPL Scripts are run on the Lync SE or Edge Server. You’ll need:

Notepad – Most MSPL scripts are small and they’re not pre-compiled before being added into Lync. Therefore you can use any text editor to create them.

PowerShell access – you’ll need to have enough permissions to add the scripts into your Lync environment, using PowerShell commands

Visual Studio (optional) – depending on what sort of MSPL you’re writing, optionally you can run a standard application alongside the MSPL to perform additional tasks. If you do this, then you’ll Visual Studio (or equivalent) to create that application.

next steps: MSPL blog posts coming soon…

Unified Communications Web API

UCWA is a REST API which allows communication with Microsoft Lync. If you’re building UCWA solutions, you’ll need:

Fiddler – a lifesaver for HTTP Request-Response traffic troubleshooting. It’s worth spending half a day getting really familiar with how it works, and what it’s telling you. Remember, nothing is a black box!

Your IDE… – UCWA is pure HTTP, and so can be used anywhere that HTTP can be. This makes it an excellent choice for things that AREN’T built using Visual Studio. Use your favorite Node.JS editor, or your Raspberry Pi to put Lync in new places!

…or Notepad – Alternatively, you can build web solutions using JavaScript, in which case all you need is Notepad and the UCWA Helper Files for JavasScript.

next steps: UCWA blog posts coming soon…

Written by Tom Morgan

Tom is a Microsoft Teams Platform developer and Microsoft MVP who has been blogging for over a decade. Find out more.

---

Buy the book: Building and Developing Apps & Bots for Microsoft Teams. Now available to purchase online with free updates.

Related posts:

UCMA Endpoints: Choosing between Application and User Endpoints Lync Development Samples from MSDN Microsoft Lync’s Development Secret: it’s easy! The Only Thing You Need To Know About Lync Persistent Chat and Application Endpoints Learning to dive: UCMA Coding