Interacting with FS using C#

[Guest Timbo]

Hello,I've been getting into C# lately and was wondering if there is any documentation, official or otherwise, about directly interacting with FS2004 using C#. I have a bad feeling that there is next to nothing on this, but I figured it was worth asking.Thanks

[Guest _FSAviator]

I regret that this post may appear twice as I am having problems posting URLs in html format and am retrying in text format.Since no one else has answered may I suggest that you obtain the latest SDK for FSUIPC. The most recent at the time of posting was v3.14 issued on 16th January 2004. This contains UIPC_SDK_CSHARP.zip with details and examples for C# users, thanks to Scott McCrory.Even if you are already familiar with the content of the FSUIPC SDK may I suggest that you ask any questions about C# and MSFS in the FSUIPC forum as many of the people who may be able to answer them are more likely to congregate there.FSUIPC, its SDK and the relevant forum are located at;http://www.schiratti.com/dowson.htmlFSAviator

[Guest Vorlin]

Many thanks to Scott for sussing out the interface and thanks to you for pointing this out to us here!My only other concern is how one would create a .dll with C# that could be changed to a .gau in order to draw a gauge? I know that C++ requires certain headers and, so far as I know, those headers have not yet been ported into C# class files that could be included or .dll's that could be referenced.Then the next question is would we be limited to GDI, GDI+ or would DX D3D be possible? Support for Direct Draw is going away in Vista and DX10 is forcing as much of hte code into hardware processing as possible, which is a good thing, but will require a little more planning on the part of the coder.Then again, I wonder if there are many people out there running FS9 or FSX under OpenGL and what kind of mess that would be on their screen if you wrote a gauge in D3D? ... trying to imagine this reminds me of my dog's recent bout with explosive diarrhea.Just wondering a few things such as these because I'm in the middle of some DX tutes these days and was wondering if and how they could be utilized in FS.Scott / Vorlin

[WarpD 824]

>Many thanks to Scott for sussing out the interface and thanks>to you for pointing this out to us here!>>My only other concern is how one would create a .dll with C#>that could be changed to a .gau in order to draw a gauge? I>know that C++ requires certain headers and, so far as I know,>those headers have not yet been ported into C# class files>that could be included or .dll's that could be referenced.>I do not believe C# supports the creation of DLLs, though I could be wrong.>Then the next question is would we be limited to GDI, GDI+ or>would DX D3D be possible? Support for Direct Draw is going>away in Vista and DX10 is forcing as much of hte code into>hardware processing as possible, which is a good thing, but>will require a little more planning on the part of the coder.>DX10 doesn't 'exist' at this point, so who knows what will and will not be possible. I know that any DirectX rendering in FS9 is a closely guarded secret, as in absolutely no one has ever offered information on it.>Then again, I wonder if there are many people out there>running FS9 or FSX under OpenGL and what kind of mess that>would be on their screen if you wrote a gauge in D3D? ...>trying to imagine this reminds me of my dog's recent bout with>explosive diarrhea.>You can't run FS with OpenGL.>Just wondering a few things such as these because I'm in the>middle of some DX tutes these days and was wondering if and>how they could be utilized in FS.>>Scott / VorlinLike I said, how to access DirectX for rendering in FS has never been made public.

[Guest Vorlin]

>I do not believe C# supports the creation of DLLs, though I>could be wrong.In VC# 2005 Express I do it all the time. It's not called a .dll in the Create a Project selections though, it's called a Class Library. It ends up producing a .dll...>DX10 doesn't 'exist' at this point, so who knows what will and>will not be possible. The bottom two articles here go into it. Check out "DX10 Introduction" and "Shaders in DX10". It's certainly not detailed information by any means but it gives a pretty good idea of what's on the horizon.http://just-code-it.net/articles.htm>I know that any DirectX rendering in>FS9 is a closely guarded secret, as in absolutely no one has>ever offered information on it.I'm not sure about the "in FS9" part but there are plenty of tutes on DX and D3D. This is what has me a tad confused. the way I'm looking at it, if FS9 allows a .dll to have a small piece of a poly to draw on then what does it care if that .dll is using GDI, GDI+ or D3D as long as the .dll returns a usable image that can be mapped to that area of the poly? This is the area that I don't understand well...>You can't run FS with OpenGL.Ok, that simplifies that...>Like I said, how to access DirectX for rendering in FS has>never been made public.Hmmm.... I wonder if anyone has tried or, if they've doen it, perhaps they figured that others would do the same if they so chose to.Time to get to the day job.... you guys enjoy yourselves.Scott

