Plugin loaded but doesn't get any calls (LB 13.15)

[GreenF]

Hey everyone,

I'm trying to write a plugin to LB and I've looked at the plugin examples.
I wrote a VERY basic plugin just to see that it works (IGameMenuItemPlugin that practically does nothing besides writing logs that it is loaded).
I should point out that the examples did not discuss about the manifest.json, so I took one from existing plugins and updated the GUID (and placed "null" for tags).

The problem is that I can't get it to work. I see the plugin in the "plugin manager", and the DLL is loaded into LaunchBox, but none of the properties nor methods are being called (let alone actually see a menu item...).

Can anyone help with that? Maybe something changed since older versions (the examples are quite old)?

Any assistance would be great 🙂

 

Thanks!

[JoeViking245]

22 minutes ago, GreenF said:

Can anyone help with that? Maybe something changed since older versions (the examples are quite old)?

With the IGameMenuItemPlugin interface, you should be able to see the menu item when you select a game and then right-click it.  If you can't see it there, then your methods won't do anything.  Even if GetIsValidForGame(IGame selectedGame) returns false, the menu item should still show (but greyed out).

Aside from the manifest file (which only allows you to see it in the Plugins Manager), nothing's changed in a long time for the IGameMenuItemPlugin interface.

Can you show us your IGameMenuItemPlugin class .cs file?

[GreenF]

sure. attaching.

As you'll see in the code, I've also tried to write to OutputDebugString, just to make sure if anything happens here.
Also, notice I'm targeting to .Net 8 and OS Version 7.

Thanks for your help!
Hopefully I just have a silly bug.

main.cs

Edited July 17 by GreenF

[JoeViking245]

1 hour ago, GreenF said:

sure. attaching.

As you'll see in the code, I've also tried to write to OutputDebugString, just to make sure if anything happens here.
Also, notice I'm targeting to .Net 8 and OS Version 7.

Thanks for your help!
Hopefully I just have a silly bug.

Start by targeting .NET 6.0

To send something to the debug output screen, you can use Debug.WriteLine("We've made it to this point");   Note this will only show in Visual Studio's output window when debugging via Visual Studio.

For classes that use a plugin interface, you don't need a class method.

Here's the class inside your namespace.  Some parts simplified and not too many Debug lines.

internal class main : IGameMenuItemPlugin
{
    public bool SupportsMultipleGames => true;  //supports multiple games

    public string Caption => "TEST ME";   //sets the display name for the plugin

    public System.Drawing.Image IconImage => null;  //no icon for this project

    public bool ShowInLaunchBox => true;  //lets the project show in launchbox

    public bool ShowInBigBox => false;    //disables the program in bigbox

    public bool GetIsValidForGame(IGame selectedGame)
    {
        //valid for single selected game
        return true;
    }

    public bool GetIsValidForGames(IGame[] selectedGames)
    {
        //valid for multiple selected games
        return true;
    }

    public void OnSelected(IGame selectedGame)
    {
        //runs the program
        MessageBox.Show("OnSelected");
        Debug.WriteLine("**************** OnSelected() IGame");
    }

    public void OnSelected(IGame[] selectedGames)
    {
        //runs the program
        MessageBox.Show("OnSelected[]");
        Debug.WriteLine("**************** OnSelected() IGame[]");
    }
}

[GreenF]

Using .Net 6 produces a conflict warning as Unbroken.LaunchBox.Plugins.dll has compiled with .Net 7, so I'm trying .Net 7.

Also, about the Debug.WriteLine(), I used OutputDebugView to see the logs in DebugView so I don't need to attach VS to LB. But just for the sake of it, I removed all the logs completely and check if I see a menu item.

I also tried to "run as administrator".

Also tried bringing the dependencies to the same plugin library (i.e. Unbroken.LaunchBox.Plugins.dll)

None worked.

Taking a wild guess here, I see all the "stock" plugins have a naming convention (for obvious reasons), like "Unbroken.LaunchBox.Windows.RetroArch.dll". In my case, it's just "testplugin.dll". I know it's far-fetched, especially as the plugin has been loaded (verified with process explorer), but.... maybe?!

I'll check in LB if there are some extra-logs I can pull out.

 

[JoeViking245]

5 minutes ago, GreenF said:

Using .Net 6 produces a conflict warning as Unbroken.LaunchBox.Plugins.dll has compiled with .Net 7, so I'm trying .Net 7.

