Hi Uhrig,

Currently, ExcelDna is my fallback. Its only drawbacks are that it
exposes my code to tampering by end clients and that it requires me to
distribute a few additional dlls. I would still rather have a my
deliverable consist of a single installable XLL file.

Not sure what you mean with the tampering issue. Easy decompilation is
a property of .NET assemblies, and you should look at obfuscation
tools to address this. But this issue is independent of how you
integrate into Excel.
Indeed for ExcelDna you currently have to ship an extra .dll file and
a text file, and address the .Net version loading issue -- I would
like to simplify this in future. If you have particular requirements,
please let me know.

How come VSTO doesn't supply this functionality?
Maybe it does so only for Excel 2007?
I know of no plans to support the creation of UDFs in VSTO add-ins,
also not for Excel 2007. But the .XLL interface (that ExcelDna uses)
got a significant upgrade in Excel 2007, so it should be a great way
to integrate into Excel for the foreseeable future.

How come it's so hard to hook up .net code into MS Excel?
It's not hard at all, and there are many ways to do it. You can:
1. Reference a .Net library in VBA code, and create functions VBA
functions that call your library.
2. Create an Automation Add-In and integrate into Excel using COM
interop.
3. Create a .XLL add-in using C/C++ and reference your .NET code
(using the It-Just-Works C++/CLR binding).
4. Use ExcelDna which is easy, open-source and free (including for
commercial use).
5. Use the commercial ManagedXll library, which is expensive but has a
very broad range of features.
For the last two, you need to write no additional code to expose your
functions to Excel, you just add some attributes in your code. Seems
pretty easy to me.

Regards,
Govert