Error when adding another class

[realsimgearinc]

When trying to add a reference to another c# file in the primary plugin class I get the following exception and the plugin won't load.

[5/24/2018 2:53:11 PM] Logging Started
[02:53:11 P] XPNet CLR: Start
[02:53:11 P] XPNet CLR: Looking for plugin in (C:\Users\...............
[02:53:11 P] XPNet CLR: Inspecting plugin candidate: (Path = C:\Users\...................
----------
[02:53:11 P] Exception: TargetInvocationException: Exception has been thrown by the target of an invocation.
Stack: 
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.ConstructorInfo.Invoke(Object[] parameters)
   at XPNet.PluginBridge.LoadPlugin(String rootDir)
----------
[02:53:11 P] XPNet CLR: Failed to load plugin due to exception: (Path = C:\Users\J...........
[02:53:11 P] XPNet CLR: Failed to find a plugin to load.  Will tell X-Plane we failed to start.

[jaurenq]

That TargetInvocationException is actually wrapping some other exception that is occurring when the plugin tries to load your class. I just committed a change to the logger so that it will trace down all the InnerExceptions on an Exception and print them all. Pull the latest and try it again; it will still fail (unless you've fixed it in the meantime), but it'll print the original exception now, not just the TargetInvocation wrapper, and fingers crossed that exception will be something obvious/actionable.

[realsimgearinc]

Thanks for this, very helpful. The inner exception error is below. I added the System.IO.Ports via NuGet, so do I need to add this file manually somehow?

Inner Exception: 
FileNotFoundException: Could not load file or assembly 'System.IO.Ports, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
Stack: 

[realsimgearinc]

I tried adding the DLL from this location to the plugin folder. The error messages goes away but X-Plane crashes on launch.

Looks like the issue is associated with the fact that version 4.4.0 of System.IO.Ports is installed, but the error log shows that it's looking for version 4.0.0.0.

[jaurenq]

I think your diagnosis is probably correct. VS handles DLL dependencies for Core projects much differently than for older .NET Framework projects; I have a lot of experience with Framework DLL issues but I haven't really learned how you're supposed to do things with Core yet, which is why this part of using XPNet isn't automated yet. My best suggestion at the moment is to go to your nuget setup and configure that you want specifically the 4.0.0 packet of System.IO.Ports instead of 4.4.0.

[realsimgearinc]

Unfortunately, only v4.4.0 is available in nuget setup

[jaurenq]

If you care to get lost in the weeds, do some Googling for System.IO.Ports and .NET Core; there's a multi-year history of "will they or won't they" regarding adding that API to .NET Core. A year ago, the status of that API on .NET Core was up in the air; when I first started trying to use a serial port in an XPNet plugin I had to start with a 3rd-party lib that I never actually got to work correctly. In some release since that time, the maintainers of Core decided to add System.IO.Ports after all, via that nuget package, but I bet you also have to make sure that you're on a new-enough runtime as well.

I had some working code using XPNet and System.IO.Ports back around Christmas that "just worked". I just went and looked at the config for that project that I had working, and it looks like this:

• Targets .NET Core 2.0.
• Uses the System.IO.Ports 4.4.0 nuget package.
• Installed dotnet runtime (in the dotnet folder in the plugin folder) is 2.0.4.

So from that config, it seems the problem is probably the opposite of what I wrote above: 4.4.0 is a known working version of System.IO.Ports and something in your setup is trying to reference 4.0.0 instead. The task then is to figure out what that thing is.

If your own project isn't the thing that's referencing it, maybe it's one of the dependency DLLs, or even the runtime itself. I updated to the 2.0.4 runtime when I got my serial port stuff working back at Christmas and it's possible that in doing so I happened to get a new enough runtime for Ports to work without even realizing it. The System.IO.Ports.dll that I have in my plugin folder has the exact same Last Modified date and time as yours.

[jaurenq]

I thought of one more thing to check. Though in Visual Studio my project shows as targetting ".NET Core 2.0", it looks like the latest SDK I've got installed on this computer where it was all working is 2.1.2, which I installed on Dec 28, 2017 (around the time I got some serial port code working here). Maybe having a newer SDK installed matters. For me the SDKs are going to C:\Program Files\dotnet\sdk; look there and see what you've got.

[realsimgearinc]

It looks like I have 2.1.2 installed also. This is the same as what is installed in the plugin folder. There must be something in my setup that is calling for v4.0.0.0 but I can't find it.

[jaurenq]

Hey Jarrod, did you ever find what was referencing the older Ports lib and get it working?

[realsimgearinc]

Hi,

No, we ended up working with our own C++ version in the end.

Sent from my iPhone

On Jul 10, 2018, at 9:41 PM, Stephen Quattlebaum notifications@github.com wrote:

Hey Jarrod, did you ever find what was referencing the older Ports lib and get it working?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.