ActiveX死了？备择方案？ [英] ActiveX Dead? Alternatives?
问题描述
我很难成为c＃开发人员，开发win32和基于Web的企业应用程序
过去几年。
开发团队我正在进行我觉得这是错误的。
我在网上寻找解决方案，但当然，需要另外一个
......
1）我们需要一个复杂的客户端应用程序
2）此客户端应用程序需要与本地（同一个框）和
远程服务器进行通信
3）它需要读/写本地文件系统
4）易于部署，占用空间小
5）需要基于Web - 可在浏览器中查看
开发人员已决定创建一个ActiveX客户端，他们说这将是满足上述要求的
。它将使用UNMANAGED代码在Microsoft Visual C ++ .NET
中进行开发 - 因为他们不希望.NET框架被分配给客户。
我认为这是错误的方法，因为ActiveX正在逐步淘汰。
他们有其他选择吗？
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?
推荐答案
Strath-Clyde写道：
Strath-Clyde wrote:
我是一个很难的c＃开发人员，在过去的几年里开发了基于web和web的企业应用程序。我正在开发的团队正走在一条我觉得错误的道路上。
我在网上寻找解决方案，但当然，还需要一个替代方案......
1）我们需要一个复杂的客户端应用程序
2）此客户端应用程序需要与本地（同一个盒子）和远程服务器进行通信
与服务器"是如此模糊，以至于我们无法说出任何事情。
什么样的沟通？什么技术/抽象级别？
3）它需要读/写本地文件系统
4）易于部署，占用空间小*
5）需要基于网络 - 可在浏览器中查看
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
无论你做出什么选择，3和5都是对手恕我直言。虽然它可以绕过浏览器的默认安全策略，但是除非你的数量非常有限，否则你将无法获得
，这是非常有限的，
控制分发系统（但在这种情况下，
基于网络的应用程序有什么用？）。更重要的是，它违背了安全的所有原则，作为一个知识渊博的用户，我会非常不信任这种解决方案。
除此之外，我对这种差异并不太相信（你可能会认为，如果你愿意，可以将ActiveX视为逐步淘汰，它不会停止一个正确的
编写的ActiveX可以很好地完成它的工作。最重要的一点是IMHO是开发团队的专业知识水平，以及他们最优惠的技术。
Arnaud
MVP - VC
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
Strath-Clyde写道：
Strath-Clyde wrote:
我很难c＃开发人员，开发win32和基于Web的企业应用程序，这几年。
我正在开发的团队走上了一条我觉得错误的道路。
我在网上找到了敲开他们的解决方案当然，还需要一个替代方案......
1）我们需要一个复杂的客户端应用程序
2）这个客户端应用程序需要与本地通信（同一个盒子）
和远程服务器
3）它需要读/写到本地文件系统
4）易于部署，占用空间小*
5）需要基于Web - 可在浏览器中查看
开发已决定创建一个他们说
将满足上述要求的ActiveX客户端TS。它将在Microsoft使用UNMANAGED代码在Visual C ++ .NET中开发 - 因为他们不希望将.NET
框架分发给客户端。
我认为这是ActiveX的错误方法正在逐步淘汰。
它们是否有其他选择？
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?
实际上，没有。他们总是可以把它变成一个Java小程序，
但这是一个更糟糕的选择IMO。如果你只针对IE浏览器，那么可以在浏览器中托管.NET控件，但那需要
框架。
就个人而言，我认为他们做出了正确的决定，给出了你所概述的内容。
通往挑战不同解决方案的途径
要求。谁不想在客户端上使用.NET框架？那是最终用户说的，或者是开发人员已经选择了
Acitve-X解决方案吗？
-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
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
感谢您的回复。
1）对于模糊的项目大纲，我们深表歉意。我担心如果我钻研太多了，我会违反一些政策。我们为
医疗行业开发企业应用程序，因此，描述服务器通信将在这个阶段显示过多的b $ b。
2）我理解安全问题，但无法解释或使用它们来支持我的立场（对于我所说的团队）。我知道我们会有一个问题
读/写文件系统但是我需要证明它不是咆哮而且
对它赞不绝口。
3）我们的目标受众是非常有控制的，尽管很快将分阶段推广给更多普通观众。因此，具有对底层OS的严格
权限的activex控件可能。是可行的，但我对此表示怀疑。我是一个6人小组中唯一的开发人员，他有这种唠叨的感觉，我们以错误的方式接近这个解决方案。
4）.NET Framework不是一个可行的解决方案，可以为我们的客户安装 -
直接来自客户的口。
为了最终完成，我所面临的紧迫问题是微软正在按照我的大纲描述的方式获取有关ActiveX组件的
。不使用
框架，activex是唯一的方法（java不是一个选项）。
再次感谢。
Strath-Clyde写道：
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:
过去几年我很难成为c＃开发人员，开发win32和基于Web的企业应用程序。
开发团队我是我正在走上一条路，我觉得这是错误的。
我在网上寻找解决方案，当然，还需要一个替代方案......
1）我们需要一个复杂的客户端应用程序
2）这个客户端应用程序需要与本地（同一个盒子）和远程服务器进行通信3）它需要读/写本地文件系统
4）易于部署，占地面积小
5）需要基于Web - 可在浏览器中查看
开发已决定创建一个ActiveX客户端，他们说将<满足以上要求。它将使用UNMANAGED代码在Microsoft Visual C ++ .NET中开发 - 因为他们不希望.NET框架被分配给客户端。
我认为这是ActiveX的错误方法正在逐步淘汰。
它们有其他选择吗？
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?
这篇关于ActiveX死了？备择方案？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
