AcuToWeb and non-graphical .NET assembly

I'm having trouble getting non-graphical .NET assemblies to work under AcuToWeb. CREATE statements that return a handle under normal circumstances return no handle under AcuToWeb. In fact, they seem to be ignored altogether, because changing the namespace to something non-existent, which would normally cause an error, has no effect.

The syntax I'm using to create the control is:

CREATE "@My.Assembly"
NAMESPACE IS "My.Test.Namespace"

I've also tried using the AcuToNet.dll interface, but got the CoCreate Instance Failed error.

As I understand it, instantiating non-graphical .NET assemblies with CREATE is supported, so is there something I need to do differently to get it to work under AcuToWeb?



  • Are you running the AcuToWeb Desktop? The AcuToWeb Desktop is needed to support any @ syntax.
  • Yes, I'm running AcuToWeb Desktop.

    I managed to instantiate a COM object in AcuToWeb by adding SERVER-NAME to the CREATE statement, but I've had no luck with the .NET assembly. I tried adding FILE-PATH to the CREATE statement (though the DLL is in the same directory as the runtime anyway), but it didn't help.

    About the COM object: Though I'm able to create an Excel application and generate a worksheet, trying to make the application visible doesn't seem to work. Is that a limitation of AcuToWeb?
  • trying to make the application visible ... are you trying to make the worksheet visibile inside the browser? or just visible in some other means? or are you saying that the COBOL program is no longer visible? We're looking at reproducing the .Net assembly issue currently. There may be a bug, not sure yet. I'll let you know what we find.
  • Verified Answer

    We have reproduced the issue where using a .Net assembly in a COBOL program which works when using Thin client, does not work when using AcuToWeb. We have sent this issue to Development to sort out. Thanks.
  • By making the application visible, I mean setting the visible property of the Excel application to true after the worksheet is generated so that the user can see it.

    It occurs to me that using SERVER-NAME is probably not the way to go, because Excel needs to run on the client. I tried it because using 'SERVER-NAME is "Local:"' was the only way I could get the CREATE statement to return a handle. I'm testing all this on one machine, so the distinction between what happens on the client and what happens on the server is sometimes lost on me.

    I've tested this use of Excel under Thin Client (without the use of SERVER-NAME) and it works. Could the failure to return a handle to a COM object under AcuToWeb be related to the .NET issue?

  • Verified Answer

    Could the failure to return a handle to a COM object under AcuToWeb be related to the .NET issue? Possibly, the .Net issue seems to be centered around an internal opcode, we're still sorting that out. AcuToWeb (even with the Desktop) does not support ActiveX or .Net assemblies that contain a User Interrface. What you may need to do is use C$SYSTEM and call a client side bat or cmd command to launch Excel