The prerequisites for using of your product are: re-distributed .NET Framework of required version or later, plus Microsoft Office of required version (could include just the Excel and its prerequisites).
Office Interop does not work without installation of the Office product itself, but if the user installs both .NET and Offices, corresponding Office Interop assemblies become available to .NET; they are placed in GAC.
Of course, it creates the licensing problem: you cannot redistribute your copy of Office. You either need to make some legitimate license agreement with Microsoft, or simply require that your clients have it, as one of the prerequisites to your product.
This is one of the reasons why I'm strongly against Office development. This is not a good investment, maybe only acceptable in narrow user base scope, such as corporate tools, but even that is questionable. As I described above, deployment of such products is still quite possible, but it also creates the
vendor lock-in (
http://en.wikipedia.org/wiki/Vendor_lock-in[
^]). Why having all that trouble? There are good alternatives to the Office. It can be as simple as HTML. And it can even be something within .NET. For example, you can leverage WPF
FlowDocument. And, these days, a lot more good opportunities.
—SA
Submit an article or tip