[Guest ziporama]

I'd say it's possible, but not without a tremendous amount of hardship, er, challenge. I've been hacking at this for a while now.First, you can most certainly create DLLs in C#, but not the standard win32/win64 dynamic link library. C# (or any .NET language for that matter) can only create .NET dlls which are class libraries (packaged assemblies in a dll form). The are in principle exactly like a regular DLL, but the proper entry points will not be exposed, and certainly not in the form that FS expects its DLLs to be. One of the things the .NET dll does on startup is to create an application space for your assembly and an instance of the CLR engine.To use C# with FS, you need to bridge the gap between the .NET world and the standard DLL module or gauge file format FS expects.There are several theoretical ways to do this in FSX, and only two in FS9. This is the theory, in practice I've run into some severe problems with the garbage collection model in FS and how interop works deep inside. We know that using .NET and FSX outside of SimConnect is vastly documented, don't we :)Method 1 (FSX only): Use SimConnect and write an external program to interface with FS. This program can be a DLL or a regular EXE, but will be standalone. By far the easiest and actually is documented in the SDK.Method 2: Write a C++ Interop wrapper that calls a C# assembly. This is how MS wrote the SimConnect wrapper for .NET. The nice thing here is that C++ interop is semi-automatic using the #pragma managed and #pragma unmanaged pre-processor directives, and yes, you can use any C# DLL along with the C++ Interop assembly. Watch out for garbage collection or null pointer exceptions will abound.Method 3: Write a C# DLL exposed to COM (via COM interop), use a regular DLL inside the FSX process space (a DLL or gauge) to use the .NET assembly via the COM interface. This is the opposite of #2, and does require you to use a standard C or C++ module, add the COM layer via MFC or ATL and call your C# DLL using COM. That has its share of problems because MFC and ATL are inherently problematic when used with the dreaded macros provided in the header files. The macro in macro in macro in macro that calls external undocumented function approach to be challenging.The short of it is that if you enjoy this sort of thing, go at it. I've made some progress in this area, but it is far from easy. A lot of the complexity gets down to the lack of documentation and the need for trial and error. When you look at the amount of work involved, it may be just as fast to learn C++ and deal with the pre-processor macro extravaganza. I like to think of this as one reason why C# was invented with no pre-processor and no pointers (ok, there are pointers using #unsafe so this is not entirely true)...Another thing you will hear is a performance hit. I've not seen this very substantiated in terms of CLR performance vs raw C++ code in this environment. Caching, threading and a number of other parameters enter the equation. Certainly, C is the fastest, C++ is marginally slower than C, and the CLR is interpreted but also pre-compiled. Not sure if anyone has real data at this point.Hope this helps,Etienne

[Bob Scott 7,720]

>Many thanks to Scott for sussing out the interface and thanks>to you for pointing this out to us here!>>My only other concern is how one would create a .dll with C#>that could be changed to a .gau in order to draw a gauge? I>know that C++ requires certain headers and, so far as I know,>those headers have not yet been ported into C# class files>that could be included or .dll's that could be referenced.Scott McCrory's C# interface is basically the same interface I wrote for Visual Basic .Net ported over to C# (which was a re-write of Chris Brett's original version for C). It is intended for stand-alone C# executables interfacing with FS via FSUIPC and/or WideFS, not for compilation of gauge dlls that will run under FS.CheersBob ScottATP IMEL Gulfstream II-III-IV-VSantiago de Chile