Using VS2022, C# 10, RO 10.0.0.1533, .Net 6, code first
I can create a new RO server by doing Add | New Project and selecting “Remoting SDK Server, Code-First” in VS and then just run the created application without a problem. When I do, the application runs as expected and I get the little default window with the RO button on it.
There doesn’t appear to be a template to create a .Net 6 RO server (and if I missed it, please let me know), but if I use the MS upgrade-assistant “application” to upgrade that (almost empty) project to .Net 6 and then run it, the application appears to run (in that I can set a breakpoint on server.Run() and it gets there and the memory and CPU usage graphs appear in VS), but the window with the button does not appear. The unfortunately means I can’t close the application without using “Stop Debugging”, and as such it doesn’t do a clear shutdown, etc.
Am I missing something or is this an RO bug? I originally did this with one of my applications, but reproduced it with a clean new app, as I said. I see in searching for similar problems that at least some people are using .Net 6, but they may be running it as a service (and I’ll need my app to be able to run as not-a-service sometimes as well).
I’m unfamiliar (as yet) with servers not using the default window, so I haven’t tried to make my own main window yet to see if that works or not.
As an ancillary question: I’m a relative newbie with VS/C#, but is it possible to debug into the RO code and see where the problem is coming from? I’ve looked through the source briefly, but nothing jumped out at me, but breakpoints are non-functional. I assume I have to load/reference the PDB somehow, but I can’t see how/where to do that. I’d love a point in the right direction so I could debug this issue and figure out if it’s me or RO (and I could submit a bug report).
To bd cear, this means you create the application for classic .NET 4.x, and it works ok, and once you migrate it to .NET Core 6.x, it no longer shows the UI?
If so, this sounds like a bug in RO for .NET Core or a bug in the migration. I’ll log an issue and my colleague will have a look.
I take it the (GUI-less) server runs fine and accepts requests okay?
Of course, that iOS one of the top tenets of the “Combo” template; that it can be run as service, GUI and command line tool.
You should be able to do this if you uncheck “Just My Code” in the Debugger settings for VS. I think it should file the PDBs automatically, but if not, you can right-click the Remoting SDK .dlls in there Module window in the VS debugger and choose to load symbols manually.
To bd cear, this means you create the application for classic .NET 4.x, and it works ok, and once you migrate it to .NET Core 6.x, it no longer shows the UI?
Correct.
I take it the (GUI-less) server runs fine and accepts requests okay?
I had not yet gotten that far, but have now: so, yes, I can login and call functions. I haven’t tested everything (though I have no reason to doubt the rest will work as well).
I am unfamiliar with the commandline operation. The application runs, but it seems to run as a window-less GUI, in that the command line returns immediately to the prompt and the application is still running process list. As far as temporary solution, I’m good to go. I can work around this in several different ways, no worries.
Ok, after your hints with PDBs I debugged into this and the “issue” appears to be that the default action for NETCORE and NETSTANDARD (via a #if) is ApplicationRunAction.ExecuteWithCLI (from ArgumentParser.SetDefaultValues()). A quick glance through the code leads me to believe that this cannot be overrided via other command line arguments (though I may have missed something).
ApplicationServer is a rudimentary solution provided only for backwards combability reasons. It supports only command-line mode. The reason for that solution is that adding additional WinForms dependency is not always feasible, especially considering that it won’t work on non-Windows hosts.
New host variants provide better combability with IHostBuilder approach and allow to run server apps either as command-line aps, as Windows Service apps or as Dockerized applications, effectively covering 99% of use cases.
Perhaps in your case the best solution would be to create a WinForm or even WPF application and then to add RO SDK server functionality to it. If needed, I can create a sample of such application.
Ok, apologies, seems I missed some stuff and did things the exact wrong way. I assumed what I had was right because (unless I missed something more) it pretty closely matched all of the sample apps I looked at. I was also surprised that it seemed that none of the demo apps seemed to be WPF apps. Looking again, I did find the other templates, not sure why they didn’t show originally.
It looks like neither Microsoft.Extensions or Topshelf are perfect fits for me, since I need GUI/service. Well, need is maybe the wrong word, maybe strongly desire. Being able to register the ApplicationServer as a service via command line was a nice thing. Can you recommend either over the other?
Are any of the samples designed around Microsoft.Extentions (or Topshelf for that matter)? I do most of my investigations via samples (and then augment with doco) but I don’t remember seeing any that stood out as different, like that. A quick search doesn’t show HostFactory or Host.CreateDefaultBuilder (from your new hosting link) as referenced in any of the samples. A quick search of the online doco doesn’t show any info more than the link you provided. Am I missing doco I should have read about this or is that all there is?
Perhaps in your case the best solution would be to create a WinForm or even WPF application and then to add RO SDK server functionality to it. If needed, I can create a sample of such application.
I’d dearly love this, if there is aren’t samples I can look at (for both the server environments or using WPF).
Suggestion for anyone following after me trying to make this work. Using RO with Microsoft.Extensions.Hosting and WPF is viable, and not especially difficult, given the right add on packages. I can suggest both:
Dapplo.Microsoft.Extensions.Hosting.Wpf
and
WPF.Extensions.Hosting
both from NuGet. I ended up using WPF.Extentions.Hosting, though it required some minor recoding of my base Program class, due to a different usage scheme from the base Microsoft.Extensions.Hosting. I originally started with Dapplo, but was unable to make it work with IpSuperHttpServerChannel for some reason that I couldn’t figure out, and ended up with WPF.Extensions.Hosting. In the end I ended up with a single Program class that let’s me have an application be Console or WPF and toggle between them at load time (eventually via command line).