I already wrote about UCMA 3 applications and Lync 2013, and working on that post got me thinking about what configurations (supported or not) will actually work. As a disclaimer for all of this, these results are based on some reasonably quick testing of a UCMA app. I haven’t tested the entire runtime, so there may be problems that I don’t know about (although if you find cases that don’t work, drop me a line and let me know what you find). That being said, the app I tested with set up an AudioVideoCall, created conferences, set custom audio routes, added and removed participants from a conference through dial out, used TTS, and processed Instant Messaging calls, so I’m reasonably confident that most of these cases are going to work out just fine. I also don’t have any references to UC workflow in my projects (and neither should you, because it’s gone in UCMA 4), so there’s not that complication to worry about.
Most of this started with a reasonably simple question-how can you build a UCMA 3 application and a UCMA 4 application on the same machine. As I’m sure others have found, attempting to install the UCMA 4 sdk on a machine that has UCMA 3 installed will force you to uninstall the old version before proceeding, but really, what is this error saying? UCMA is really just a series of assembly references, and a runtime, right? And I can have multiple .net versions installed on the same box, so why not UCMA? As it turns out, it’s possible, but you have to selectively uninstall things, and be willing to work with manual provisioning in development (which I’d recommend doing anyway).
There are three pieces to the UCMA SDK that you’ll need to consider: the core components (OCSCore.msi), the SDK itself, and the Microsoft.speech SDK/voices. First, the core components, which you’ll see in add/remove programs like this:
This is the stuff that installs in C:\Program Files\Microsoft Lync Server 2010\Deployment, and contains the files you need to bootstrap the machine, and install the local config store. These are installed on every machine in the topology, and will have to get uninstalled if you want to dual build/target. Note that if you’ve auto provisioned any applications on your server, they won’t work after this, so switch those over to manual provisioning (set –RequiresReplication to $false on your pool) on the 2010 server.
The SDK is a bunch of files that installs under C:\Program Files\Microsoft UCMA 3.0\SDK, and really, the files you care about are in C:\Program Files\Microsoft UCMA 3.0\SDK\Core\Bin. There is no reason that these can’t coexist, but I’ll detail an optional step in a minute to keep things even cleaner for you.
Finally, UCMA 3 installs the Microsoft speech platform SDK version 10.2, and one of the voices. You may have installed more voices, in which case your add/remove programs will look something like this (yes, I installed all the voices… you never know when you might want to try Japanese TTS):
Now, the UCMA 4 SDK installs new versions of each of these components. The SDK files are actually the nicest, since they install to C:\Program Files\Microsoft UCMA 4.0\SDK, and can exist quite nicely beside the UCMA 3 versions. The core components can’t exist concurrently though, and that’s what causes the setup error on the SDK install. Version 11 of Microsoft.speech also can’t coexist with version 10.2, but in this case, the UCMA 4 install won’t fail if you have it on there already, so while you’ll get the new SDK files, your speech runtime will remain at 10.2. Interestingly enough, this doesn’t seem to matter.
The other thing to mention before getting to the results is .net. UCMA 3 was built against .net 3.5, and the supported scenarios all have UCMA apps targeting this version of the framework. UCMA 4 on the other hand, targets .net 4.5. Of course, it’s well documented that an uplevel .net application can use an assembly from an earlier framework, so is there any reason that your UCMA 3 app can’t use .net 4.5 too? As it turns out, no, there probably isn’t.
So with all that in mind, I tested just about every combination of the following:
- Lync Server Version: 2010 and 2013 (both with the latest updates)
- UCMA 3 and 4 assemblies
- OCSCore 3 installed, OCSCore 4 installed, and no OCSCore installed
- .net 3.5 and 4.5
- Microsoft.speech 10 and 11
And doing so gave me some really interesting results:
- Referencing the UCMA 3 libraries in a .net 4.5 project worked, but you need to make sure to set the <startup useLegacyV2RuntimeActivationPolicy=”true”> in your app.config file (standard practice for loading an old assembly in new .net). Note that I didn’t make any code changes in the app, but it did use the newer framework.
- Building a UCMA 4 application using the old (10.2) speech runtime worked just fine.
- Running a UCMA 3 application using the new (11.0) speech runtime worked just fine too, and actually seemed to have better TTS than the old version.
- If you’re manually provisioning, it doesn’t seem to matter whether OCSCore is installed or not.
- UCMA 4 apps run against Lync 2010. I didn’t expect that to work, but it does imply that there are little to no changes in the SIP layer. This is one case I’m definitely going to investigate further though, since the one thing I did not try is running this in a pure 2010 environment (not a hybrid), mostly because all of my dev lync environments are hybrids now. Interesting prospects though.
- I didn’t bother testing UCMA 4 with a lower level .net, but I don’t think it’d work.
Now, knowing all of that, the question is, what makes the most sense to release. My final configuration was a bit of a compromise: I created a build that generated 2 sets of binaries: one using UCMA 3, and one using UCMA 4, but both using .net 4.5 and speech 11. This means that clients will still be able to auto provision in production. As for how I set this up:
- Uninstall the 2010 core components
- Uninstall the 10.2 speech SDK and voices
- Install the UCMA 4 SDK
- Verify that the v11 speech SDK is installed, and install any additional voices you want.
- In your project, reference the appropriate version of Microsoft.RTC.Collaboration etc (3 or 4). NOTE-it’s important to remember to reference the specific version of the assembly, and not just the latest. I did this by explicitly setting the HintPath in the project file to the path of the DLLs rather than using the GAC copy (although you could also use the SpecificVersion flag in the reference)
- Update your project to .net 4.5 if you want (although you could also split out by .net version).
So far, this seems to have worked out well, and going into the next full QA round for our products we’ll be testing these configurations more thoroughly. I’m pretty impressed that these cases all worked out, but it would have been nice if it’d been easier to set this up. I can understand why two versions of OCSCore can’t exist on the same machine, but why not the speech runtime and voices?
In any case, this is what I managed to figure out through testing these cases out myself, and the end results are that this all looks really promising. Have any of you tried these configurations yourself, and if so, what does and doesn’t work? Any other things to watch out for?