What's the conflict warning it gives?  And if it's just a warning and it still compiles, you should be fine.  But as far as I know, LaunchBox/BigBox [still] uses .NET 6.0.  So not sure where you saw .NET 7.  The only warning I get during compile is related to Microsoft.Win32.SystemEvents.  Adding a reference the one located in the /Core/ subfolder takes care of that.  But again, it's just a warning and still compiles and runs without its reference.

The 3 references I use (all located in the /Core/ folder) are:

• Unbroken.LaunchBox.Plugins
• Microsoft.Win32.SystemEvents
• System.Drawing.Common

 

17 minutes ago, GreenF said:

I also tried to "run as administrator".

Ya, don't do that.  LaunchBox should never need to be ran as admin.  Never.

 

18 minutes ago, GreenF said:

Also tried bringing the dependencies to the same plugin library (i.e. Unbroken.LaunchBox.Plugins.dll)

Doesn't hurt anything.  I don't think.  But I do know it's not necessary.  At least not dependency files already existing in the /Core/ folder.

 

19 minutes ago, GreenF said:

Taking a wild guess here, I see all the "stock" plugins have a naming convention (for obvious reasons), like "Unbroken.LaunchBox.Windows.RetroArch.dll". In my case, it's just "testplugin.dll". I know it's far-fetched, especially as the plugin has been loaded (verified with process explorer), but.... maybe?!

A namespace by any other name is just a namespace.  

I suggest not worrying about seeing in the Plugin Manager for now (i.e. the manifest.json file) and just work on getting it to show up in the right-click menu.  The rest will fall into place later.

 

36 minutes ago, GreenF said:

I'll check in LB if there are some extra-logs I can pull out.

