Microsoft Biology Foundation describes itself as “a language-neutral bioinformatics toolkit built as an extension to the Microsoft .NET Framework, initially aimed at the area of Genomics research. Currently, it implements a range of parsers for common bioinformatics file formats; a range of algorithms for manipulating DNA, RNA, and protein sequences; and a set of connectors to biological web services such as NCBI BLAST.”
While Microsoft Research has made a blanket pledge to make their tools compatible with third-party vendors, staffing problems have interfered with the plan to do the refactoring needed to support Silverlight and Mono. Michael Zyskowski writes,
During our development of MBF, we decided to take a hard dependency on .NET 4.0, specifically the use of Parallel Extensions to enable more effective use of multi-core machines when performing sequence alignment and/or assembly. The capabilities of SL4 were not as well understood, and in effect we elected to maximize the benefit of the .NET 4 feature set over the provision of a framework targeting the subset of features available in Mono or SL4. We had every intention of revisiting compat for SL4 (as well as the .NET 4.0 Client Profile subset) via a refactor of the framework into a set assemblies targeting each version for MBF v1.
Unfortunately, we lost some key folks during the past few months and had to make some tough trade offs. One of these was the decision to post-pone the effort to re-factor the library into a Client Profile, Silverlight4 and full .NET 4.0 set of assemblies. This is clearly a first order of business for us after we release the final v1 release of MBF in June. However, we would welcome the community to investigate, prototype and even submit code to be considered that would achieve this result. The beauty of this project is that we hope to enable the community to advance the platform in areas that it deems most important, without having to rely upon Microsoft to do the work.
While extensive testing is needed, the list of compatibility problems detected by the Mono Migration Analyzer is quite minimal. The specific problems are:
- In two places there is a call to CredentialCache.DefaultCredentials. This is only used for NTLM, negotiate, and Kerberos-based authentication, so it can be ignored when those aren’t being used. But if you need them, there isn’t really any good workaround.
- There are four calls to Assembly.GetName(Boolean), which has the rather uninteresting ability to change the Assembly.CodeBase when an assembly is shadow-copied.
- Another security related feature being used is HttpTransportSecurity.ClientCredentialType from Windows Communication Foundation. Since this is just used for calling web services via WCF, an alternate web service layer could be used until Mono catches up.
- In one of the add-in packages there are a couple of calls to the Win32 function GetTickCount. This merely returns the number of seconds since the system was last started, so it is rather odd that Mono doesn’t already have a translation layer for the Linux and OS X equivalents.
All in all there isn’t that much work for a Mono-equivalent. Unfortunately a Silverlight version won’t be so easy, as that is much farther from .NET 4.0 and has no interest in eventually reaching full compatibility.