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.
We appear to have struck you speechless!
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.
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?
According to the tech support rep there is a Microsoft license issue. She was going to do some homework and get back to me.
The infragistis.excel can be used to create a workbook without any ui interaction. It is much faster to create a workbook on the server and return back to the client the binary file if needed.
Crystal reports is another example where we can create a pdf on the server and return the binarybfile to the client.
I guess I am surprised that an Excel spreadsheet .xls or .xlsx file would be smaller than the data it contains. Sure, I can see doing all of the sort and select of the data on the server, but building the actual spreadsheet seems ... to me anyway ... like it would only make sense if the initiator was not the consumer.
Haven't people been doing Crystal for years without GUI for .NET?
Mind, I am on your side about thinking there are good server side uses ... except for the part about using a Windows server, of course!
She was going to do some homework and get back to me.
I'm curious. Hopefully Progress will post the whole story to the public.
I guess I am surprised that an Excel spreadsheet .xls or .xlsx file would be smaller than the data it contains.
That may or may not be the case and actually it might really depend a lot on the file format being transmitted over the wire. But then think about a WebSpeed process with a Web Browser as a client. You need to generate a document on the server.
Haven't people been doing Crystal for years without GUI for .NET?
It's not only about being possible to do so. It's also about HOW it's possible. The .NET integration into the language if by far superior to any external interface we've ever had in the language:
- no limitations or complicated issues with struct or array parameters
- access to enums
- strong typing and compile time validation
- garbage collection
and then think about the fact, that for a large part of the rest of the world .NET is simply available and many 3rd party vendors may stop supporting non .NET versions of their tools at some point. Well, I'm also aware that a large number of .NET Interfaces today are still only using COM-Interop (EA, Excel, Outlook, ...) but still that will probably change at some point as well and we still leverage the language benefits and GC when using a COM-Interop .NET interface.
And as Roger mentioned in a side note. It's not just about Excel and Crystal. The whole windows API can easily be accessed from .NET - I just rarely use external DLL procedures anymore. And the whole file handling is lovely in .NET. I'm just glad I haven't had to use INPUT FROM OS-DIR on the client for a while (System.IO.Directory is much simpler and appears much faster).
except for the part about using a Windows server, of course!
Since there were the 2003 versions of the servers my experience is that they have gotten much more accepted than before.
Roger Blanchard
Osprey Retail Systems, Inc.
404 County St.
New Bedford, MA 02740
Phone: (508) 992-1097
Fax: (508) 992-2716
Good points ... but I would still prefer not to be tied to Windows for the server, even if it is possible to make it work acceptably.
These day's I take any sort of agreement from your end as a
compliment
Whether or not I say so or it is apparent in my posts, I always think of you in complimentary terms. One might say it means that you are good enough to be worth arguing with.
Back when I was a grad student, my dissertation advisor was notorious for the way he marked up papers ... scared many of the students. If the paper was really good, it would come back absolutely covered in red ink. Some of this red ink was making corrections and suggestions on how to make the paper better yet ... it didn't hurt that he was a quite literate gentlement. But, some of the red ink would turn out to be compliments or ideas in the the flavor of "this reminds me of .... you might want to check that out". I.e., bottom line, he was treating one as a junior colleague and he was helping you to prepare a paper for publication. On the other hand, if it thought the paper was not very good, it might come back with a single note at the top saying something like "You can do better than this". That was really devestating ... not that it ever happened to me!
I just spoke with my rep who spoke with Shelley and basically it is not supported on the Appserver today. It is something they are thinking about for the future...maybe in V11.
Yes, but we knew that ... what they haven't told us is why.
All my rep told me is that is what an architectual design and that the clrbridge was not part of the Appserver. Maybe a Progress rep could chime in on this?