Resolving required plugin assemblies problem
|
2011-04-05, 03:44 PM
Thanks for the info. Yeah, I did notice the stack contained no MusicSpot stuff so NPVR had nothing to work with.
My Projects
Programs Plugin [SIZE=2](retired) | Volume OSD Plugin (retired) | Documentation Wiki (retired)[/SIZE]
2011-04-05, 03:44 PM
I've found that if you have the plugin DLLS at ...\Program Files\NPVR\Plugins\Spotify\ and use a NextPVR.exe.config like below the dependencies are resolved and everything works!
Code: <?xml version="1.0" encoding="utf-8" ?>
My Projects
Programs Plugin [SIZE=2](retired) | Volume OSD Plugin (retired) | Documentation Wiki (retired)[/SIZE]
2011-04-23, 08:41 AM
Any chance somebody has come up with a creative solution to this in the interim? I'm not excited about putting the additional DLLs into the app directory either, and I can't feel really good about the nextpvr.exe.config edit either.
Is there any advantage to an "oi! You heard of this assembly?" interface a plugin can optionally implement that can be used to give additional hints to the search?
2011-04-23, 12:11 PM
I can probably do something more when I'm back home with my development machine. Worst case I can probably search all plugin directories looking for a named DLL.
2011-05-01, 11:08 PM
Sub, I'm using an NUtilities from the other thread on SetVisible (which I will also reopen when you are back) and I think you have started on this. For now I was just wondering if all these System.Windows.Forms belong there?
Code: 2011-05-01 18:46:49.677 [DEBUG][1] PluginResolveEventHandler: System.ResolveEventArgsMartin
2011-05-02, 12:05 AM
Yeah, its normal to have a fair few System.Windows.Forms entries in the stack trace.
2011-10-26, 05:30 PM
NPVR is failing to load a COM Interop assembly for my plugin. It is not finding it even though my assembly plugin appears in the stack (I thought it was supposed to look in the directories of plugins appearing in the stack)? My log is attached.
My Plugins: PhotoFilter, MusicMonkey, Windows Desktop Gadget
2011-10-26, 06:12 PM
Hi. I remember having these problems with gbpvr and later pvrx2.
One solution I found was in the constructor, or the initialise interface method (I can't remember what's used now), was to touch a method on each dll I needed to load. I made a getversion static method for this purpose that reported the internal version. Butthe method was unimportant, it was the action of doing something with each external dll that helped. As only in initialisation did gbpvr know where it was to resolve all the dlls. Then when they were accessed later on they were ready to use. Maybe a help maybe not. |
|
|
