Is COM really dead?
-
:suss: What i know is COM will no longer be used in .NET. Although we can create COM components but in future developments COM is not the standard way of create reusable components. is it so? @ish@
-
:suss: What i know is COM will no longer be used in .NET. Although we can create COM components but in future developments COM is not the standard way of create reusable components. is it so? @ish@
Yes, I think this will be so in the long run. But it will take several years I think .NET itself still uses COM+ for some parts but I get the impression that eventually it will all be replaced by native .NET. I suspect Windows itself and perhaps some MS apps. wil still use COM internally but application developers will write .NET components for new stuff. Kevin
-
Yes, I think this will be so in the long run. But it will take several years I think .NET itself still uses COM+ for some parts but I get the impression that eventually it will all be replaced by native .NET. I suspect Windows itself and perhaps some MS apps. wil still use COM internally but application developers will write .NET components for new stuff. Kevin
Kevin McFarlane wrote: I get the impression that eventually it will all be replaced by native .NET If you want to use the shell, you have to use the COM shell interfaces. .NET classes exposing shell features do exactly that for us, but in the end if the COM shell objects are badly installed, or badly registered, it won't work, regardless of the .NET virtual machine and classes. Kevin McFarlane wrote: I suspect Windows itself and perhaps some MS apps. Again no. The entire operating system is based on COM. What we developers do is use the features provided by these COM objects. So in the end, we need at least a COM bridge. That's P/Invoke. Because of that, not only the underlying COM is not going to vanish but also, quite the contrary, people are using platform invoke with C# to solve their problems. In the marketing brochures, MS never talks about that hybrid .NET code made of simple C# (or VB.NET, ...) code, plus all the application logic done with platform invoke. I can't figure out what is "native .NET" when it comes to real world problems, really. What is going to change through the years ? - probably the classes provided to us will have more "business objects", hopefully. - .NET will be more than ever out of developers' control, unlike MFC dlls for instance. The ability to run your .NET app on someone else machine will probably rely mostly on the actual target .NET runtime to accept your IL code (based on some .NET-compliance certification steps, or whatever MS might think about it along the way...).
-
Kevin McFarlane wrote: I get the impression that eventually it will all be replaced by native .NET If you want to use the shell, you have to use the COM shell interfaces. .NET classes exposing shell features do exactly that for us, but in the end if the COM shell objects are badly installed, or badly registered, it won't work, regardless of the .NET virtual machine and classes. Kevin McFarlane wrote: I suspect Windows itself and perhaps some MS apps. Again no. The entire operating system is based on COM. What we developers do is use the features provided by these COM objects. So in the end, we need at least a COM bridge. That's P/Invoke. Because of that, not only the underlying COM is not going to vanish but also, quite the contrary, people are using platform invoke with C# to solve their problems. In the marketing brochures, MS never talks about that hybrid .NET code made of simple C# (or VB.NET, ...) code, plus all the application logic done with platform invoke. I can't figure out what is "native .NET" when it comes to real world problems, really. What is going to change through the years ? - probably the classes provided to us will have more "business objects", hopefully. - .NET will be more than ever out of developers' control, unlike MFC dlls for instance. The ability to run your .NET app on someone else machine will probably rely mostly on the actual target .NET runtime to accept your IL code (based on some .NET-compliance certification steps, or whatever MS might think about it along the way...).
Thanks. Very informative.:) Kevin
-
Yes, I think this will be so in the long run. But it will take several years I think .NET itself still uses COM+ for some parts but I get the impression that eventually it will all be replaced by native .NET. I suspect Windows itself and perhaps some MS apps. wil still use COM internally but application developers will write .NET components for new stuff. Kevin
very right :-) and this is what i was thinking. thanks :-), nice to get the response for this message ;). let me see your bios :-). @ish@ Check my article on .NET What is Common Language Runtime (CLR)?
-
Kevin McFarlane wrote: I get the impression that eventually it will all be replaced by native .NET If you want to use the shell, you have to use the COM shell interfaces. .NET classes exposing shell features do exactly that for us, but in the end if the COM shell objects are badly installed, or badly registered, it won't work, regardless of the .NET virtual machine and classes. Kevin McFarlane wrote: I suspect Windows itself and perhaps some MS apps. Again no. The entire operating system is based on COM. What we developers do is use the features provided by these COM objects. So in the end, we need at least a COM bridge. That's P/Invoke. Because of that, not only the underlying COM is not going to vanish but also, quite the contrary, people are using platform invoke with C# to solve their problems. In the marketing brochures, MS never talks about that hybrid .NET code made of simple C# (or VB.NET, ...) code, plus all the application logic done with platform invoke. I can't figure out what is "native .NET" when it comes to real world problems, really. What is going to change through the years ? - probably the classes provided to us will have more "business objects", hopefully. - .NET will be more than ever out of developers' control, unlike MFC dlls for instance. The ability to run your .NET app on someone else machine will probably rely mostly on the actual target .NET runtime to accept your IL code (based on some .NET-compliance certification steps, or whatever MS might think about it along the way...).
Question: Developing an enterprise level application would you inherit from ServicedComponent and install it in COM+, or would you create a Remoted object, and host it without COM+? From the below link... I would think that COM+ as an "Application Server" for .NET components will go away, and we'll see a .NET Application Server. Thus making the choice above for inheriting from ServicedComponent the most logical choice. http://msdn.microsoft.com/msdnmag/issues/01/10/complus/default.aspx I ask this question because I run into quite a few people who say COM+ is dead.. Use .NET Remoting, and the singlton design pattern, and roll your own small service to remotly expose your objects. Though I keep saying... "What about Context? Connection Pooling, Object Pooling..." they respond.. "The singleton mrs!! now shooo!". :eek: Thanks for the help in advance. Joan