That said, yes…VS2010/C# 4/.NET 4 has a number of new features intended
to make dealing with COM interop easier. Among those is the "no Primary
Interop Assembly (PIA)" feature, in which the compiler takes the type
information from the COM interop assembly, and instead of requiring you
to deploy the whole interop assembly, embeds the types you use in your
program within your program's own assembly.
You can control this behavior using the "Embed Interop Types" property
for a COM interop reference added to your project.
There are a number of other enhancements to use of COM interop as of the
VS2010 release, such as the dynamic type (which allows type resolution
to be deferred until runtime), and "type equivalence" (which allows two
managed assemblies to use different versions of interop DLLs and yet
still work together in the same process), among others.
In general, you should find dealing with COM interop much easier in many
ways with .NET 4/C# 4 than with earlier versions of .NET and C#.
It was interesting how that mini-advertisement creeped in
. It's
nice that a dependency on the DLL is no longer required when that
property is checked. It's also nice that only the interop parts that
actually get used get embedded in the project. But as nice as that
capability is, it doesn't impress me a lot. I realize that
Microsoft's motivation for interop is a response to companies with
many, many lines of code that will take a lot of time and effort to
convert over to managed code. I.e., they weren't even trying to
impress me
. But as someone who needs to find ways to use interop
more than the average C# programmer, that feature is almost as
underwhelming for me as the hoopla over optional parameters. Don't
get me wrong. Microsoft has provided a large variety of ways for me
to do what I need to do in C#, especially in terms of threading and
interop options. So many, in fact, that choosing the best ones will
not be an easy task. I even learned yet another new threading option
today. In the PDC 08 session:
TL 13 - Microsoft Visual C++: 10 is the new 6 (Boris Jabes)
"It [lambda expression] is simply a functor done for you
automatically.
...
Where I think they're really interesting to experience is when you're
doing parallel programming where parallel API's really take advantage
of the fact that you can quickly express functionality and state in
one place and then pass it around on any number of cores.
...
The building block for all of these [API's, agents, tasks, algorithms]
is lambdas. So probably you're going to start seeing this as a kind
of a required knowledge to build parallel applications, in C++ anyway,
and probably in other languages as well."
Until now, I had thought of lambdas mostly as a vehicle for
implementing LINQ without much consideration of what future
possibilities they will enable for me. So I suppose that Microsoft's
touting of features that are somewhat marginal to me is fine as long
as the features I really care about are there. I have to recurse
(made up verb) finding the best ways of doing interop with
understanding how I can use the new features before I decide how
important they are to me
. Type equivalence looks great if I opt
to use managed C++ to take advantage of C++'s special interop
capabilities. I'll already know the data types that are to be
"marshalled," so the dynamic type's main benefit seems to be that
hinted in the PDC 08 session:
TL11 - Introduction to Microsoft F#
where map and sum are changed to pmap and psum in a declarative way to
transition smoothly to running in parallel. The kind of thinking
required to program in F# is a little foreign to me, so I'll have to
try it out a little to see if it's as appealing to mathematicians as
they claim.
James A. Fortune
(e-mail address removed)
