• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 742
  • Last Modified:

DCOM alternative for my Silverlight app (currently requires Office be installed on IIS server)

I have a Silverlight 5 application that utilizes some MS Office features (opening documents, spreadsheets, sending email via Outlook, etc).

The implementation requires that MS Office 2007 or higher be installed on the IIS server.  Understandably, some of my clients' IT departments are balking at installing Office on the server.

Is there any alternative?

When I search for "DCOM alternatives" I see discussions about using Web Services instead.  I don't know if that's reasonable in this situation or not.  We are already utilizing web services in my application for other things.  I'm not the developer on this project, just the project manager, so I don't know the details of the implementation.  

What I need to know is if there is some remedy / alternative that will be acceptable to IT, as well as provide the features to users (the ability to work with documents and send email from the browser app without Office being installed on the server).

We are already requiring that the application have elevated permissions, which is not an issue.
0
bjones8888
Asked:
bjones8888
  • 8
  • 6
1 Solution
 
RobOwner (Aidellio)Commented:
Lots of info about distributing it with your app too
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
bjones8888Author Commented:
Microsoft says that even PIA isn't recommended for a server side solution.

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757#kb2

The link provided by apeter indicates that PIA is simply a wrapper for the underlying executables (winword.exe, etc) - so that doesn't actually seem like a solution either.
0
 
RobOwner (Aidellio)Commented:
Your right about Microsoft recommending not to use it but it's more general than that. Also they're not saying it won't work, they're stating that it should never be automated in a server environment.
Honestly Microsoft are just washing their hands of supporting such an environment. They haven't designed or tested the software to work on this way and don't plan to by the sound of it.
My question to you is: Are you really worried about it?   The possible solutions you've got now all have issues, you just have to pick one that is the easiest to manage and maintain.
I still like the idea of working with your IT Department to get it installed on the server but to me that's the same as having the PIA installed
0
 
RobOwner (Aidellio)Commented:
I'm also going to suggest that you rethink the need to use office....
There are ways to send emails using SMTP on IIS, open word docs and excel spreadsheets by not using office but other third party structures such as OOXML
But I would need to know why you need to stick with office
0
 
bjones8888Author Commented:
There are two broad scenarios for a user of our application.

1. User is working from their office pc, in their LAN environment.  In that instance, Office is not required.  Documents are opened directly at the file share using software installed on the client pc, via the SL equivalent to ShellExecute.  No problems.

2. User is working out of the office, and the file share is not directly accessible.  In this situation, the SL app sees that the file share isn't locally available, and so it uses a web service to tag the document with metadata (flagging the document with identifying information that it "belongs" to a particular record in our application.  The file is then downloaded to the pc's sandbox, and opened.  When the user saves the document on close, an Add-In "recognizes" the metadata and calls a web service to upload the document back to the server, and then removes it from the local pc.

From what little I've seen so far on OOXML, that seems like a great solution.

We're also sending email from our app.  When Outlook is available, we use that client.  If not, we're using SMTP - so Office would not be required in that case on the server.

Researching the viability of OOXML now.  Once we decide (soon), I'll repost back here.
0
 
RobOwner (Aidellio)Commented:
Microsoft changed its file format to this in office 2007 and fully supported it in 2010. This means you could really only support these versions if excel and word etc
So it's modifying the meta data that you need office installed on the server? As I assume each client will have office installed. If you're just checking if the file share is available or not why do you need office?
0
 
bjones8888Author Commented:
It is for the purpose of writing to the doc/docx/xls/xlsx, etc - to put metadata onto the file itself.
0
 
RobOwner (Aidellio)Commented:
Ok sure, that's the catch then :-) and from what you've said it does make sense to keep the information about the linked record in your application.
 additional catch here is writing to the older 2003 office files but they may not be an issue?
0
 
bjones8888Author Commented:
Older formats would certainly be an issue.  This is a legacy app and there are very old documents.  New documents created wouldn't be 2003 formats, but they would need to put metadata tags on older documents when they want to edit them, conceivably.

I didn't realize OOXML doesn't support those formats.  Do you know if it can convert doc to docx?

Back to the drawing board....
0
 
RobOwner (Aidellio)Commented:
OOXML would not be able to convert it but there are other options. You could manually open each older doc in the corresponding program and save it but if you can batch process them then here's your answer
http://adminramble.com/convert-batch-doc-files-docx-work-ppt-xls-files/
0
 
bjones8888Author Commented:
Manually opening them is not an option.  Scores of thousands of them potentially.

Batch conversion is certainly the way to go.  Thanks for the link.  Looks like it will do the trick.  It is somewhat comforting that it is from Microsoft.  (Yes, I'm naïve.)

Hopefully I could set the source and destination folders to the same path.  Then I could delete all the .doc files and simply be left with docx.  My SQL database holds a pointer to this specific file & path, so the newly converted files would ultimately have to go back to the original location anyway. I'd have to then update the file specification in my database to be docx instead of doc.  That's easy enough.

I've also just heard from my programmer that OOXML works as expected for putting the metadata on the docx and xlsx files.  Looks like I have a viable solution.

Thank you!!
0
 
bjones8888Author Commented:
OOXML is the answer for us.  It explicitly states in their website that it is designed to handle server environments.

Although it doesn't work with doc/xls formats, the other solution you provided for a batch conversion of those older formats will be sufficient to convert legacy data.

Now we can remove MS Office as a server requirement.

Thank you.
0
 
RobOwner (Aidellio)Commented:
No problem. Great to hear you've got the answer.
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

  • 8
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now