467,911 Members | 1,364 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,911 developers. It's quick & easy.

ActiveX Dead? Alternatives?

I'm a die hard c# developer, developing win32 and web based enterprise apps
for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an alternative
is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box) and
remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say will
meet the above requirements. It'll be developmed in Microsoft Visual C++.NET
using UNMANAGED code - as they do not want the .NET framework distrubuted to
the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?
Nov 17 '05 #1
  • viewed: 14004
Share:
21 Replies
Strath-Clyde wrote:
I'm a die hard c# developer, developing win32 and web based
enterprise apps for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an
alternative is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box)
and remote server "Communicate with a server" is so vague that we can't say anything about it.
What kind of communication? With what technology/abstraction level ?
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser


Whatever choice you make, 3 and 5 are antagonist IMHO. Although it is
possible to circumvent the browser's default security policy, it will get
you in endless distribution trouble unless you are in a very limited,
controled distribution system (but in that case, what is the use of
web-based app?). More important, it is against all and every principles of
security, and as a knowledgeable user, I would distrust strongely this kind
of solution.

Apart from that, I do not believe much in that kind of differences (You may
consider ActiveX as being "phased out"if you wish, it won't stop a correctly
written ActiveX do to it's job nicely). The most important point IMHO is the
level of expertise of the developement team, and with which technology they
are most at ease.

Arnaud
MVP - VC
Nov 17 '05 #2
Strath-Clyde wrote:
I'm a die hard c# developer, developing win32 and web based
enterprise apps for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an
alternative is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box)
and remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say
will meet the above requirements. It'll be developmed in Microsoft
Visual C++.NET using UNMANAGED code - as they do not want the .NET
framework distrubuted to the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?


Practially speaking, no. They could always make it a Java applet instead,
but that's a far worse choice IMO. If you're targeting IE only, it's
possible to host a .NET control in the browser, but then that requires the
framework.

Personally, I think they made the right call, given what you've outlined.

The path to a different solution is likely through challenging the
requirements. Who doesn't want the .NET framework on the clients? Is that
the end-users speaking, or is it the developer who already chose the
Acitve-X solution?

-cd
Nov 17 '05 #3
Thanks for the replies.

1) Sorry for the vague project outline. I'm afraid if I delve too much into
it, I'd be violating a few policies. We develop enterprise apps for the
healthcare industry, therfore, describing the server communication will
reveal too much as this stage.

2) I understand the security issues but can not explain them or use them to
defend my stance (to the team I mean). I know that we will have a problem
reading/writing to the file system but I need to prove it not rant and and
rave about it.

3) Our target audience is very controlled, though it will be phased to a
more general audience soon. Being so, an activex control with severe
permissions to the underlying OS "might" be viable but I doubt it. I'm the
only developer in a group of 6 that has this nagging feeling that we're
approaching this solution the wrong way.

4) The .NET Framework is not a viable solution to install for our clients -
straight from the client's mouth.

To finialize, the pressing issue I have is the direction Microsoft is taking
regarding ActiveX components as described by my outline. Without using the
framework, is activex the only way to go (java is not an option).

Thanks again.
"Strath-Clyde" wrote:
I'm a die hard c# developer, developing win32 and web based enterprise apps
for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an alternative
is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box) and
remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say will
meet the above requirements. It'll be developmed in Microsoft Visual C++.NET
using UNMANAGED code - as they do not want the .NET framework distrubuted to
the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?

Nov 17 '05 #4

For what it's worth, I know of several companies in different
industries that refuse to allow .Net on their corporate machines.
There is resistance, although I wouldn't presume to try to quantify it.
"Strath-Clyde" <St*********@hotmail.com> wrote in message
news:07**********************************@microsof t.com...
Thanks for the replies.

1) Sorry for the vague project outline. I'm afraid if I delve too much
into
it, I'd be violating a few policies. We develop enterprise apps for the
healthcare industry, therfore, describing the server communication will
reveal too much as this stage.

2) I understand the security issues but can not explain them or use them
to
defend my stance (to the team I mean). I know that we will have a problem
reading/writing to the file system but I need to prove it not rant and and
rave about it.

3) Our target audience is very controlled, though it will be phased to a
more general audience soon. Being so, an activex control with severe
permissions to the underlying OS "might" be viable but I doubt it. I'm
the
only developer in a group of 6 that has this nagging feeling that we're
approaching this solution the wrong way.

4) The .NET Framework is not a viable solution to install for our
lients -
straight from the client's mouth.

