I've been struggling with this off and on for two weeks, most of that time having been spent waiting for responses to my support issue. I have the solution, which I will post here in the hopes that it helps the next person who runs into this issue. I'm going to throw in a lot of unnecessary detail to increase the odds of the next guy finding this.
I am working on an MVC5 site, and using the ActiveReports 8 HTML5 viewer to display an IList-bound code-based section report. I have enabled PDF, Word, and Excel exports using the availableExports parameter to the GrapeCity.ActiveReports.Viewer javascript function. The viewer renders properly on the page, and makes the expected call to ActiveReports.ReportSerice.asmx, which returns the information needed to render the report, including the URL to stream the data from. The report displays in the viewer just fine. So far so good.
On my development machine, I can export to PDF, Word, and Excel. When deployed to the test server, however, the Excel export stops working, and the browser just shows a save file dialog attempting to save a file called ActiveReports.ar8?blahblahblah. Digging in with Fiddler, I determined that this is almost exactly the same as the URL returned from the call to the report service above except for a few parameters such as "Command=Export" and "ExportFormat=Xls".
Saving this "file" results in a 0-byte file called ActiveReports.xls. I can simulate this behavior for other export types by removing key dlls such as GrapeCity.ActiveReports.Export.Pdf and then asking for a PDF export, for example. It appears to me that ActiveReports (at least as of version 8.1.414.0) swallows certain server-side errors, such as missing dlls, and returns a 404 error code to the client. I think a 500 error with details about what's missing would be preferable to a generic 404.
This leads me to believe that there is something missing on the test server. Since I have "copy local" set on all the ActiveReports dlls, and I can see that they all successfully deployed to the test server, the missing piece must be something present in the GAC of my local machine, but not on the server.
Using Fiddler, I have determined that the response to the ActiveReports.ar8?blahblahblah URL has a return code of 404. The content-disposition header on the resulting 404 response has been set to "attachment; filename=ActiveReports.xls", but the Content-Type is "text/html" rather than the expected "application/vnd.ms-excel". This tells me that the export made it at least partway through processing before giving up.
What's missing on the server that's preventing Excel exports from completing?
The missing piece of the puzzle is the DocumentFormat.OpenXml.dll, a copy of which can be found in the "C:\Program Files (x86)\Common Files\ComponentOne\ActiveReports 8" folder. Ironically, it alphabetizes right next to all of the GrapeCity.ActiveReports assemblies, but without any indication of which other assemblies use it, you can easily look right past it as I did, figuring it was a dependency of something else in that folder such as the license generator.
Adding a reference to DocumentFormal.OpenXml.dll to the web project, and setting Copy Local to true ensures that the dll gets deployed along with everything else. My Excel exports work just fine now.