I've seen this question multiple times but there never seems to be an answer other than "Don't use the 'Start on Front-End Work Station' option, use the 'Registered Program' option."
Does anyone know why a .NET Connector application cannot be set up to execute and handle functions through an RFC Connection configured as "Start on Front-End Work Station?" It works fine as a registered program, but this won't work, since if multiple users are running the program from their local machine all with the same ProgramID, the RFC connections will get confused -- am I right?
What I want to do is:
Like I said, this scenario works fine as a registered program, but that's not entirely feasible. Can anyone let me know if I should check something else to allow the program to launch on-demand, similar to SAPFTP or R3_WINDOWS_SERVER?
I went a different route, but it works pretty well. I made a .NET library (DLL) that contains a Form within it. registered everything safe for COM interop and called it using OLE functionality. (registered the program in t-code SOLE). This ABAP launches the form and returns the user input. SCN won't allow me to attach the .NET source code, but feel free to email me if you'd like to see it.
DATA: mydll type ole2_object,
str type string VALUE 'Empty'.
CREATE OBJECT mydll 'MYAPP.LAUNCH'.
IF mydll-handle > 0.
CALL METHOD OF mydll 'GetText' = str.
I think, I got the solution.
In your .NET application you have to pass the start arguments of the exe over to your RFCservre component.
Like this (C# code):
static void Main (string  args)
Then the connection test works well in the SM59 and the RFCServer is accessible from SAP!