To finialize, the pressing issue I have is the direction Microsoft is
taking
regarding ActiveX components as described by my outline. Without using
the
framework, is activex the only way to go (java is not an option).

Thanks again.
"Strath-Clyde" wrote:
I'm a die hard c# developer, developing win32 and web based enterprise
apps
for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an
alternative
is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box) and
remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say
will
meet the above requirements. It'll be developmed in Microsoft Visual
C++.NET
using UNMANAGED code - as they do not want the .NET framework distrubuted
to
the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?

Nov 17 '05 #5
Withheld wrote:
For what it's worth, I know of several companies in different
industries that refuse to allow .Net on their corporate machines.
There is resistance, although I wouldn't presume to try to quantify it.

Well I guess after Longhorn and WinFX they will have to live with it. :-)

--
Ioannis Vranos
Nov 17 '05 #6
Carl Daniel [VC++ MVP] wrote:
Practially speaking, no. They could always make it a Java applet instead,
but that's a far worse choice IMO. If you're targeting IE only, it's
possible to host a .NET control in the browser, but then that requires the
framework.

Personally, I think they made the right call, given what you've outlined.

The path to a different solution is likely through challenging the
requirements. Who doesn't want the .NET framework on the clients? Is that
the end-users speaking, or is it the developer who already chose the
Acitve-X solution?

How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
the 64-bit IE that it contains?
Still a .NET approach sounds a more reasonable solution to me, given the
..NET x64.

--
Ioannis Vranos
Nov 17 '05 #7
Ioannis Vranos wrote:
Still a .NET approach sounds a more reasonable solution to me, given the
.NET x64.

If such an approach exists.

--
Ioannis Vranos
Nov 17 '05 #8
Ioannis Vranos wrote:
Carl Daniel [VC++ MVP] wrote:
Practially speaking, no. They could always make it a Java applet
instead, but that's a far worse choice IMO. If you're targeting IE
only, it's possible to host a .NET control in the browser, but then
that requires the framework.

Personally, I think they made the right call, given what you've
outlined. The path to a different solution is likely through challenging
the
requirements. Who doesn't want the .NET framework on the clients? Is
that the end-users speaking, or is it the developer who already
chose the Acitve-X solution?

How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
the 64-bit IE that it contains?


No idea.

I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit Windows
just for compatibility with all the IE plugins out there...

-cd
Nov 17 '05 #9
Carl Daniel [VC++ MVP] wrote:
No idea.

I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit Windows
just for compatibility with all the IE plugins out there...

Yes, perhaps there will be one. For backwards compatibility with all the
vulnerabilities out there. :-)

--
Ioannis Vranos
Nov 17 '05 #10
Strath-Clyde wrote:
Thanks for the replies.

1) Sorry for the vague project outline. I'm afraid if I delve too much into
it, I'd be violating a few policies. We develop enterprise apps for the
healthcare industry, therfore, describing the server communication will
reveal too much as this stage.

2) I understand the security issues but can not explain them or use them to
defend my stance (to the team I mean). I know that we will have a problem
reading/writing to the file system but I need to prove it not rant and and
rave about it.
You can read/write to the file system (I have an IE hosted activeX
control that does just that). You'll just have that annoying "Allow
Blocked Content" thing every time it comes up, thanks to the new
security in Windows XP SP2. You may also have to mark safe (e.g. LIE
about) the ActiveX control with a registry key to prevent a second
annoying dialog. You may have some security zone problems as well; the
websites in question will probably have to be added to the local
machines trusted sites list.

But, as I said, I have full file system access from an ActiveX control,
so unfortunately for you I have to report that it is possible, even
under XPSP2. Who knows about Win64 and Longhorn though?
3) Our target audience is very controlled, though it will be phased to a
more general audience soon. Being so, an activex control with severe
permissions to the underlying OS "might" be viable but I doubt it. I'm the
only developer in a group of 6 that has this nagging feeling that we're
approaching this solution the wrong way.

4) The .NET Framework is not a viable solution to install for our clients -
straight from the client's mouth.

To finialize, the pressing issue I have is the direction Microsoft is taking
regarding ActiveX components as described by my outline. Without using the
framework, is activex the only way to go (java is not an option).


Java would be nicer than ActiveX IMHO (having developed the heinous
application I mention above), but I doubt you'd be able to access the
file system at all in any case.

Given your requirements, ActiveX is the only possibility I can think of.

Tom
Nov 17 '05 #11
From what I heard windows 64 bit has both the 32 and 64 bit versions of IE
on it.

