 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / March 2005ActiveX 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? > I'm a die hard c# developer, developing win32 and web based > enterprise apps for last few years. [quoted text clipped - 5 lines] > 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 > I'm a die hard c# developer, developing win32 and web based > enterprise apps for last few years. [quoted text clipped - 17 lines] > > 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 > 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 [quoted text clipped - 7 lines] > 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.  SignatureIoannis Vranos > Still a .NET approach sounds a more reasonable solution to me, given the > .NET x64. If such an approach exists. SignatureIoannis Vranos >> 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 [quoted text clipped - 10 lines] > 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 > 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. :-) SignatureIoannis Vranos From what I heard windows 64 bit has both the 32 and 64 bit versions of IE on it. >>> 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 [quoted text clipped - 17 lines] > > -cd > 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/windowsxp_x64_preview2.asp SignatureIoannis Vranos >> 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? SignatureSerge > 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. SignatureIoannis Vranos > 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 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. SignatureSerge >> 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/default.asp?url=/workshop/components/activex/c ontrols.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 >> 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. SignatureSerge 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. > I'm a die hard c# developer, developing win32 and web based enterprise apps > for last few years. [quoted text clipped - 17 lines] > > Are they any alternatives? 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. > Thanks for the replies. > [quoted text clipped - 55 lines] >> >> Are they any alternatives? > 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. :-) SignatureIoannis Vranos > Thanks for the replies. > [quoted text clipped - 7 lines] > 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 [quoted text clipped - 8 lines] > 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 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. > Thanks for the replies. > [quoted text clipped - 44 lines] >> >>Are they any alternatives? 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 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." > I'm a die hard c# developer, developing win32 and web based enterprise > apps [quoted text clipped - 21 lines] > > Are they any alternatives?
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.