BT

Mono Compatibility Report for Microsoft Biology Foundation

| by Jonathan Allen Follow 640 Followers on Aug 03, 2010. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Java would be a better choice for portable development by jean-simon Larochelle

Why on earth are people trying to use .NET for portable development will always puzzle me. Java is a more mature portable platform and is now really "Open Source" while Microsoft support for MONO is still ambiguous.
MONO is a heroic achievement and very useful if you are stuck and don't have any choice but to use .NET under Linux however I don't think that selecting .NET up front for portable development is a good idea.

Re: Java would be a better choice for portable development by Jonathan Allen

Considering that Microsoft Resaerch is the sponor for this project, I don't think that they are going to consider redoing everything in Java.

Re: Java would be a better choice for portable development by wang yi

If you want to use Biology Foundation, you have to use .NET. Microsoft cannot support Java.

Re: Re: Java would be a better choice for portable development by jean-simon Larochelle

Silly me. I started thinking about order project that try to use MONO for portable applications and I lost sight of the fact that MS was the sponsor. Sorry ...
I still think that if MS wants people to embrace MONO it will have to come out with a more solid stamp of approval than a simple statement with no legal value.

Re: Re: Java would be a better choice for portable development by Jonathan Allen

I hate to use the term FUD, but "fear, uncertainty, and doubt" is the best description of what we have right now. Even if Microsoft says, "No, you can only have what's covered by the standard." it would still be better than our current situation.

The .NET platform is just one way by 杨 振涛

I have been a Bioinformatics developer in the past three yeas .I use c,java and python(not perl) to process sequence data.Sometimes I do wanna write a self-used "Bioinformatics" library with c,java or python ! But you know we have to make the Biology problem not coding ...

Web service and open source lib are all very important in Bioinformatics/Genomics area!And there have been so many lib and portable tool like bioXXX and web services(SOAP and REST style) from NCBI,EBI ... with some useful access tools .

So,one language or platform or big foundation lib --- just one way! Microsoft is smart --- IBM too !

GetTickCount by Miguel de Icaza

GetTickCount is not handled because it is not part of .NET, it is instead a method that is being invoked from the host OS.

You *could* hack a tiny library that just provides this, but you will be much better off just writing a wrapper for this function that uses GetTickCount on Windows and uses DateTime.UtcNow.Ticks on Linux/OSX.

Our upcoming version of Mono (2.8) comes with Parallel Frameworks, and would love to have some beta testers for it.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss
BT