InfoQ Homepage COM Content on InfoQ
News
RSS Feed-
Build Machines, Windows 7, and Classic ADO
Imagine you are doing maintenance on an application from the late 90’s that uses the classic ADO libraries. The recompiled code works fine on any Windows 7 SP1 machine, but mysteriously crashes on the Windows XP machines that have been running the program for nearly a decade. This is the problem facing lots of maintenance developers.
-
Managed Extensions for Internet Explorer
With .NET 4.0, writing reliable managed extensions for Internet Explorer has become possible. Unlike previous versions, each extension will run against the CLR it was compiled for instead of mindlessly grabbing the most recent version. Alas, COM interfaces are still needed.
-
Marshal.ReleaseComObject Is Considered Dangerous
Paul Harrington, Principal Developer on the Visual Studio Platform Team, has written an explanation on why calling Marshal.ReleaseComObject() to dispose of a COM object from managed code is considered dangerous and recommends not using it.
-
Silverlight 4’s COM+ Automation Raises Security and Portability Concerns
Silverlight 4 supports COM+ Automation when running as an Out-Of-Browser (OOB) application with elevated privileges. Microsoft indicated that this support is a result of enterprise customers requesting such a feature, offering as an example Office automation from Silverlight.
-
Is It Appropriate to Use Non-.NET Libraries in Your Day to Day Work?
From the beginning, the .NET stack had first class support for unmanaged libraries. By using P/Invoke one can access most of the Win32 API and support for COM opens up developers to a wealth of applications and third-party libraries. But should .NET developers actually take advantage of this?
-
C# Feature Focus: Optional and Named Parameters, COM Interoperability
Believe it or not, C# is going to have full support for optional and named parameters. This, and other features intended for COM support, will be included in C# 4. There was also a rumor about parameterized properties.
-
.NET 4 Feature Focus: Type Embedding and Equivalence
In .NET 4 types will no longer be restricted to a single assembly. A single type, or part of a type, can be extracted from one assembly and placed into another. Why would you do this? Well first off all, to reduce the cost of including the Office Primary Interopt Assemblies from several megabytes to about 2KB by only including what you actually need.