Home » Project database » Core » The Open Toolkit library » Issues
the Fiddler's picture

[OpenTK] Create MSI packages for Windows (help wanted)

Posted Friday, 20 November, 2009 - 11:13 by the Fiddler
Project:The Open Toolkit library
Version:1.x-dev
Component:Miscellaneous
Category:task
Priority:minor
Assigned:Unassigned
Status:open
Description

While zip releases are good enough in most cases, it would be beneficial to provide msi packages for Windows users.

Advantages:

  1. we can install OpenTK into the GAC
  2. we can provide project templates to simplify development with OpenTK
  3. we can (potentially) integrate OpenTK documentation with the VS help viewer or MonoDevelop MonoDoc

If possible, package creation should be integrated into the build process.

WIX is an open-source tool that can create such packages. Anyone willing to help with this?


Comments

« first‹ previous12

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
charles's picture

#11

Posted Sunday, 7 February, 2010 - 23:46 by charles

Hi Fiddler,
I've got Doxygen running here too and agree that it's significantly faster, I'll look into using it when building the msi. However I noticed the doc target currently builds the documentation rather than just creating a DoxyGen file which is fine. However should the msi target do the same and create the installer, using MSBuild internally, or just create the MSBuild file which can then be used to build the installer, project, or documentation?

I've also been giving some thought to versioning and this is what I've come up with so far:

  1. We create a new 'version' file which contains the current version, this is located in the root folder.
  2. The MSBuild script reads this file and extracts the current version.
  3. The MSBuild script updates all AssemblyInfo.cs files with the current version, along with any other required files.
  4. The MSBuild script builds OpenTK, using the vs2008 target.
  5. The MSBuild script builds Documentation, using doxygen.
  6. The MSBuild script builds the Installer.

Note that this will ofcourse change a number of files that are under source control. This could be considered a little odd since we just want to build the installer from the current source. Another option might be to extract the version update step into it's own OpenTK Build target so that we can make sure we don't miss anything. What do you think?

Also I probably won't be in touch for a little while as I'm moving to Brisbane (AUS), yep it's been pretty hectic over the last few weeks, but hey thats life!

the Fiddler's picture

#12

Posted Wednesday, 24 March, 2010 - 17:12 by the Fiddler
Version:0.9.x-dev» 1.x-dev
Priority:normal» minor
Status:in progress» open

I have spent some time working on the msi installer but didn't manage to get this to work as I would like. The main issue is that we need a way to collect the binaries, source code and documentation without hardcoding paths and locations beforehand. The documentation mentioned that heat.exe could create an initial file list, but the expectation was that the list would be managed by hand after that (which is not what we want). Trying to rerun heat.exe would modify GUIDs, causing problems on upgrades.

I expect to revisit this issue in the future but, for now, I have created a simple NSIS-based installer. The build process is based on Build.exe and works like this:

  1. Generate project files / solutions.
  2. Build OpenTK.sln using Microsoft BuildEngine / BuildFramework. These are the .Net APIs msbuild is presumably based on. Starting with Mono 2.6, their implementation is robust enough to build OpenTK there.
  3. Build html documentation using doxygen.
  4. Build pdf documentation using latex.
  5. Regenerate the project files / solutions to ensure references to OpenTK.dll/OpenTK.dll.config are correct (there are better ways to handle but they wouldn't be ready in time for opentk-1.0).
  6. Build nsis installer using makensis.

There is no automatic handling of build numbers right now: Build.exe either asks the user or uses its own build number. This should be fixed in the future (likely updating/generating AssemblyInfo files during the bootstrapping process.)

Finally, NSIS has a one significant advantage over MSI: it is buildable on Linux. While I don't consider MSI a high priority right now, I certainly wouldn't object to patches adding that capability.

« first‹ previous12