You can only use .NET objects from the GUI client or from the WebClient executable on Windows. (14693) - Forum - OpenEdge Development - Progress Community

You can only use .NET objects from the GUI client or from the WebClient executable on Windows. (14693)

 Forum

You can only use .NET objects from the GUI client or from the WebClient executable on Windows. (14693)

  • Can someone explain this to me? I ran into this last week and Progress TS support says that in their license agreement with Microsoft they have to prevent their AP's from using certain .NET components when not running on a GUI client. I do not want say I understand that but that really ties our hands does it not? Basically, if we have purchased a 3rd party control that is written in .NET we cannot use it on an appserver. Examples of this are: Quickbooks SDK (allow integration to Quickbooks accounting), Positive Access Driver's License parsing utility, Infragistics.Excel, OPOS Controls that are used to integrate with POS peripherals, etc. The list goes on and on. Basically, any control written in .NET will NOT run even though the 3rd party control allows us to use the control anywhere we would like.

    Is this the intention of Progress or an oversite? What exactgly does Progress need to prevent it's AP's from doing? Can they do a better job without tying our hands?

    Any insight would be great.

  • Can someone explain this to me?

    I think if that's really critical for you I'd discuss that with your sales rep.

    I ran into this last week and Progress TS support says that in their license agreement with Microsoft they have to prevent their AP's from using certain .NET components when not running on a GUI client.

    I must say that this surprises me as well. So far my understanding was that the limitations in the use of the .NET brige were to protect Prorgess' interest (who needs ODBC data server when ADO.NET is available) and the product stability (multi-threading).

    But hey, the product component is called "GUI for .NET". What (supported) use of the .NET bridge do you expect outside of the Graphical User Interface?

    Did you check the section from the OpenEdge EULA? (%DLC%\licenses\OpenEdge\OpenEdge_EULA.rtf)

    "2.  The products listed below include the “OpenEdge AVM to Microsoft .NET CLR intra-process communication” (“AVM to CLR Bridge” or the “Bridge”).  At this time, the allowable uses of the Bridge are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products, and for one-way usage of AVM calling the CLR (and not vice versa).   


    Any use of the Bridge other than as set forth in the previous paragraph is prohibited.  Additionally, the Bridge may not be used for multi-threaded processes." 

    Basically, any control written in .NET will NOT run even though the 3rd party

    control allows us to use the control anywhere we would like.

    Any insight would be great.

    If you want a technical solution that works, try COM-Interop (works fine for me). When there are classes in those products that are designed to be used on something like the OpenEdge AppServer (I wouldn't call those classes a Control, by the way) you should be able to create a simple wrapper in Visual Studio (including the free Express Editions) and build that as a COM-Accessible assembly. Works fine. Basically what you will be losing is strong typing and compile time validation.

    But I'm with you. Now with the state of the GUI for .NET I believe time has come for native access to .NET on the AppServer or WebSpeed agent (and TTY client). There's far more in the .NET framework that's nice than just GUI components.

  • Message:

  • Message:

    Roger, looks like your message got lost.

  • Probably the e-mail equivalent of a dropped jaw and open mouth ...

    I have only been able to think of two reasons for a limitation like this.

    One is a licensing restriction, i.e., either Infragystics or some other party whose technology is being used imposed a license restriction on it being GUI client only.  However, that doesn't make a lot of sense to me unless there is some licensed technology in the bridge which is not apparent, since, after all, what is one going to use the Infragystics controls for except UI.

    The other is a CYA move reflecting the fact that 100% of the testing to date has been focused on the use of the bridge in UI so they don't want to risk people using it in ways that they haven't systematically tested because, of course, they will still get blamed if it doesn't work.  There is at least part of this which is sensible since there are some obvious ways in which the bridge has limitations, notably being multi-threaded on one side and single threaded on the other.  That shows up as a need in some UI situations, but it wouldn't surprise me that it was even more common in server-side applications.  Some of those are clearly not going to work and others might uncover problem areas that haven't been revealed by the UI-oriented testing.

    Hopefully, Ms. Chase will leap in here with her usual insightful and illuminating clarification, but in lieu of that I would consider a two pronged approach.  One prong is the one Mike suggests since that is the only one which is licensed and provides a short term predictable solution.  But, in parallel with that, I would consider prototyping the use in the context of a GUI client and find out whetther it works or not.  In that context, you can expose issues to tech support and maybe get us farther down the road of validating was would and wouldn't work in a non-UI context.  Moreover, anything you can make work that way gives you an exemplar to take to your sales rep and anyone you can buttonhole* at PSC to say "Look how useful this would be if you would let me use it on the AppServer".

    * buttonholing being somewhat less easy in the absence of an in-person Exchange.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • We appear to have struck you speechless!

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • No real improvement, that post...

  • > Can someone explain this to me?

    I think if that's really critical for you I'd discuss that with your sales rep.

    We are in the process of doing so.

    > I ran into this last week and Progress TS support says that in their

    > license

    agreement with Microsoft they have to prevent their AP's from using certain .NET components when not running on a GUI client.

    I must say that this surprises me as well. So far my understanding was that the limitations in the use of the .NET brige were to protect Prorgess' interest (who needs ODBC data server when ADO.NET is available) and the product stability (multi-threading).

    But hey, the product component is called "GUI for .NET". What (supported) use of the .NET bridge do you expect outside of the Graphical User Interface?

    The name to me is just a name and it hit what everyone was looking for. The ability to develop a great looking app that can compete with a .NET app. I did not expect the Appserver to prevent me from using a class such as FileInfo or any other "CLASS" written around .NET.

    Did you check the section from the OpenEdge EULA? (%DLC%\licenses\OpenEdge\OpenEdge_EULA.rtf)

    Yes, and I am still scratching my head as to why this is the case. I can understand the multi-threading but as my comment above stated preventing use of a .NET CLASS makes no sense.

    "2.  The products listed below include the “OpenEdge AVM to Microsoft .NET CLR intra-process communication” (“AVM to CLR Bridge” or the “Bridge”).  At this time, the allowable uses of the Bridge are restricted to developing or deploying Microsoft .NET Winforms User Interfaces for business applications using OpenEdge products, and for one-way usage of AVM calling the CLR (and not vice versa).   

    Any use of the Bridge other than as set forth in the previous paragraph is prohibited.  Additionally, the Bridge may not be used for multi-threaded processes."  

    > Basically, any control written in .NET will NOT run even though the

    > 3rd party control allows us to use the control anywhere we would like.

    >

    > Any insight would be great.

    If you want a technical solution that works, try COM-Interop (works fine for me). When there are classes in those products that are designed to be used on something like the OpenEdge AppServer (I wouldn't call those classes a Control, by the way) you should be able to create a simple wrapper in Visual Studio (including the free Express Editions) and build that as a COM-Accessible assembly. Works fine. Basically what you will be losing is strong typing and compile time validation.

    But I'm with you. Now with the state of the GUI for .NET I believe time has come for native access to .NET on the AppServer or WebSpeed agent (and TTY client). There's far more in the .NET framework that's nice than just GUI components.

    Agreed and Thanks for the response/input. Take care

  • I guess so.

  • I can understand licensing restrictions if that is the case with Infragistics but other 3rd party classes also do not work. Any .NET call on the Appserver is being prevented.

  • Besides, the Infragystics set is all UI, so it doesn't make any sense on the AppServer.  That's why I theorized some licensed technology which is not apparent to us.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • Is there actually a Microsoft license involved?  Aren't the ones used just the standard stuff that comes with Windows or the .NET framework download?

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com

  • According to the tech support rep there is a Microsoft license issue. She was going to do some homework and get back to me.