ASP.NET and HTAs

  • Thread starter Thread starter Bryan Lynn
  • Start date Start date
B

Bryan Lynn

I am looking to create a standard ASP.NET web application, but present
it to the end user via a HTA. This will allow me to customize my own
UI, do some cross domain scripting, and bypass some of the browser's
security settings so I can access the registry, local file system, and
such (which I need to do).

Does anyone (especially anyone from MS) have a position on HTAs? Is it
an emerging/declining/core technology? I know the Windows Add/Remove
Programs app is implemented as a HTA -- are there any other examples of
core Windows apps running as HTAs?

I love the power HTAs offer but don't want to go down that road if HTAs
do not have a future.

Thanks for any input...
 
Sending a HTA to a user via the HTML protocol will not give you the same
level of reduced security as you got when a user open a HTA directly from
his hard drive.

I'm not sure about what you want to achieve by using ASP.NET to send a HTA
instead of a HTML to an user but if I were you, I wouldn't be so optimistic
about HTA.

S. L.
 
Clinton,
Please explain -- you've been thinking along my lines (i.e., wondering
about the positioning of HTAs) or along Sylvain's lines (i.e., stay
away from HTAs)?
 
Sorry Brian. We've discussed the use of HTA as useful but got distracted and
did not follow up anymore -- as of yet -- to determine all of the
ramifications. What I do know is that Microsoft's Channel Definition Format
(CDF) and other older implementations still function in IE so Microsoft
seems to have a long term commitment in that regard but they do drop further
developement and support so for any initiative that doesn't cath fire with
one book of matches or is so hated by the Microsoft haters that they simply
choose to stop spitting in the wind.

It is interesting to note that the same haters club then pick and choose the
parts of Microsoft's technology they like and the W3C finally gives it their
blessing, i.e. innerText, XmlHttpRequest and so on.

Smart Client development is Microsoft's goal. I don't know if that's
pertinent for you but that is what we are considering now as the entire
software industry has adopted web services where the goal is integration and
interoperability.

<%= Clinton Gallagher
 
Thanks for your thoughts Clinton. Yeah, I'm aware of the smart client
direction and that's something we've considered.

I've long considered HTAs as an under utilized platform to deliver
solutions on. I love the ease of deployment as you don't have to worry
about the installation headaches. In addition, when properly written,
HTAs can have a windows like interface that users are already familiar
with and still interact with the local file system/registry if needed.

I'm just curious if HTAs are really being used out there. I know the
Windows Add/Remove Programs component is implemented as a HTA -- are
other Windows components implemented the same way? If we choose a HTA
platform for a product, will that scare away potential customers???
 
Just in case you come back -- here -- I think I am changing my mind about
hta longevity as Microsoft uses hta quite frequently noting all of their
MSDN developer resources have been using hta for at least the last year. I
didn't even realize this until I started using the file system to dig
through several I have been receiving.

I wonder how secure hta is?

<%= Clinton Gallagher
 
Good info Clinton -- thanks!

By their nature, HTAs are not secure. HTAs essentially run like IE w/
out any of IE's security constraints -- that's the whole point of them.
Because they bypass IE's security model, this allows you to use HTML
and script (vb script, jscript, etc) to build rich "web" apps that can
interact with the user's file system, registry, etc (just like real
applications do).

So from a security standpoint, HTAs are like EXEs. HTAs are trusted
applications that should only be run from trusted sources -- and b/c of
this "trust", they have full permissions much like an EXE.
 
Hi,

HTA's are a very good model for client UI, the security is not an issue
- it's "automatic". They allow you to create W3C compliant end-user apps
with zero deployment.

The big downside is that there's zero revenue for Microsoft from their
use, so obviously Microosft is not going to be pushing their use.

It's important the original poster understands the difference between
ASP.NET and HTAs, in that ASP is for client/server apps and HTAs are for
local apps. e.g. you would not use HTAs for a world-wide-web site
providing a nation-wide telephone directory. Conversely, you would not
use ASP.NET to provide a mobile sales rep with a CD-RW backup facility
for their laptop - you give them an HTA.

Smart-clients are a joke in all but 1 in 1000 real-world scenarios. A
simple example is the services I currently run can be used from hotel
rooms, internet cafe's and broken down home-user Win95 computers, Linux
boxes, Mac boxes, internet TVs and handhelds. See how well your lame-ass
"smart-client" app works on these systems??

The future is the W3C.

The way I write apps, is to write them once and never deploy them.
People simply type in "www.mydomain.com/myapp" and of they go. They get
superior client-side interaction from W3C compliant DOM and it's way
ahead of anything you can do in .NET with WinForms/Avalon (or whatever).
 
Back
Top