"Carl Daniel [VC++ MVP]" <cp*****************************@mvps.org.nospam >
wrote in message news:%2***************@TK2MSFTNGP10.phx.gbl...
Ioannis Vranos wrote:
Carl Daniel [VC++ MVP] wrote:
Practially speaking, no. They could always make it a Java applet
instead, but that's a far worse choice IMO. If you're targeting IE
only, it's possible to host a .NET control in the browser, but then
that requires the framework.

Personally, I think they made the right call, given what you've
outlined. The path to a different solution is likely through challenging
the
requirements. Who doesn't want the .NET framework on the clients? Is
that the end-users speaking, or is it the developer who already
chose the Acitve-X solution?

How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
the 64-bit IE that it contains?


No idea.

I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit
Windows just for compatibility with all the IE plugins out there...

-cd

Nov 17 '05 #12
Altman wrote:
From what I heard windows 64 bit has both the 32 and 64 bit versions of IE
on it.

Yes it is included. However I was not sure ActiveX could still run on it
, especially an ActiveX with file system access since this is a
relatively low level functionality, and do not know what also happens
with IE 64 vs ActiveX.
More info on the latest Windows XP RC2:

http://www.winsupersite.com/reviews/...4_preview2.asp

--
Ioannis Vranos
Nov 17 '05 #13
>> From what I heard windows 64 bit has both the 32 and 64 bit versions
of IE on it.

IV> Yes it is included. However I was not sure ActiveX could still run
IV> on it , especially an ActiveX with file system access

Since ActiveX may be written in unmanaged code, how are you going to control
whether it accesses the file system or not?

Also, what is the security risk if you are running the ActiveX from a local
storage or approve it after downloading from the Internet?

--
Serge
Nov 17 '05 #14
Serge Baltic wrote:
IV> Yes it is included. However I was not sure ActiveX could still run
IV> on it , especially an ActiveX with file system access

Since ActiveX may be written in unmanaged code, how are you going to
control whether it accesses the file system or not?

What I meant is that it is a file system of 64-bit OS, and XP x64
unaware applications with such low level access may not work under XP
64. As you can see in the link provided, antivirus programs do not work
under XP x64 RC2 for example:

"n addition to presenting this small subset of available x86
applications, I should note that XP x64 is incompatible with entire
classes of applications, including antivirus applications and security
suites (but not, curiously, antispyware solutions). Microsoft tells that
these antivirus applications won't work in XP x64 because they access
the system's kernel, which is 32-bit code in XP 32-bit but 64-bits in
x64. However, all major AV vendors, including Symantec and McAfee, are
allegedly working on x64-compatible upgrades."

Also, what is the security risk if you are running the ActiveX from a
local storage or approve it after downloading from the Internet?

I am not against ActiveX in particular, I do not know much about the
technology anyway. My guess is, it is using Win32 API and thus it is
restricted to it.

--
Ioannis Vranos
Nov 17 '05 #15
Ioannis Vranos wrote:
I am not against ActiveX in particular, I do not know much about the
technology anyway. My guess is, it is using Win32 API and thus it is
restricted to it.


Any self-registering COM DLL qualifies as an Active-X control. As such
there's virtually no limit to what such a control might do (including host
the CLR and run managed code).

-cd
Nov 17 '05 #16
Your client has specified a Microsoft non-.NET non-Java platform.
ActiveX is your only option. From a developer's perspective, it's older,
more complex, and less desirable to work with than .NET. But, it will be
supported and it's an adequate functional solution.

Often there's a conflict when developers want to use the latest and
greatest technology and clients want to stick with older technology
that's more widely deployed and entrenched that requires less upgrades.

It's easy to understand the perspective of each side; unfortunately,
business needs trump developer preference. In a situation like this, the
developers have to use the older and less sexy technology.

Strath-Clyde wrote:
Thanks for the replies.

1) Sorry for the vague project outline. I'm afraid if I delve too much into
it, I'd be violating a few policies. We develop enterprise apps for the
healthcare industry, therfore, describing the server communication will
reveal too much as this stage.

2) I understand the security issues but can not explain them or use them to
defend my stance (to the team I mean). I know that we will have a problem
reading/writing to the file system but I need to prove it not rant and and
rave about it.

3) Our target audience is very controlled, though it will be phased to a
more general audience soon. Being so, an activex control with severe
permissions to the underlying OS "might" be viable but I doubt it. I'm the
only developer in a group of 6 that has this nagging feeling that we're
approaching this solution the wrong way.

