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 <i><b>up to date</b><i> before the Genomics Application can be installed (which is a good policy for security and other reasons). <b>DirectX Runtime Components Installation</b> 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 on 11/28/2006 12:25 PM ()
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 on 11/29/2006 3:12 AM ()
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 on 11/29/2006 10:04 AM ()
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 on 11/27/2006 4:59 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us
Built with WebSharper