0

Piece of code below works fine with Development Server but fails when the project is published to IIS. Tried different ones than the xlExcel8 but no help. I also thought changing Microsoft.Office.Interop.Excel reference's "Copy Local" property to "True" but it's grayed out. I am not able to change it. I suspect the IIS and Visual Studio using different dlls.

_excelApp.ActiveWorkbook.SaveAs(filename, XlFileFormat.xlExcel8)
Jude
  • 2,353
  • 10
  • 46
  • 70
  • You do realize that the Excel interop is not designed for - and Microsoft specifically say "Do not use" in an IIS context? – Ian Feb 24 '14 at 12:22
  • 1
    Please see my question here http://stackoverflow.com/questions/1273116/reading-excel-files-as-a-server-process regarding using Excel on a server. It includes a link from Microsoft as to why you shouldn't do it using the Interop. – Ian Feb 24 '14 at 12:23
  • OK. Accept all. But, just to test I have installed VS2012 on the server and it worked properly. Makes sense or not? – Jude Feb 24 '14 at 12:27
  • @Ian Do you think it's a good idea to develop a Windows Project for that. – Jude Feb 24 '14 at 12:38
  • 1
    @Jude: I would pick a library that you can use instead that will work safely within IIS. It's incredibly difficult to get native Excel to behave - and it varies across server operating systems. It really isn't worth the hassle trying. I used FlexCel previously, quite cheap and worked really well. – Ian Feb 24 '14 at 13:00
  • OK. I will go for the same. – Jude Feb 24 '14 at 13:03

2 Answers2

0

Well. Let's start with the fact that running office in a server environment is not supported? And an IIS application pool sort of is exactly hat. Contrary to your dev server - running in your UI session - it also has no UI session it runs in.

And that pretty much is it.

Not supported. Whoever came up with this idea - did not check whether it is feasible.

TomTom
  • 61,059
  • 10
  • 88
  • 148
  • 1
    This isn't an answer to the question - it should be a comment. – Ian Feb 24 '14 at 12:25
  • Actually it is an answer. Do not do it, it is not fixable and it is not going to work, ever. THere is no other answer. – TomTom Feb 24 '14 at 12:29
  • 1
    That's not strictly too - before I was unaware of the reasons not to do it, the product I used to be involved in did so and it worked reasonably well. I however switched it to use a 3rd party library instead when I came across that advice. – Ian Feb 24 '14 at 12:31
  • What are comments for then TomTom? – Jude Feb 24 '14 at 12:31
  • @Juse commenting. You may want to use a dictionary to get the terms "answer" and "comment" defined - you seem to lack some language understading (on top of working on a design that is not supposed to even work). – TomTom Feb 24 '14 at 12:32
  • I suppose you need that said dictionary – Jude Feb 24 '14 at 12:35
-1

Just FYI,

For reasons I'd rather not get into, I am running interop on IIS and it works fine. I'm not saying I'd recommend using it, and I plan on switching to OpenXL, but for those saying it doesn't work and there's no other answer, they are quite wrong.