dll hell

[BobAtTorrey]

sub,
(While I'm not a developer, it seemed this post would be better here than in the support forum. Feel free to move it if you prefer it elsewhere.)

Today I had two problems because of dll conflicts. See here:
http://forums.nextpvr.com/showthread.php?t=18726 and
http://forums.nextpvr.com/showthread.php?t=18728

It seems to me that while the .Net runtime does its job of protecting the software with manifest checking for unintended dll's, that the structure we're using for the plugins and utilities walks us back into dll hell.
While the plugin dll's are in the \Plugins subfolder of gbpvr, many of them share dlls located in the gbpvr folder. Some of them assume that whatever is there is fine and they share it (which may give them manifest errors), while others install their own dlls, overwriting what gbpvr or some other plugin or utilities may have installed (giving something else the manifest error).
I'm not a developer so perhaps there are better or more clever ways to solve this, but one alternative would be for any plugin to explicitly install its dlls into its own sub-folder of the \Plugins folder. E.g., the XRecord dll would be in ..\Plugins, but any dlls or other support files it had to install would be in ..\Plugins\XRecord folder.
One advantage of that solution is that it requires no changes at all to gbpvr -- just advice and encouragement to the plugin writers to change to the new system. The other side of the coin, though is that it means there are no teeth in enforcement. An alternative would be to totally change the present system in a way where any plugin that doesn't comply with the new scheme won't be found and won't load.
Also, any non-plugin utilities (e.g., zaptools, GetTheaterListings, etc.) should also be constrained or contained in a similar fashion.

My purpose here isn't to argue for any particular solution -- only that this is begging to be solved.

Cheers .... Bob

[sub]

I'm not a developer so perhaps there are better or more clever ways to solve this, but one alternative would be for any plugin to explicitly install its dlls into its own sub-folder of the \Plugins folder. E.g., the XRecord dll would be in ..\Plugins, but any dlls or other support files it had to install would be in ..\Plugins\XRecord folder.

One advantage of that solution is that it requires no changes at all to gbpvr -- just advice and encouragement to the plugin writers to change to the new system. The other side of the coin, though is that it means there are no teeth in enforcement. An alternative would be to totally change the present system in a way where any plugin that doesn't comply with the new scheme won't be found and won't load.

Unfortunately this is not possible. Only one version of the DLL can be loaded into the single process.

Basically developers should stick to using the same versions of DLLs that I use. Like I have with ICSharpCode.SharpZipLib.dll, I'll stick with a specific version for as long as possible to minimise disruptions from changing version. We've been using this same version for a couple of years. I'll only change version if there is an important reason to change.

We will be using 1.0.30.1 of the SQLite DLL for the forseeable future.
We will be using 0.5.0.0 of ICSharpCode.SharpZipLib.dll for the forseeable future.

That said, if developers compile there plugins to not require a specific version, then they'd probably be able to handle an updated version of these components without having to be recompiled (depends if public interface has changed).

I have no vested interest in the other DLLs that are shared between plugins, but not used by the core GB-PVR application (for ID3 tags etc). The developers will need to come up with there own scheme for these.

[BobAtTorrey]

sub,
Thanks for the reply. I understand. But a couple points:

1. You suggest that developer's arrive at their own method. I think that indicates that you believe such a method is at least conceivable. Could you either offer them a hypothetical coordinating process or at least use your bully pulpit to hound them to devise such a process?

2. Perhaps your reaction is that it should be obvious to anyone developing that they must ensure dll compatibility. But, they're not all doing it. (Witness my two problems just today.) I quickly scanned the Developer section of the wiki and saw nothing on the topic. Perhaps something should be there and, because existing developers won't be reading that stuff again, perhaps you should also put out a reminder. (?)

3. The issue isn't just their stepping on gbpvr, but also their potentially stepping on each other. One plugin may coincidentally use a dll not used by gbpvr but used by another plugin. If it's left to just testing, that will seldom be caught unless all developers test their plugin/utility with all other possible software, and we know that won't happen. So there needs to be some sort of any-to-any coordination, not just any-to-gbpvr coordination.

Anyway, over the course of time I've used gbpvr I've probably been bitten by this about half a dozen times. It seems a shame to leave open this door of vulnerability.

Thanks for your consideration.

Cheers .... Bob

[sub]

1. You suggest that developer's arrive at their own method. I think that indicates that you believe such a method is at least conceivable. Could you either offer them a hypothetical coordinating process or at least use your bully pulpit to hound them to devise such a process?

I'm just suggesting a manual method like they agree among themselves what version to use.

2. Perhaps your reaction is that it should be obvious to anyone developing that they must ensure dll compatibility. But, they're not all doing it. (Witness my two problems just today.) I quickly scanned the Developer section of the wiki and saw nothing on the topic. Perhaps something should be there and, because existing developers won't be reading that stuff again, perhaps you should also put out a reminder. (?)

3. The issue isn't just their stepping on gbpvr, but also their potentially stepping on each other. One plugin may coincidentally use a dll not used by gbpvr but used by another plugin. If it's left to just testing, that will seldom be caught unless all developers test their plugin/utility with all other possible software, and we know that won't happen. So there needs to be some sort of any-to-any coordination, not just any-to-gbpvr coordination.

I do understand your concern, but the reality is that it has not presented many problems over the last couple of years of GB-PVR, so not really something I want to invest any time in.

For now, I'll have to give a pretty selfish answer - developers should use the versions of the DLLs that I'm using. If I notice a plugin overwriting one of GB-PVRs DLLs, I'll point it out to the developer and ask them to change the version they're using. Most developers are pretty receptive.