4.0k
views4
comments

Request for advice on shipping an F# Genome Viewer

A friend of mine, Darren Platt, has been writing a genome viewer in F#. Here's some things he had to say, followed by a question which I thought I'd open up to the forums. It's really a very cool app and I'm thrilled that Darren's using F# for such great things.

Hey just got my viewer up and running with mouse interaction thanks for some of your code snippets. It's the fastest genome assembly viewer I've ever seen and only 500 lines of F#. It's really an incredible language Don, you've done a really good job.

Here's the question. I've taken a stab at answering the question below, but if there are people who are more familiar with DirectX, installers, ClickOnce etc. etc. then please chime in.

Do you have any thoughts/experi with distributing F# binaries. I would actually like to start giving this to people to use (it's already incredibly useful) and there is a reasonable stack of dependencies (other .net dlls eg. database connector, FSharp libraries, dotnet installation, directX). Is there a sensible path for doing this or should I just ask my users to install all of those things first into standard places (the random and varying import parts for different versions of directX are annoying for example). I'll send you the demo once I get over this hurdle, it loses a bit in the screenshot, but basically with very fast and smooth zooming/scrolling it's really pleasant to use. My current tool for doing is a python CGI script that produces nice images but which is completely non-interactive and very slow.

Darren - given the DirectX dependency I would do this

Note the version of the DirectX Runtime (not SDK) that you're using
Statically link the F# code using --standalone. You will have to add a reference to some other assemblies that form part of the transitive closure of assemblies. Jon Harrop just did this for his DirectX raytracer. This will give you a binary ~1MB - you can make this much smaller by running the tool "iltrim.exe" in the latest distributions (not yet publicly released, but I know you have a copy I sent you for testing)
Tell your users to install .NET 2.0 and the given version of the DX runtime (give them links to the MS downloads). If you depend on a non-standard database connector then probably just ship that DLL alongside your binary.

That should give you an app people can run. Next:

Once you're satisfied you know how the dependencies work out on a clean machine (Virtual PC is a great tool for this), you might build an installer with Visual Studio 2005, or if you like more control then I recommend WiX.
There are ways to ensure that your app is "ClickOnce", i.e. it will direct users through to Microsoft and other sites for the relevant components. I haven't shipped an app like this but I'm sure others on the site know lots about that.

don

Let's take this part by part.

The --standalone advice as listed above is the F# preferred method for packaging of assemblies for the target machine (independent of installer choice).

Windows Installer or ClickOnce

In general, this page has useful guidelines when determining a distribution strategy where Windows Installer and/or ClickOnce are under consideration.

Note that ClickOnce is sandboxed and Single-User Centric. If a target machine is shared by more than one user, the software to be considered for installation MUST be installed by each user separately.

Note that ClickOnce does NOT require FULL TRUST for installation, i.e. administrative access is NOT required.

Note that ClickOnce does require the application be compiled with FULL TRUST rights on the assembly (this is a known problem and there is plenty of further information on this).

I personally think that if you are doing an application that is volatile in updates, i.e. high frequency, ClickOnce is a great approach. If many of the target machines are not .NET/DX/GenomeApp ready, the initial installation will be a little painful. If the application is not volatile in updates, then Windows Installer is likely a better choice. With Windows Installer, the application can be made available on a web server as needed after successful builds of the installable application target. WiX (free) and InstallShield (costs money) are two alternative platforms that are Windows Installer compatible and behave well at installation time.

.NET Runtime Components Initial Installation

.NET is now pervasive in many settings. The following are the base versions that are shipped:

Windows 2000 (and earlier) - none
Windows XP (all service packs) - v1.1
Windows 2003 Server (all editions) - v1.1
Windows Vista - v3.0

Microsoft Update will automatically attempt to update the machine to .NET v2.0 for 2000/XP/2003. If the target machines are updated regularly and have .NET v2.0, then this is not an issue. A likely policy/scenario would be to require the target machines to be up to date before the Genomics Application can be installed (which is a good policy for security and other reasons). DirectX Runtime Components Installation Currently, F# supports the #I (-I) and #R (-R) directives (compile flags) for the inclusion of an assembly. The target for DirectX assemblies for managed code are OS version dependent. Also given the volatility in the release schedule of builds of DirectX RTCs, there are many versions of working DX RTCs in the wild. This makes it difficult to both find and bind (in F#) to the appropriate dlls at runtime. The recommended approach for DX (3D or otherwise) is to reference the DX assembly in the GAC at design time. @Don - Is there a way to reference a GAC assembly at design/compile time in F#? This would alleviate this problem. Absent a GAC approach in F# at compile time, I don't have a clear answer on this topic (yet). I'd be happy to try to answer other specific questions. ---O p.s. I have a *few* VPCs where I test applications (including installation testing). If there are targets that you have that you are uncertain will work, let me know and I may be able to provide direct assistance.