Not sure what extra logs there may be.  Also not familiar with the 'DebugView' (maybe I'm missing out on something good).  I usually just have VS start LaunchBox as a Startup Project after compiling and copying the file ("testplugin.dll") to the plugin folder.  If you do this, just be sure to point to the LaunchBox.exe that's in the /Core/ folder.  Not the one in the root folder.

[GreenF]

1 hour ago, JoeViking245 said:

What's the conflict warning it gives?  And if it's just a warning and it still compiles, you should be fine.  But as far as I know, LaunchBox/BigBox [still] uses .NET 6.0.  So not sure where you saw .NET 7.  The only warning I get during compile is related to Microsoft.Win32.SystemEvents.  Adding a reference the one located in the /Core/ subfolder takes care of that.  But again, it's just a warning and still compiles and runs without its reference.

Sorry, it wasn't a warning but an error:

Quote

warning MSB3277: Found conflicts between different versions of "System.Drawing.Common" that could not be resolved.
warning MSB3277: There was a conflict between "System.Drawing.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" and "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51".
warning MSB3277:     "System.Drawing.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was chosen because it was primary and "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" was not.
warning MSB3277:     References which depend on "System.Drawing.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.32\ref\net6.0\System.Drawing.Common.dll].
warning MSB3277:         C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.32\ref\net6.0\System.Drawing.Common.dll
warning MSB3277:           Project file item includes which caused reference "C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.32\ref\net6.0\System.Drawing.Common.dll".
warning MSB3277:             C:\Program Files\dotnet\packs\Microsoft.WindowsDesktop.App.Ref\6.0.32\ref/net6.0/System.Drawing.Common.dll
warning MSB3277:     References which depend on or have been unified to "System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" [].
warning MSB3277:         C:\Users\green\LaunchBox\Core\Unbroken.LaunchBox.Plugins.dll
warning MSB3277:           Project file item includes which caused reference "C:\Users\green\LaunchBox\Core\Unbroken.LaunchBox.Plugins.dll".
warning MSB3277:             Unbroken.LaunchBox.Plugins
1>CSC : error CS1705: Assembly 'Unbroken.LaunchBox.Plugins' with identity 'Unbroken.LaunchBox.Plugins, Version=13.15.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Drawing.Common, Version=7.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' which has a higher version than referenced assembly 'System.Drawing.Common' with identity 'System.Drawing.Common, Version=6.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'

The warning states that there is a conflict between:

There was a conflict between "System.Drawing.Common, Version=6.0.0.0.... " (used by me, choosing .Net 6) and "System.Drawing.Common, Version=7.0.0.0....."

in the error, CSC says: "Assembly 'Unbroken.LaunchBox.Plugins'  ..... uses 'System.Drawing.Common, Version=7.0.0.0....' which has a higher version than referenced assembly 'System.Drawing.Common' ... '... Version=6.0.0.0...'.

Basically, when I'm compiling with .Net 6, I am using System.Drawing.Common v6, which conflicts with 'Unbroken.LaunchBox.Plugins' that uses v7 (thus, as far as I understand, Unbroken.LaunchBox.Plugins compiled with .Net 7).

Switching to .Net 7 resolves the error.

 

1 hour ago, JoeViking245 said:

Ya, don't do that.  LaunchBox should never need to be ran as admin.  Never.

Got it 🙂

 

1 hour ago, JoeViking245 said:

Not sure what extra logs there may be.  Also not familiar with the 'DebugView' (maybe I'm missing out on something good).  I usually just have VS start LaunchBox as a Startup Project after compiling and copying the file ("testplugin.dll") to the plugin folder.  If you do this, just be sure to point to the LaunchBox.exe that's in the /Core/ folder.  Not the one in the root folder.

Yeah, didn't see much over there...

Btw, DebugView (DebugView - Sysinternals | Microsoft Learn) is a Microsoft tool (originated from Sysinternals) so see logs from the whole system, including system applications and drivers. It is quite noisy (but you can filter and color using patterns, that's why I used all the "++++" symbols in the log), but it is an excellent tool when there's no console and you want to see things in real-time (especially when you write system applications or drivers).

 

Honestly, I am a bit stuck. Maybe it is something in my environment so later on I'll try in a clean environment (i.e. a virtual machine).

UPDATE: Didn't work in a virtual machine either.

Obviously at the end it would be something silly we should've thought about right from the beginning 🙂 .

 

If you have any other ideas, I'd be more than happy!

Thanks again for all the help.

Edited July 17 by GreenF

[JoeViking245]

3 hours ago, GreenF said:

Basically, when I'm compiling with .Net 6, I am using System.Drawing.Common v6, which conflicts with 'Unbroken.LaunchBox.Plugins' that uses v7 (thus, as far as I understand, Unbroken.LaunchBox.Plugins compiled with .Net 7).

Switching to .Net 7 resolves the error.

Switch the plugin back to .NET 6.0.  I guess the only thing more I can say about this is "trust me". 

Remove any and all referenced assemblies you have.  Including and especially any NuGet packages.  Then add only the 3 assembly references I showed above. (again, Browse to and get them from the /Core/ folder) 

Doing so WILL eliminate the System.Common.,Drawing warning.    Wait for it...... w a i t   f o r   i t . . . . . . .  "I Promise!"  😎

[GreenF]

Okay, Starting from scratch.

I created a whole new solution, added .net 6 class library, referenced to Microsoft.Win32.SystemEvents, System.Drawing.Common and Unbroken.LaunchBox.Plugins from "core\" dir.

Compiled (I must add - without warnings!)

Copied to "LaunchBox\Plugins\TestPlugin\"

And..... Launchbox doesn't show any menu item on right click 😞 

 

I'm adding my solution (which is pretty much empty)....

TestPlugin.zip

 

I have a feeling like I am using the wrong .NET. There's something is still an enigma to me (I'm mainly a C/C++ dev, not .net). I downloaded a plugin (that work!) and decompiled it to inspect. It was compiled in .Net framework 4.8 (latest .net framework), which is supposed to be incompatible with .NET 6 (previously .NET Core 6 as I understand), and that plugin still reference to Unbroken.LaunchBox.Plugins.dll successfully, which is, as you said, compiled in .NET 6 (not .net framework...). 😵‍💫🤯

 

[JoeViking245]

30 minutes ago, GreenF said:

And..... Launchbox doesn't show any menu item on right click

Really not sure what to tell you. I took your solution, updated the paths to the references and built it.  Copied the .dll into the Plugins folder, started LaunchBox (you are starting LB after copying the .dll into the Plugins folder. Right?).  Right-clicked a game and saw this.

 

34 minutes ago, GreenF said:

It was compiled in .Net framework 4.8 (latest .net framework), which is supposed to be incompatible with .NET 6

LaunchBox, to a degree has some backwards compatibility.  When they 1st switched to .NET 6.0, I tested several of my previous "framework" plugins, and they all still worked.  I'm not saying switch yours to 4.8. That would be kind of silly.

 

Here's your same solution (with the paths for the resource files changed) and the compiled .dll.  Give my compiled dll a try and see if it appears in the game's menu.

TestPlugin.7z

 

 

[GreenF]

And the plot thickens...

I guess it's something in my environment, as with the plugin you uploaded I still get:

 

I'll check it out during the weekend.... Thanks a lot for your help! I will update once I figure it out.

 

Btw, about:

8 hours ago, JoeViking245 said:

LaunchBox, to a degree has some backwards compatibility.  When they 1st switched to .NET 6.0, I tested several of my previous "framework" plugins, and they all still worked.  I'm not saying switch yours to 4.8. That would be kind of silly.

I meant .NET states they don't have backward compatibility (at least in their documentation). Well, clearly as we see they are loading DLLs from different frameworks so I guess they are compatible to so to some degree (as you wrote), but I guess .NET team just let things run and they just state that "it might not work".

 

 

Thanks again!

 

 

 

[JoeViking245]

3 hours ago, GreenF said:

I guess it's something in my environment, as with the plugin you uploaded I still get:

I'll check it out during the weekend.... Thanks a lot for your help! I will update once I figure it out.

Usually when a simple plugin like this doesn't work it's because it's blocked. But if you used 7-Zip to extract it, it should unblock it for you.  Double check by right-clicking the dll file, select properties and see if there's an option to unblock it. If there isn't, then it's ok.

I tried running LB as admin (which we should NEVER do).  But the plugin still showed.

Then I got a crazy idea.... I added a manifest.json file to the test plugins folder. Though the plugin showed up in Manage Plugins (not that you can do anything with it there), it would not appear on right-click.  So if you still have that json file in with the plugin, remove it.  Note to self: the manifest.json file is only for plugins that are internally managed by LaunchBox.

 

If it's not the json file thing, then I don't know.  I suppose maybe try a known working right-click-game plugin and see if it works.  Here's a small, simple one known to work.  Note in the instructions it talks about checking that it's unblocked.

[GreenF]

Oh

My

God

 

YOU FOUND THE BUG! 👏👏👏👏👏

It's the manifest.json !

Feels like the Unbroken guys tried some "if-patching" for their own built-in plugins (that's of course a very wild guess, but yours was spot on(!) so who knows?! 😊 )

 

Thanks Again Joe the Viking!

[C-Beats]

The new manifest.json requirement is only a thing for the newer interfaces that are displayed in plugin manager. If that file exists we only check the DLL for the interfaces where it is required and don't look for the others.

[GreenF]

Thanks for clearing that out!

Can I ask which interfaces?

Also, if you don't find any interfaces in a plugin, I think you guys should display some error, or at the very least write it to the log (maybe you do, but I didn't see such a record).

[JoeViking245]

11 minutes ago, GreenF said:

Also, if you don't find any interfaces in a plugin, I think you guys should display some error, or at the very least write it to the log (maybe you do, but I didn't see such a record).

Or... if you're building a third-party plugin, don't add a manifest file.   

[GreenF]

That's also a valid option, but how would I know not to add? 

Anyway, just making some suggestions to help out the community here 🙂. 

I'll work on my plug in next weekend. 

Thanks guys, especially you Joe. 

[C-Beats]

21 minutes ago, GreenF said:

That's also a valid option, but how would I know not to add? 

I mean there's no documentation telling you TO add it, and no plugin you find on the forums has it either.

[GreenF]

Maybe I missed something, but I didn't find any tutorials. There's documentation for the DLLs, or code samples I found in github, but no tutorial on how to create a plugin.

Same for the installation, I figured I need to copy only by finding posts in the forum (and seeing the plugin dir). 

The other thing is once I had some issues in the beginning (like using .net 8), I tried looking at existing installed plugins (i.e. plugins directory), which were only the stock ones and all of them have the manifest file. Once I placed a manifest file it added my plugin to the manager, which looked like I was on the right track. Also, I assumed that if I had done something wrong, I would see it in the log. 

Anyway, I just think that you guys should write a small official getting started guide with prerequisites (like .net 6), the dlls that should get referenced and how to install the plugin. Otherwise we'll get into guessing in case we're doing something wrong and that may lead to lots of funny stuff. It is also a place to publish updates or changes you might do in the plugin system.

But again, just a suggestion 😁

Edited July 18 by GreenF