This project is read-only.

Source Code Project structure changes

Mar 28, 2013 at 5:17 PM
Edited Apr 8, 2013 at 11:27 PM
Hi all,

.NET Bio 1.1 is right around the corner and there are several source project structure changes I'd like to propose to make it easier for people to take the source and build the project on their own.

First, I'd like to see the HPC projects into their own solution with binary dependencies to .NET Bio. I doubt many people use this part of the system, and while it is useful, it makes it much harder to build .NET Bio from source because of the additional dependencies required to build this aspect (namely the HPC SDK bits).

Given the dubious future of Silverlight, I'd like to remove the Silverlight projects from the tree - the core DLL and unit tests associated with it. They would also have a dedicated solution which people could use to specifically build/edit that version of the library.

FInally, I think we should move to Visual Studio 2012 - they are about to release SP2 so it's stable, and right now I'm noticing the static code analysis and unit tests don't run completely in that environment.

Just to be clear, I not proposing we remove the projects from source control - just separate them so that we have multiple solution files (.sln) and you could use a BioCore.sln to just build .NET Bio and algorithm DLLs with unit tests, SlBio.sln to build the Silverlight version, HpcBio.sln to build HPC binaries and tools, etc.

What does everyone think?

Thanks!
mark
Mar 28, 2013 at 5:41 PM
I wanted to chime in and say that I wanted to strongly endorse all of the proposed changes!!!

If I can make one other addition to the list of changes as well. I have been proselytizing C# amongst biologists for awhile now. The discussion usually gets to a point of "well, that language sounds great, those features would definitely make my coding cleaner and easier, but myself and everyone I know uses a mac to write code and a linux cluster to run it, and since C# is exclusively microsoft, it's a non-starter" and so another convert is lost to java/c++/python. However, both the mono framework, and the mono platform are pretty mature at this point, and I might suggest that we have a build switch specifically to target mono, that way we aren't missing the 90% of computational biologists who own macs (at least judging from Harvard/MGH/Broad).

I believe this would require only a few changes. First, we make the aforementioned changes to remove the silverlight and HPC bindings, which removes a large barrier to use even on windows (there are many HPC SDKs one could download, and the correct one isn't obvious) and the majority of incompatibilities with mono. With these separated out, I believe the majority of the code base except for a few bits that help with extensibility are directly compatible with mono. I noticed that in the silverlight toolkit source they just use compilation flags to specify silverlight versus wpf (making small adjustments for each but otherwise having the same code), and I think we could do the same in the few places where a feature is MS specific and doesn't overlap well with mono. I think these changes would make the MS .NET version of the code a "first class" build with unit-tests etc. while allowing mono to be available for those who want/need to scale their code on linux clusters, with the usual caveat emptor that people have come to expect with anything *nix.
Mar 28, 2013 at 5:49 PM
This sounds great - I know that Leonardo (on another thread) was asking about VS 2012 integration, and now 2012 has been released for some time, a transition makes sense.

Regarding Silverlight - I agree in principle to its removal because I think that a simpler project is a better project, my concern is whether we have anyone relying on it. Jim Hogan's team has done a lot of Silverlight visualization in genomics, so I'd like to know from him whether this would generate problems.

Regarding HPC - moving these into a separate solution would alos make a lot of sense - Jon Zhang at Cornell may have a view on this, because I know the BioHPC system he is developing uses Windows HPC.

Mono - do we know anything about the future of Mono?

Simon
Mar 28, 2013 at 5:54 PM

Regarding Silverlight - I agree in principle to its removal because I think that a simpler project is a better project, my concern is whether we have anyone relying on it. Jim Hogan's team has done a lot of Silverlight visualization in genomics, so I'd like to know from him whether this would generate problems.

Keep in mind that it would still be there - just not built with the main solution. Today it's part of the primary solution - even though it's a separate project/DLL and has no dependencies on the other projects at all. What I'm suggesting is a restructuring of the project, not a removal of code. If Jim and team wanted to continue to develop/rely on it there would be no problem. It's actually behind now anyway since it was ported in the 1.0 timeframe so all he changes made to 1.01 and 1.02 aren't in the Silverlight branch anyway.
Mono - do we know anything about the future of Mono?

As far as I can tell, it's a thriving community. The Mono guys (Xamarin) joke that they love C# more than Microsoft does since they are far more responsive to the community! :-)

ms
Mar 29, 2013 at 5:15 PM
Okay then, if the Silverlight stuff will be there, I see no objection. I agree its use should be deprecated at this stage, though.

MONO - okay. It would depend on how long support would take, buit it would obviously be great to have. My concern is that we will very shortly have enough changes for the next release, in fact so many I will suggest it is the 1.1 release instead of 1.01, possibly these changes coudl fit into 1.2 instead?