4) The .NET Framework is not a viable solution to install for our clients -
straight from the client's mouth.

To finialize, the pressing issue I have is the direction Microsoft is taking
regarding ActiveX components as described by my outline. Without using the
framework, is activex the only way to go (java is not an option).

Thanks again.
"Strath-Clyde" wrote:

I'm a die hard c# developer, developing win32 and web based enterprise apps
for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an alternative
is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box) and
remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say will
meet the above requirements. It'll be developmed in Microsoft Visual C++.NET
using UNMANAGED code - as they do not want the .NET framework distrubuted to
the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?

Nov 17 '05 #17
C> Any self-registering COM DLL qualifies as an Active-X control.

Quite the opposite ‚ÄĒ any ActiveX control is a COM DLL. Not every COM DLL
is an ActiveX control, though.

--
Serge
Nov 17 '05 #18
>> Since ActiveX may be written in unmanaged code, how are you going to
control whether it accesses the file system or not? IV> What I meant is that it is a file system of 64-bit OS, and XP x64
IV> unaware applications with such low level access may not work under
IV> XP 64. As you can see in the link provided, antivirus programs do
IV> not work under XP x64 RC2 for example:

Accessing filesystem is not that low level considered in the article. They
talk about the drivers, mostly. Just CreateFile will definitely go on to
live, at least for some time.
Also, what is the security risk if you are running the ActiveX from a
local storage or approve it after downloading from the Internet?

IV> I am not against ActiveX in particular, I do not know much about the
IV> technology anyway. My guess is, it is using Win32 API and thus it is
IV> restricted to it.

Yes. But WinAPI is no way low-level enough, from this point of view.

--
Serge
Nov 17 '05 #19

"Tommy Vercetti" <ve*********@hotmail.com> wrote in message
news:uI**************@TK2MSFTNGP09.phx.gbl...
SNIP>
It's easy to understand the perspective of each side; unfortunately,
business needs trump developer preference. In a situation like this, the
developers have to use the older and less sexy technology.


Actually, it's not unfortunate at all. If developers had their way,
business people wouldn't be able to do anything without a fleet of geek to
help them. This constant "use the sexy new technology" drive does not make
anything better, and if it takes a year or two to really become proficient,
nobody's good at anything because by the time they really understand a
technology, there's a newer, sexier one beckoning. Sexier technology is the
siren song that lures developers into a constant state of mediocrity.

-Michael Viking
Nov 17 '05 #20
Serge Baltic wrote:
Any self-registering COM DLL qualifies as an Active-X control.


Quite the opposite - any ActiveX control is a COM DLL. Not every COM
DLL is an ActiveX control, though.


http://msdn.microsoft.com/library/de...x/controls.asp

<quote>
In other words, a control, at the very least, is some COM object that
supports the IUnknown interface and is also self-registering.
</quote>

You're right, not every COM object is an Active-X control.

I'm also right - every self registering COM object IS an ActiveX control.

Note that to be an OLE Control, which is what most people think of when they
hear "Active X Control" requires much much more.

-cd
Nov 17 '05 #21
Here is a quote from MS Longhorn site

What is the future of COM, OLE and in-place activation?

All of COM and OLE that you've come to know and love will live on in
Longhorn, although it won't be extended. COM and OLE aren't "dead," but they
are "done."


"Strath-Clyde" <St*********@hotmail.com> wrote in message
news:85**********************************@microsof t.com...
I'm a die hard c# developer, developing win32 and web based enterprise
apps
for last few years.
The development team I'm on is going down a path I feel is wrong.
I scoping out the web to knock their solution but of course, an
alternative
is needed...

1) We need a complex client application
2) This client app will need to communicate with a local (same box) and
remote server
3) It will need to read/write to the local file system
4) Easy to deploy with little footprint
5) Needs to be web based - viewable in a browser

The development has decided to create an ActiveX client that they say will
meet the above requirements. It'll be developmed in Microsoft Visual
C++.NET
using UNMANAGED code - as they do not want the .NET framework distrubuted
to
the clients.

I think this is the wrong approach as ActiveX is being phased out.

Are they any alternatives?

Nov 17 '05 #22

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by StrathClyde | last post: by
11 posts views Thread by binarybana | last post: by
5 posts views Thread by ESPN Lover | last post: by
7 posts views Thread by Rob T | last post: by
24 posts views Thread by Rob R. Ainscough | last post: by
6 posts views Thread by fantum | last post: by
12 posts views Thread by better_cs_now | last post: by
1 post views Thread by Bradley Plett | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.