NuGet is not automatically downloading DLL?

[Demon]

Nope, still get that EXCEPTION.

Can I get more detail from a windows log somewhere?

[Demon]

Updated VS tools:

 

EDIT: I will be using C++ and VB.NET for this project.

EDIT SOME MORE: I hadn't noticed a LOT of tools were hidden.

[Paul Henty]

Go to the individual components tab and check you have NET SDK checked:

That seems to be the part you're missing.

Are you on Windows 10/11?

Paul

[Demon]

NET SDK is checked.

Win 10

 

[Demon]

The installation details listed to the right seem to be a "condensed" version of all the ones on the left.  NET SDK is checked on the left, but I don't see it on the right.

I'm making an image of all the checks on the left now...

[Demon]

This is all the tools listed on the left:

[img]https://i.imgur.com/brpbyG2.png[/img]

EDIT: AWE CRAP!, gonna see if I can host this on IMGGUR for a better resolution.

 

EDIT SOME MORE: Resolution is better when I open in another window, then zoom in there (using Chrome browser).

[Paul Henty]

Hmm.. Your dotnet --info is clearly saying there are no .NET SDKs installed. So something has gone wrong.

The only thing I can suggest now is to download and manually install the .NET Visual Studio SDK from Microsoft:

https://dotnet.microsoft.com/en-us/download/visual-studio-sdks

You need the .NET 6.0 Visual Studio 2022 SDK - either x86 or x64 depending on your machine.

Paul 

[Demon]

Installed x64 version just now and rebooted.


This is insane...

EDIT: I checked VS tools and NET SDK is checked.

[Demon]

Found this on GITHUB:
 

Quote

Note about 64-bit installs of the .NET SDK

In 64-bit environments the .NET SDK will fail to be discovered if the 32-bit dotnet path comes before the 64-bit dotnet path in the Environment PATH variable. Try removing the 32-bit path entirely from your PATH variable and relaunch VS Code to see if your issue is resolved.

 

[Demon]

My path variable looks like this:

[Demon]

I ran WHERE.EXE DOTNET and got this:


That purple highlight would mean that C:\Program Files (x86)\dotnet\dotnet.exe is causing me grief?

How would I go about editting that?  I'm thinking of at least inverting the order....?

Robert

[Paul Henty]

Yes that looks to be what the problem is. It's going for the 32 bit files not the 64 bit ones.

Look for the Path variable in the System list (not the user list). You should see them there... 

Paul

 

[Demon]

I moved DOTNET above the x86 folder.


And got this.


🙂

Gonna go test...

[Demon]

WOOT WOOO!!!


Created using your template and build.

I'm so happy I hadn't wasted your time on a stupid mistake on my part.  🙂

Thing is, I remember reading about that 32bit stuff interfering with 64bit compilation while researching how to do this (somewhere, can't remember where).

Thanks so much!

[Paul Henty]

Ah brilliant! Glad it's working. That was an obscure problem. 

Paul

[Demon]

It may not seem as much, but to me it's the world.
🙂



I can get to the SimConnect Events using C++, and now to the SimVars using this DLL.  Now if only I could figure out how to get to those pesky XMLVARs from C++ or VB...
😄

[Paul Henty]

Quote

Now if only I could figure out how to get to those pesky XMLVARs from C++ or VB...

If you mean local panel variables (or L:Vars) you can use my DLL. For all sims you can use use:

FSUIPCConnection.ReadLVar()

For MSFS you can also use the MSFSVariableServices class. This also allows you to set H:Vars as well.

This is more complicated, but is thousands of times faster than ReadLVar().

There is an example project dedicated to MSFSVariableServices on the website...

http://fsuipc.paulhenty.com/#downloads

Paul

[Demon]

10 hours ago, Paul Henty said:

If you mean local panel variables (or L:Vars) you can use my DLL.   ...

Paul

(reading your link as soon as I post this)

These guys are the last on my list.  I don't know if they are considered as local, and haven't seen examples of how to read/write to them YET:

• XMLVAR_YokeHidden1
• XMLVAR_YokeHidden2
• XMLVAR_ADF_Mode

That ADF Mode selector is the last control on the Cessna 152 that I can't afffect; it's not a Simconnect event or simvar (by MSFS SDK standards - although I might have missed a paragraph - there's a LOT of information spread all over that documentation).

I started looking at WASM modules today to see if they can get to them.

Robert
 

[Paul Henty]

Quote

 I don't know if they are considered as local, 

Not sure. They usually have the L: prefix, so these might be something different. I've not heard of XML variables and I don't know how you can read them.

Paul

[Demon]

I've seen isolated comments about XMLVARs and FSUIPC, but in conjunction with "calculator code".

https://forums.flightsimulator.com/t/how-to-write-to-xmlvar-defined-localvariable/363112

The only other place I've seen Calculator Code is in links about FSUIPC's WASM module.

That's my current direction of research unless something better comes along.

Robert

 

[Paul Henty]

The MSFSVariableServices in my DLL uses FSUIPC WASM Module.  (You could also use C++ if you want to roll your own implementation).

MSFSVariableServices allows you to execute calculator code.

Paul

[Paul Henty]

Looking at that link it would seem the XML Vars are L: vars.

Paul

[Demon]

6 minutes ago, Paul Henty said:

The MSFSVariableServices in my DLL uses FSUIPC WASM Module.  (You could also use C++ if you want to roll your own implementation).

MSFSVariableServices allows you to execute calculator code.

Paul

Ok, that's excellent news.

Can your module also process Simconnect Events?  I'm looking through your Example Code project and I see mostly references to Offsets.

(I'm a mainframe guy by trade, so things don't stand out to me unless there's a flashing neon sign)

Robert

[Paul Henty]

No, my DLL can't process SimConnect Events. It doesn't use SimConnect.

The Offsets are how FSUIPC handles data. These mainly map to what I think SimConnect calls "SimVars".

There is another, separate example project for the MSFSVariableServices.

Paul  

[Demon]

Ok.  Now that I think about this a bit more, it's probably better if I keep processing separate.  Your module works perfectly at what it's designed to do.

I'm going to have a "dispatch" module that will process requests from my USB device, and have dispatch issue calls to your VB.NET module, or a C++ module for SimConnect requests (that logic is already tested out).

Modular is always better, easier to isolate muck-ups.  I just need to figure out how the calls work.

Robert
🙂