JTalton's picture

Windows OpenTK Installer

It would be nice to have a Windows OpenTK installer that registered the assemblies with the GAC and setup the proper registry keys such that Visual Studio would automatically find the assemblies and show them when adding assemblies to a project. Examples, documentation, and links could also be setup.

It would not be hard to do. I would suggest using the NSIS installer. I know what registry keys to setup. I just don't have the time.


Comment viewing options

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

I'm feel this is not a very good idea, at least not until OpenTK reaches stable status. My objections:

  1. Once you install a library in the GAC, its public API is set into stone. This is a considerable burden, and I don't think OpenTK is ready for this just yet.
  2. You'd have to maintain to separate installers (32bit/64bit) when the core library works in either version without issue.
  3. As far as I know NSIS, WIX and relevant technologies are windows-only. I don't really wish to maintain different installers per platform... :-)

I'm interested in opinions however - do you think OpenTK would benefit from an installer? How? Do you know of any installers that can handle multiple platforms (32/64bits, Linux/Windows/MacOS) without too much hassle?

JTalton's picture

It does make it nice when developing to have visual studio automatically find the assembly and list it when you add assembly references to your project.
The TaoFramework does this. I ended up making a library directory and setting the registry keys to that. Then I just copy assemblies into it and they show up in VS. It would be more of a convenience to developers who don't know how to set that up.

I do not know of any good cross platform installers. At one point I went looking but it seems like most projects uses NSIS for windows and another method for Linux/OSX.

nythrix's picture

Is it really a hot issue? I'm fine with the way things are now. Some extra clicking once in a couple of months isn't going to kill me.

PS: I never liked the windows registry idea-thing anyway.

Inertia's picture

Would definitely be nice to have a .Net based installer, especially if it was capable of pointing the user towards websites when bad or outdated drivers are detected (this would be sweet for both: deploying OpenTK itself for developers and deploying an app built with it to users). The requirement for drivers seems to be OpenTK's weakness, every single deployment problem I've faced so far could be fixed by updating the respective drivers. In my imaginary perfect world we will reach a point where driver issues are solved in a similar manner as the DirectX redistributable solves it.

FYI: this discussion is related to deployment, too.

objarni's picture

I would not want to install anything to the GAC nor fiddle with the registry. I've been a windows user / developer far too long to see any point in making things more complicated than they are. The registry is a bad smell (global state, anyone?) and I've never liked it at all. The GAC is global state too (Global Assembly Cache.. just the name is a bad smell).

So the current situation is fine with me.

JTalton: When I want a new project, I put OpenTK/other third party libs into a directory beside the project directory, in the same directory as the solution file:


This makes browsing to add references simple, and updating OpenTK and other libraries are simple (just unzip!). Another good point with this setup, is that the references are relative and not absolute, so I can actually move NewThing-folder to another location (even another computer!) without making any changes whatsoever. Just compile!

A simple way to start a new project is to just copy an old project and remove the Project-folder(s), keeping the ThirdParty folder.

I just want to minimize all "configuration, dependence"-issues and other non-fun-activities I do. And this is the best method I've seen so far under Windows.

my 2cc

djk's picture

I agree with objarni, we also use a ThirdParty folder for the same reasons.