If you don't see them I think you're just not looking or maybe you should
give one a try yourself and see how easy it really is. And that one will
lead to more for you and the for good of your company.
Personally, from real deployed experience I think putting the browser in the
mix for corporate development just adds more code which adds more potential
for bugs when it isn't needed at all. For the wide world of retail users
and non-MS OSes the browser and the UBIK javascript definitely has it's
important place, but for corporate deployment where you know that the users
have the framework, as your post implies, an IE window is often just
overhead.
So now it's called "Smart Client" and there's a new MSDN dev center for it,
but since v1.0 we've had the ability to do "AutoDeploy" with binary
Remoting. The assemblies sit in an IIS VDir and are called over http and
when the are called they just deploy and run... and with Remoting you get a
nice performance boost over XML-heavy web services. (Pick up "Advanced .Net
Remoting" - C# or VB versions - by Ingo Rammer. After the first few
chapters you'll see that remoting really isn't all that tough)
Yes, SmartClient/AutoDeploy is for corporate solutions and you have to use
strongnaming and you have to get the desktop user permissions set with an
msi or other tactic to allow the apps to dowload and run, but it far
outshines adding the surface area of IE code and you get a "real" app.
Change the version and the users get it automatically.
Case history (you wanted to know if anyone was really doing it):
I took over a very mature VB6 app used concurrently by 40+ users on both
coasts, it used DCOM against a server process for intelligent multiuser task
scheduling, LeadTools for graphics and loads of "Rocky method" object
manipulation. It was very well coded by my predecessor but with all that it
had, and with the fact that the users always wanted more it was not only a
full 1024x768 main screen but it also at the dll limit of VB6. It could
take no more.
But back with the days of .Net1.0 we had two major features that needed to
be added, and so with a simple COM callable wrapper, a ten-line "loader"
called by the VB6 app, and a couple of SetParent api calls (or Setowner,
depending on whether you wanted the .Net gui element to be a "form" or to
embed itself like a control into a VB6 frame), we were able to add in
AutoDeploy forms "applets" with VB.Net that raised and responded to the main
app's COM events.
Updating the new features just meant updating the version numbers and
popping the new assemblies into the VDir. As stated, the applets used
remoting to talk to their specific functionalities' serverside equivalents
so a lot of maintenance was even better centralized.
By checking/downloading the applets during the first need for each object
and holding references for future use we got nice speed perception and the
users firmly believed that they were just running the main app, they could
not tell the difference.
I go into all this because it's a little frustrating to know that we all saw
this being done way back in the betas and we all read Billy Hollis' "Death
of the browser" in the MSDN VBasic dev center Columns years ago and yet when
given the choice of this simple and powerful option or sticking something in
a browser the browser seems to still be a habit that many folks don't want
to get out of. We don't have to wait for .Net2, it's all right in .Net1.
Granted, there are some little tricks to getting autodeploys with interop
and remoting to all work together (I put a few such tips on my little site
so that I wouldn't forget them) but truly, all it takes is trying it with
the .Net you have today to really amaze you (and your bosses).
Robert Smith
Kirkland, WA
www.smithvoice.com
. Once you get