Lunatico GNS support (included version)

SGP 4.1 download still includes Lunatico GNS version 1.0.0.2 while Lunatico themselves distribute version 1.0.1.0 since at least 2020. Unfortunately the version currently still included with SGP does not work well with other Lunatico software.

Can you upgrade the with SGP included version of Lunatico GNS? Or better still: have SGP use the GNS version at a user defined location? Latter is already done for external applications such as PHD2 and ASTAP. This might then also prevent the issue where SGP automatically launches GNS at the start of a sequence, even when that was already launched previously by SGP for a sequence that has been aborted. Launching a second instance of GNS generates a conflict and accompanying error messages.

We keep SGPro updated with what Jaime has available in “Update for SGPro” download here: http://lunaticoastro.com/GNS/GNS.1.0.0.2b-SGPro.zip

Have you tested 1.0.1.0 with SGPro yet?

@Ken , I have also been in touch with Jaime and was under the impression that you had been discussing this issue with him as well.

Unfortunately it is not possible to test GNS 1.0.1.0 with SGP since SGP will launch its included instance of GNS that will then raise a conflict because the other GNS instance is already running. As decribed in my previous post it would be better to either include the latest version or (better, but more work for you) add it to the External Apps dialogue in SGP Options.

I am more than willing to test SGP with GNS 1.0.1.0 if you can provide me with an SGP version that does not auto launch GNS 1.0.0.2 when a sequence is started (and usage of GNS is enabled in SGP).

Thanks. Seems like you should just be able to rename the existing GNSUI.exe to something else and then copy the new GNSUI.exe into the SGPro install directory. I am uncertain if the new version is backward compatible with 1.0.0.2, but you can try it out if you’d like.

No, I have had this discussion with Jaime of Lunatico back in September 2020 already. Differences between the two GNS versions are apparently minimal, but the file structure has changed. SGP includes the version with GNSUI.exe and GNS.dll. Lunatico GNS install only has GNS.exe and no separate DLL.

So, SGP launches GNSUI.exe (even if one is already running), that conflicts with GNS.exe (if already running). It will also conflict with another GNSUI.exe instance (if left running from a previous SGP sequence that was aborted).

On the other hand other Lunatico software will look for GNS.exe and can not connect to GNSUI.exe.

Hello, Jaime here. Let me try to sort this out.

None of Lunatico programs will execute GNS.exe (nor GNSUI.exe) - they will just instantiate the COM object (It is difficult for me to check now for older versions, but I’m fairly sure this was the situation from the very beginning).

It would be much easier if SGPro just used the COM object as an external one (dynamic in C#), as it would free us to release new versions more easily, and it is one less burden for SGP development.

The COM calls are backwards compatible.

Hope this helps. Anything I’m available, but please send me a heads up.

Ah, ok. I was unaware that GNS now registers a COM object. I will take a look.

Hi Ken,

that could be the original misunderstanding :slight_smile: - it has always registered a COM object. This explains things! Sorry if I was not clear…

Im looking at GNS integration now and we do already use the COM implementation, but we felt compelled to distribute the GNSUI.exe dependency because it seems like it is not registered with the operating system as a COM object on install. Is it possible to do that? Doing this would allow a simpler setup where SGPro could just know where to find the GNS dependencies without user intervention or more settings.

Hi Ken - sorry missed this notification.

The object is registered on install - maybe it was not in the early test versions (as SGPro was there from the very beginning) - but since then, all official versions have performed the COM registration on the install process.

Let me know if you need anything to try that out.

Thanks.

OK, thanks. I will take a look.

@jaime

Does GNS have any 32 / 64-bit considerations or can the same version be used for both versions of SGPro?

Hi Ken,

1 - no special consideration, it will work from both versions.
2 - GUID: {BEA72AC7-0495-4DD6-89CE-47D9C1A5E7F3}

Anything just let me know,

Thanks! I don’t know if you have any particular insight to the issue I am currently having, but it doesn’t hurt to ask… I am attempting to convert GNS to a “reference-free” dynamic integration where SGPro does not need to import or reference any contracts from GNS. C# supports this and I have it all laid out, but the OWL object fails immediately as soon as I try to operate on it. How it works:

  • Do registry lookup based on CLSID
  • Find location of registered GNS assembly
  • Dynamically load the assembly and extract the class schema (GNS.OWL in this case)
  • Attempt to operate on the object normally with NewTimeout

Have you ever attempted to integrate the GNS assembly this way?

I can’t really figure out why this is broken, but all indications point to improper initialization from within SGPro.

var objectHandle = AppDomain.CurrentDomain.CreateInstanceFrom(@"C:\Program Files (x86)\GNS\GNS.exe", "GNS.OWL");
var gnsObject = objectHandle.Unwrap();
var t = gnsObject.GetType().GetProperty("NewTimeout");
t.SetValue(gnsObject, 30000, null);

The above, lines 1 - 3 are fine and a new GNS.OWL object is created, but line 4 just fails with {"Object reference not set to an instance of an object."} with the callstack indicating the error was emitted from within GNS => at GNS.OWL.set_NewTimeout(Int32 Value). The call stack shows that the execution path made it to the correct function, but something goes wrong here.

Any thoughts on this?

Hi Ken,

I always struggle with Windows, but I’ve been using this approach that seems to work nicely:

public partial class Form1 : Form
{
private dynamic Owl;

public Form1()
{
InitializeComponent();
}
private void Form1_Load(object sender, System.EventArgs e)
{
const string progID = “GNS.OWL”;
Type foo = Type.GetTypeFromProgID(progID);
Owl = Activator.CreateInstance(foo);
}

private void Form1_Unload(object sender, System.EventArgs e)
{
if (Owl != null)
Owl = null;
}
private void btnSendMessage_Click(object sender, EventArgs e)
{
Owl.NewMsg = “Test message…”;
Owl.NewTimeout = 123;
}
}

This way you don’t have to know anything in advance about the file location, etc… I actually use this system in almost every project.

Hope this helps, if not, let me know!

oh ya? Does that mean Type.GetTypeFromProgID does the registry lookup for you? The docs don’t mention it, but I assume it does or it wouldn’t be able to find the COM assembly.

Yes, it does :smiley: - pretty useful. I don’t remember how I discovered it, but 99% it was googling in frustration.

Thanks. That is extremely helpful and it works too!

@jaime @Ventania In 4.1, betas 729 and higher will no longer distribute GNS and will use the installed and registered version of GNS instead.

Great!

Shall I remove the “special version for SGPro users”, or better wait until the beta makes it to official release?

Great news @Ken !

Will gladly test this when .729 is released and local weather actually allows a meaningful sequence to be executed. Can also try to compile some sort of dummy sequence with simulators if the clouds don’t disappear any time soon. Will keep you posted.

Thanks very much for all the efforts here both @Ken and @jaime as this has been a two year long grief of me with SGP and I am very happy to see it is now sorted.Will confirm by shortly.

1 Like