HTML -> Smart client (communications)

[Marc Gravell]

I need to tie together two apps; a thin (HTML) client and a smart-client
(running on the user's machine) deployed with click-once.

My question is: does anybody know of a good way to communicate between the
two?

The thin client is HTML generated from an asp web-site (not asp.net) [can
easiy be edited as required]
The smart client is C# / win form / .Net 2
The user is not an administrator, and ideally few or no changes would be
required
Must also work on internet zone to support extranet usage

Current ideas:
1: HREF to a second .application with params on query-string; this exe
accepts the params and uses remoting to talk to the main exe (and then
exits)
2: (preferred option) Smart-client starts up a simple web-server (e.g.
HttpListener or similar); thin client posts to
http://localhost/somewhere?someparams [problem: this triggers cross-domain
security warnings; don't want to have to trust the web site]
3: Some kind of control embedded on the page? Not sure if this can be
deployed easily? (don't want COM overhead)
4: other?

At the minimum I need to be able to send data in the forwards only
(html->smart) direction. Being able to process the response would be a "nice
to have". I do not need to be able to push from the smart-client to the web
page (thankfully).

Any suggestions? Surely somebody has had to do something similar?

Many thanks in advance,

Marc

 

[Alec Yu]

If you host a winform control in a web page, javascript may call
methods of the control, and the control may start up other parts of
your smart client.

 

[Marc Gravell]

Wow - I'd almost given up ;-p Much appreciated.

OK - and how would I do that? Via <OBJECT CODEBASE="...">...</OBJECT> or
something? Or would I need to expose a (client-registered) COM CID / PID?

Any more of an example?

Marc

 

[Alec Yu]

As .NET system.windows.forms.Control implements an ActiveX control, it
is theoratically that you may deploy your WinForm control in this way:
<object id="MyControl" classid="MyAssembly.dll#MyNamespace.MyClass"
width="320" height="240"></object>
where MyAssembly.dll is in the same web directory of your web page.
Then you may script the control by:
<script>
document.all("MyControl").DoSomething();
</script>

However, there are some tips that you must take in mind:
1. It won't install .net framework for you. If somebody with no .NET
framework installed browse your web page, nothing will happen except a
red X.
2. The control will be run in a sandbox. There are lots of security
restriction for code running in a sandbox. You will probably encounter
lots of permission exceptions. Microsoft's tricks to leverage this
issue is simply not comfortable for product development.
3. Somebody posted that the scripting trick will be broken if .NET 2.0
installed on the client machine.

I have a solution for all of these issues: (but it will cost you some
bucks, for I spent weeks to develop it)
http://en.ezlag.com/site/335/lagloadernet.aspx

 

[Marc Gravell]

Interesting; does your solution require installation / configuration at the
client? If so, doesn't that represent a security risk (i.e. an "elevate me
to full trust" back door that could be attacked by other sites?) And if not,
how much of a hack is it? I.e. would it be a complete nightmare to support
if it stopped working due to MS tightening the runtime?

Marc

 

[Alec Yu]

Its client side requirements are: you are running 32-bit Windows and IE
5.x/6.x (and probably 7.x).
And of course .NET framework can be installed in such environment (but
not required to be pre-installed).

Security is an issue, right, and I know that.

There are two additional files required to be on the server side (IIS,
Apache, or any other web server),
one of them is a 7z decompressor dll packed in a cab, and the other is
"DotNetHost.7z", less than 300KB.
The 7z archive is always asked to be in the same web directory of the
ActiveX control, and the ActiveX control
doesn't work alone.

As my sample page contains a demo version of LagLoader.NET to do speech
to text smart client demo,
that demo version comes with a DotNetHost.7z which is functional only
at my own web sites.
So even if you get all the server side LagLoader.NET files from my
sample page, it won't work other where else.
So is the trial version, which is functional only at your local file
system or http://localhost (but with full trust mode on).
Only if .NET assemblies come from my web sites (in the demo case) or
from your local side (in the trial version case),
LagLoader.NET will run the smart client code.

The lite edition provides only partial trust mode, like Microsoft's
sandbox plus .NET check/install functionaility
and scripting (for .net 2.0), so it harms nothing.

The real concern is the professional edition, which gives you the power
of fully trusted.NET smart clients.
LagLoader.NET will check codebase attribute of the OBJECT tag and the
path of the .NET assembly
containing the requested WinForm control class.
If they are not from the same web site or not both from your local file
system, it will stop to work.

There is no back door or undocumented MS tricks used.
Raymond Chen told, we can't host an ActiveX container in an ActiveX
control hosted in an ActiveX container,
and we can't host multiple .NET framework runtime versions in the same
executable instance.
What he told is theoratically true, and I am not going to fight against
that theorem by back doors.
I work around these issues by Win32 API SetParent(HWND),
making ActiveX control LagLoader.NET the parent window of .NET WinForm
control running in my Win32 hosting exe.
Why should it stop working in the future?
If you use WebBrowser control in your application, while the control an
ActiveX one,
there is an iexplore.exe started up for that control.
For Raymond Chen's theorem to hold,
the WebBrowser control and LagLoader.NET should work in the same way.

The hosting exe at the client side comes with the 7z archive downloaded
by the ocx.
It is the hosting exe deciding whether your smart client may be run
fully trusted or partial trusted,
just as Microsoft's ieexec.exe decided to run every smart client in a
partial trust sandbox.
I decided that partial trust is simply not enough for many works to be
done,
so I created a full trusted environment for smart clients.
If somebody thinks LagLoader.NET will do anything harmful to their
security,
they have the choice to refuse to install it when IE prompts them to
install the ActiveX control.

I am planing an update to my LagLoader.NET product activation process,
you may choose to lock your purchased copy of LagLoader.NET to your web
sites,
so that nobody else can pirate them and deploy them somewhere else.

Also, I am going to give a later version of LagLoader.NET the
capability to determine
if DirectX runtime or other system COM stuffs are installed.