"Glen B" wrote:
Yup

Sure, the back-end and many communications tools we deal with aren't
using .NET, so every solution will be hybrid to some extent. The
ongoing goal is to minimize the points of failure.

There's nothing inherently wrong with using unmanaged DLL. The
problem is with the sorts of issues that are possible with unmanaged
code that we don't even need to think about with managed code - like
memory leaks, hanging object references, unterminated threads, etc.

How about this. Let's say I tell you I wrote a new ODBC driver so
that you can do SQL queries from some Linux client into D3 Linux.
Then you find out that all I'm doing is passing the queries through a
Windows box as a proxy. That's a pretty cheesy (though effective) way
to do this. The obvious question is "what happens if the Windows box
does down?" That's the same way I look at .NET code that has to run
through Interop to get somewhere else.

If I tell my client they are using "Linux" for ODBC, they think
they're getting all of those warm fuzzy benefits of Linux including
stability, open source, etc. If I tell someone I'm using .NET, they
(should) expect all of the benefits that are promised with that
technology. If my app has a chance of falling over with a null
pointer exception or array out of bounds error, I might as well be
writing in C or VB and not bragging about using better technology.

I wouldn't consider n-tiered deployment as creating different
definitions for .NET or the notion of managed code. The code is
simply managed or not at various tiers and you do the best you can to
make each point as stable as possible.

HTH
T