As one of my consulting services, I develop WMS9 server plugins. If any of you has ever tried to develop a plugin for the Microsoft Media Server, you know that there is very little documentation for it, and very little support.
Recently, one of my clients setup a new Windows Server 2003 Enterprise system and tried to deploy our plugins to it. As you can imagine, the plugins did not work. While the other Micorosoft supplied plugins worked, my plugins reported error 0xc00d157d. You should try to google for that error code to see what you find.
The WMS log console shows that my plugins are reporting a binding error, yet the popup error message reports that it's a .NET runtime version error. Which path to choose?
For about a week, both me and my client's IT staff looked feverishly for a fix. Sometimes they blamed my code, sometimes we cursed Microsoft, and other times we looked to the heavens ala Google searching. Nothing seemed to work.
When I tried using the fusion log viewer, and with a little super-user configuration, I discovered that the binding error should have been our investigation path. As it turns out, the shipped WMS9 installation has Microsoft.WindowsMediaServices DLL version 9.1.1.3842. I knew this from long ago b/c this update has been around for a long time, and I've avoided it to preserve compatibility with existing systems. I didn't know that Microsoft had decided to put this new version into its latest service pack.
The WMS DLL version that I've been using for the past 2 years is 9.0.0.3693. This was the cutting edge DLL back in the day when we first started deploying the plugins. This was also the version that came with the Platform SDK for Multimedia/WindowsMediaServices9.
What really chaps me is that I pay good money to be an MSDN subscriber. You would think that Microsoft would want to tell the developer world that they are scrapping the old Platform SDK DLL in lieu of a new one that will break compatibility with existing plugins. Then again, you would also expect Microsoft to police their WMS newsgroups and actually answer questions that are more involved than the typical "how do I write a logging plugin." Neither is the case with WMS development.
Recently, one of my clients setup a new Windows Server 2003 Enterprise system and tried to deploy our plugins to it. As you can imagine, the plugins did not work. While the other Micorosoft supplied plugins worked, my plugins reported error 0xc00d157d. You should try to google for that error code to see what you find.
The WMS log console shows that my plugins are reporting a binding error, yet the popup error message reports that it's a .NET runtime version error. Which path to choose?
For about a week, both me and my client's IT staff looked feverishly for a fix. Sometimes they blamed my code, sometimes we cursed Microsoft, and other times we looked to the heavens ala Google searching. Nothing seemed to work.
When I tried using the fusion log viewer, and with a little super-user configuration, I discovered that the binding error should have been our investigation path. As it turns out, the shipped WMS9 installation has Microsoft.WindowsMediaServices DLL version 9.1.1.3842. I knew this from long ago b/c this update has been around for a long time, and I've avoided it to preserve compatibility with existing systems. I didn't know that Microsoft had decided to put this new version into its latest service pack.
The WMS DLL version that I've been using for the past 2 years is 9.0.0.3693. This was the cutting edge DLL back in the day when we first started deploying the plugins. This was also the version that came with the Platform SDK for Multimedia/WindowsMediaServices9.
What really chaps me is that I pay good money to be an MSDN subscriber. You would think that Microsoft would want to tell the developer world that they are scrapping the old Platform SDK DLL in lieu of a new one that will break compatibility with existing plugins. Then again, you would also expect Microsoft to police their WMS newsgroups and actually answer questions that are more involved than the typical "how do I write a logging plugin." Neither is the case with WMS development.