Desmond File

Blog archive

Microsoft Interoperability Mojo

Back in February 2008, Microsoft announced with a flourish that it was committing to improving the interoperability and openness of its products, technologies and processes. The published document set out four guiding principles for Microsoft's approach to interoperability: Open connections to Microsoft products, support for standards, data portability, and open engagement.

Microsoft faced a skeptical audience at the time -- not the least of whom were the regulators in the European Commission, who days later levied a $1.3 billion fine against Redmond for failure to comply with earlier findings. It was easy to be skeptical about the initial interoperability announcement. But since then, we've seen a steady stream of products, initiatives and announcements pointing to an ever more open and pragmatic Microsoft.

The latest activities come in the form of Microsoft's purchase of SourceGear's Teamprise Client Suite, an Eclipse plug-in that integrates the Team Provider menu into the Eclipse IDE to enable source control, work-item tracking and build and reporting. The acquisition means that Eclipse developers wanting to tap Microsoft's native TFS source control and collaboration resources can do so from the supported Teamprise client. In short, the acquisition extends Microsoft's ALM footprint in mixed platform development environment.

Perhaps more significant was the announcement this week that Novell had released a plug-in for Visual Studio, called Mono Tools for Visual Studio, that enables Windows-based .NET developers to create cross-platform, Mono-compatible applications directly within the Visual Studio 2008 (and later, 2010) IDE. A component of the wide-ranging Mono Project bank-rolled by Novell and headed up by Miguel de Icaza, Mono Tools could go a long way toward making cross-platform .NET development a reality.

Brian Goldfarb, director of Web/UX Platform and Tools at Microsoft, says Microsoft recognizes that many IT environments have mixed infrastructures. "We’ve intensified our efforts to make our products more interoperable, as well as to provide greater choice and opportunities for developers who use a mix of Microsoft and open source technologies."

Goldfarb points to efforts like the Windows Azure SDK for PHP, the toolkit for PHP with ADO.NET Data Services, the Restlet Extension for ADO.NET Data Services that bridge Java and .NET, and most recently the 1.0 release of the Eclipse plug-in for Silverlight developed by Soyatec.

Neither of the recent announcements are earth-shaking, and no one would argue that Microsoft is working against its own best interests with its interoperability efforts. But the trend endures. More developers not aligned with .NET are gaining access to elements of the .NET development stack.

Posted by Michael Desmond on 11/13/2009


comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube