This reminds me that compiling QuantLib is such a pain in the ass. I love QuantLib though - I use it via C# and there is an Excel plugin already available in the source code.
As regards your example:
(a) single-name options usually have an American exercise-type.
(b) the main difficulty (and the thing one would actually pay for) is getting and maintaining a vol-surface for pricing these things - using flat vol to price this is quite inaccurate and risky.
I've played around with QuantLib's Excel plugin, and I don't find it easy to use - the hybrid system they set up to merge Excel with the C++ structure of QuantLib is unintuitive. I've had better luck just pulling the functions into Python and going from there.
I agree. It's quite messy. That's why I use the C# swig bindings instead and if I had to use Excel as a UI, I'd build my own plugins in C# rather than use the ones they provide - in a similar fashion as you've done with Python.
Well, it requires an unmanaged dll (NQuantLibc) to be compiled which would be pinvoked by the managed bindings dll (NQuantLib). The unmanaged dll will not be platform independent (I don't know if you'd be using x86/x64). It also needs to be copied over to the same directory in which your output binaries would reside.
As regards your example:
(a) single-name options usually have an American exercise-type.
(b) the main difficulty (and the thing one would actually pay for) is getting and maintaining a vol-surface for pricing these things - using flat vol to price this is quite inaccurate and risky.