By optionsScalper on 11/28/2006 12:25 PM (permalink)

Although most of what optionsScalper says is correct there is one small part I disagree with:

Currently, F# supports the #I (-I) and #R (-R) directives (compile flags) for the inclusion of an assembly. The target for DirectX assemblies for managed code are OS version dependent. Also given the volatility in the release schedule of builds of DirectX RTCs, there are many versions of working DX RTCs in the wild. This makes it difficult to both find and bind (in F#) to the appropriate dlls at runtime. The recommended approach for DX (3D or otherwise) is to reference the DX assembly in the GAC at design time.
@Don - Is there a way to reference a GAC assembly at design/compile time in F#? This would alleviate this problem.
Absent a GAC approach in F# at compile time, I don't have a clear answer on this topic (yet).

It does matter where the assembly is that you reference at compile time, the .NET loader will go though the same process to try and fine it. Roughtly speacking first it checks the GAC for the exact version then if it does not find it there it checks the appbase directory, usally the directory that the application was executed from. In the appbase directory an exact version match is not required, as long as the major and minor version number is the same then this is good enough. You can change this with version policy in either machine.config or the app.config. This is explain in more detail in this artical:
[link:www.awprofessional.com]

I know this from bitter experince I've see a lot of problems with developers who have left old versions of the dll that they are developing in the gac and then wonder why the changes they made to the code have not taken effect.

You can down load the directX 9.0c redistributable here at the link below [1]. I believe this will be a merge module (.msm) this can be easly added to an msi built with either wix or visual studio. This will ensure the users get the runtime you want if it not already installed but it will add quite a lot of bloat to your msi, you could be better off just telling them that they need to install it. If you use wix, it should be feasiable to detect whether it is already present and block the installation if it is not, but I'm not sure exactly how to do this, but there is a link to a blog post that has some discusion on detecting software installed using wix here [2].[1][link:www.microsoft.com]
[2][link:blogs.msdn.com]

There is also a resdiributable for .NET 2.0, but as optionsScalper says this is pushed out to users via windows update, so probably isn't worth inculding:
[link:www.microsoft.com]

By Robert on 11/29/2006 3:12 AM (permalink)

Robert,

Thanks for that point. I was too vague in my description of the DX RTCs and assembly resolution. Consider the following scenario:

I build a target F# application on Windows XP SP2 with DX v9.02.2904 and .NET 2.0. In the F# code I place the following lines:

#I @"C:\WINDOWS\Microsoft.NET\Managed DirectX\v9.02.2904";; 
#r @"Microsoft.DirectX.dll";;
#r @"Microsoft.DirectX.Direct3D.dll" ;;
#r @"Microsoft.DirectX.Direct3Dx.dll" ;;

After building the project and deploying it on a target machine, the application SHOULD run fine, assuming that .NET 2.0 and DX 9.02.2904 are installed on that machine. But when DX 9.02.2904 is installed on Windows 2000, it has a different install point, i.e. it is not located in C:\WINDOWS\Microsoft.NET\Managed DirectX\v9.02.2904. When the above target attempts to add this path using #I, the above dlls remain unresolved. So the application builds fine, the installation appears complete, the appropriate .NET and DX RTCs are installed, but the application is unable to run due to the above unresolved pathing issue. If the DX assemblies were GACified, the pathing would not be an issue. That Sells/Box link on the CLR Loader is a great article (along with the other section of that article).

Sorry for the confusion.

---O

By optionsScalper on 11/29/2006 10:04 AM (permalink)

Don is referring to my 100-line DirectX teapot demo rather than my ray tracer (that only uses WinForms and bitmaps).

I just compiled with --target-winexe --standalone and told people to install both DirectX and .NET. Obviously I'm not providing tier 3 support for a demo but users seem happy so far. I've tried the program on a couple of other computers and you can just download the EXE and it works.

I haven't tried creating an installer yet but I'd like to know how you get on.

Best of luck!

Cheers,
Jon.

By jdh30 on 11/27/2006 4:59 AM (permalink)

Topic tags

Built with WebSharper

Home

Answers

Events

Courses

Groups and Conferences

Blogs

Jobs

Developers

Topic tags