Fun with COM interop

So I have a C# object which exposes a COM interface through interop, and it was working. Then I did something, and when I went to reload it, it said the component was not registered. I confirmed that the ProgID was in the registry, and everything appeared to be good.

... It turns out that if the constructor for an object which is being constructed for a COM object instantiation throws an exception, the CoCreateInstance call will return that the component is not registered. This is not normally a problem with native C++ COM objects, since they run the constructor code as part of the registration process, so you'd catch the error earlier. However, C# COM object apparently do not, and the error coming from COM is very misleading.

Just an interesting tidbit for COM interop.

Comments

Post a Comment

Popular posts from this blog

The Story of PayPal V2

I was reading The Founders recently (https://www.amazon.com/Founders-Paypal-Entrepreneurs-Shaped-Silicon/dp/1501197266); I was interviewed for this book, fwiw. There's a section in "PayPal V2", the internal effort to rewrite the aggregate website which was ultimately scrapped when Elon was ousted, but obviously the book glosses over a lot of the technical details (for good reason, as these would be not very interesting to most mainstream readers). However, if you're reading this, I'm going to assume you might be more interested in the nitty gritty of this project, and since I had a first-hand perspective, I'll write more about that aspect here (and if you're not interested in this, then perhaps skip this post). To understand the build up to this, though, I'll need to cover a bit of internal history, from my perspective. The Preconditions Technology base Confinity and x.com had very different technology bases, which went well beyond even the approach to...
Read more

The problem of "thrashing"

"Thrashing" is a general term/issue in computer science, which refers to the situation (in the abstract) in which multiple "work items" are competing for the same set of resources, and each work item is being processed in chunks (ie: either in parallel, or interleaved), and as a result the resource access ping-pongs between the different work items. This can be very inefficient for the system if switching access to the resources causes overhead. Here's the wiki page on the topic: https://en.wikipedia.org/wiki/Thrashing_(computer_science) There are numerous examples of thrashing issues in software development, such as virtual memory page faults, cache access, etc. There is also thread context thrashing, where when you have too many threads competing for CPU time, the overhead of just doing thread context switching (which is generally only a few hundred CPU cycles) can still overwhelm the system. When thrashing occurs, it is generally observed as a non-linear incr...
Read more

Zero cost abstractions are cool

There is a language design principle in C++ that you should only pay for what you use; that is, that the language should not be doing "extra work" which is not needed for what you are trying to do. Often this is extrapolated by developers to imply building "simple" code, and only using relatively primitive data structures, to avoid possible runtime penalties from using more advanced structures and methodologies. However, in many cases, you can get a lot of benefits by using so-called "zero cost abstractions", which are designed to be "free" at runtime (they are not entirely zero cost; I'll cover the nuance in an addendum). These are cool, imho, and I'm going to give an example of why I think so. Consider a very simple, and somewhat ubiquitous in code from less experienced developers, function result paradigm of returning a boolean to indicate success or failure: bool DoSomething();  This works, obviously, and fairly unambiguo...
Read more