objarni's picture

Embed OpenTK.dll.config into OpenTK.dll

Project:The Open Toolkit library
Version:all versions
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed (invalid)
Description

There has been quite a lot of discussion about the possibility of embedding the .config-file into the OpenTK.dll main dll. If it is possible, I think it lies in line with the OpenTK philosophy "easy to deploy".


Comments

Comment viewing options

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

#1

A definite Contra here is the lost ability to manually change the .lib that is used by Mono without building again, in case the default lib is not desired. I recall this useful when working with OpenAL (not sure if this has been changed, but default driver was crap when we did the bindings), and I could imagine that this also beneficial for Linux/MacOS equivalents of glIntercept.

Just organize your directory structure to something like this:

.\bin\
.\data\
.\3rd Party\OpenTK.dll
.\3rd Party\OpenTK.dll.config
.\3rd Party\OpenTK license.txt

the Fiddler's picture

#2

It is possible to place OpenTK.dll.config under a specific hidden path (IIRC, ~/.mono/assemblies/OpenTK). OpenTK could conceptually check if this file exists on startup and create it automatically, if necessary. The user will still be able to customize it (for example to override the OpenGL/OpenAL implementation), but it will be hidden in normal use.

However, this is going to need some serious testing:

  • How does this interact with limited user accounts? (OpenTK runs under full trust, so this probably isn't an issue.)
  • What if this directory is located on a network share?
  • How does this impact startup time?

[OpenAL]
AFAIK, all major distros have switched to openal-soft, which works fine out of the box.

objarni's picture

#3

Would it be possible to use the built-in (embedded) config, which can be setup to point to reasonable default libraries under win/linux/mac, to be used by default (if there is no .config file beside the .dll that is) -- and use the .config beside the .dll if such a file exists?

the Fiddler's picture

#4

The config file cannot be embedded in the sense that it will be loaded from inside the dll - it has to lie on the disk.

That said, I think it already works as you describe (use local config first and fallback if it doesn't exist), but ultimately this is up to the runtime.

Inertia's picture

#5

Status:open» closed (invalid)