Is there any reason why microsoft is still sticking to COM technology(Office components are still COM).. when all that is done with COM is do-a-ble with .Net in a better and efficient manner
+12
A:
Because it would take a long time to completely rewrite Office, and it would inevitably result in large numbers of bugs and breaking changes.
SLaks
2010-02-02 14:29:03
I could hardly aggree on this.. I know equally sophisticated applications that has been ported to Net (Solidworks is one example).
TonyP
2010-02-02 14:36:55
I (and 7 upvoters) disagree. Rewriting a large system is _hard_. And Office is a _very_ **very** large system. In addition, Office is so complicated that it would be impossible to maintain 100% compatibility. (And it's so popular that compatibility really matters)
SLaks
2010-02-02 14:38:52
Just imagine the Mac commercials...
Mike C.
2010-02-02 14:42:54
I beleive, Solidworks is fairly complex application, and they ported it in (I beleive lessthan 6 months (probably with much lesser Developers at disposal than Microsoft))..I am not only impressed with their work, it also makes my life lot easier(seamless) when I integrate solidworks with other Net based application..
TonyP
2010-02-02 14:43:28
Why was this downvoted?
SLaks
2010-02-02 15:13:14
Solidworks was rewritten in .Net??? Perhaps the gui wrapper but rewriting all the internal engine in c# would take for ever
Martin Beckett
2010-02-02 15:31:04
+5
A:
One of the reasons for bloat in Microsoft products is the focus on backwards compatibility. Huge numbers of applications manipulate Office via COM, and they would all break, if MS dropped it.
COM integration was a huge pain the first time Microsoft's customers had to do it. Customers would absolutely freak out if they had to rewrite all of their apps to use another integration method.
That, or they'd just stick to old versions of Microsoft software, even after they went out of support. That would slow down the upgrade treadmill a lot, and MS doesn't want that.
Stephen Harmon
2010-02-02 14:40:38
That's not so true. It would be possible to write a wrapper that maintains the old API. (And it would be trivial compared to the rewrite itself)
SLaks
2010-02-02 14:41:19
Jacob is a wrapper around COM, and it's one of our biggest headaches. It's possible, but not without pain.
Stephen Harmon
2010-02-02 14:43:28
I would agree with Stephen,There are umpteen number of users using many generation of office suite. If Microsoft is ever to port Office to Net, and to maintain disparities.. that will be a un-fathamoble feat to achive in business terms.Wrappers are painfull; specially when you move your assemblies and components around machines; need to gen Strong Name keys,Adjusting execution/path privilages etc..
TonyP
2010-02-02 14:56:03
JACOB is the "Java-COM-Bridge." We use it to control Word and Crystal Reports with Java. Generally, it works well, but the occasional memory leak, or orphaned process, causes headaches.
Stephen Harmon
2010-02-02 17:15:43
+6
A:
Because using COM makes the component available to the widest number of consumers. If an API uses COM it can be consumed from VBScript, native code, etc, not just .Net. The new features of C# 4.0 make it relatively painless to call COM components from .Net.
Samuel Jack
2010-02-02 14:53:29