Prevent VSTO Office Customisation installer prompt from appearing when Opening a document - vsto

I have developed a VSTO 4.0 Document Customisation for a custom Template which works fine and installs using ClickOnce.
However, one of the requirements I have is that the resultant documents, being the resultant .docx files, are shared with users outside of my organisation and I DON'T want them to be prompted by VSTO to install the customisation.
The external users should be able to open the document without any VSTO prompts and treat it like a usual Word document, and when the document is saved by the external user and sent back, I can open the document and the the VSTO customisation will work as expected.
This is a usability scenario where a document needs to be collaborated on by my organisation and an external organisation, but I can't expect the external organisation to install the VSTO customisation. They will typically just insert text, pictures and add review comments.
Is there any way that I can achieve this scenario?
BTW, using a Web Addin for Office 365 is not a feasible option at this stage as some of the customisation requirements cannot be achieved with the Word Javascript API.

You need to remove the link from the VSTO document before making it available to outside people. And when the document comes back you can link the customization back to it.
There's an entire MSDN article on the topic, as well as a blog article.
In a nutshell, there are two ways this can be done: from within the opened document or on the closed document.
Run the Document.RemoveCustomization method, which can be assigned to a button in the Ribbon customization, for example. This removes the links stored in Custom Document properties to the VSTO code (which is how the document, itself, finds the code when it opens), as well as any cached data.
Use the ServerDocument.RemoveCustomization method, which essentially does the same thing.
ServerDocument.RemoveCustomization(documentPath);
Re-attaching can only be done via ServerDocument.AddCustomization, logically enough.
string deployManifestPath = System.Environment.GetFolderPath(
Environment.SpecialFolder.Desktop)
+ #"\Publish\WordDocument1.vsto";
Uri deploymentManifestUri = new Uri(deployManifestPath);
ServerDocument.AddCustomization(documentPath, deploymentManifestUri);

Related

How to read contact information from office add-in in word

I need to have an office add-in component (https://dev.office.com/getting-started/addins ) to allow user to select a contact from the global address book to insert that contact email in the word document.
Any suggestions if this can be done with office add-ins? if yes how can it be done? or it must be VSTO?
An Office Add-in is simply a web app (that happens to run in the context of an Office host), so you can design it to do the types of things that a web app can do, including issuing requests against REST APIs. Regarding the scenario you've described, I'd view it as 3 distinct tasks:
Get contact info from AD.
Present list of contacts to user (so they can select one).
Insert email address of selected contact into document.
1- Getting contact info:
Re the specific scenario that you've described, I'd suggest that you investigate the feasibility of using either the Microsoft Graph API or the Azure Active Directory Graph API to get contact information from the GAL. Please note that, in general, using Microsoft Graph is recommended over using Azure AD Graph.
2- Presenting list of contacts to the User:
Regarding UI design, because your Office Add-in is simply a web app, you can present the list of contacts to the user in whatever manner that your web app supports.
3- Inserting text into the Word document:
Regarding inserting text into the document when the user selects a contact via the Add-in UI, you'll use the Word JavaScript API to do this. If you haven't used the Word JavaScript API before, I'd suggest that you start by doing the Word Add-in quickstart, which shows how to insert text at various points in a document. Then, for additional details about the API, see the Word JavaScript API reference docs. (Which API operation you use to insert text into the document will depend the specifics of your implementation. I'd suggest that you post a separate Stack Overflow question that describes specifically what you want to achieve re insertion of text into the document, if you need help with that when the time comes.)

How to get Webtop Drl of a document via .net application?

Is it possible to retrieve drl ex:https://host:port /ewebtop/drl/objectId/0900a58e80970f7b of document via .net application?.So that when users clicks on this link they can be able to edit the document and when they close the document the document should be autosaved onto documentum.
First of all: a link is a link. What you decide to do with it I u to you. Default handler in browser will just redirect you to webtop application. If you have SSO you can have the document opened for edit. There are some extra arguments that can be provided (view/edit).
The object id is the only varying part of the URL, so you can easily construct this in code.
Secondly: what is your goal? There is no way to make the document upload itself into Documentum repo. You can write a plugin for every application to handle that, but it seems like a big task - especially dealing with security.
The problem is that upon check-in, user must provide some information - at least about the new version number...
If you're building a thick client in .net I would go with DFS - that's the only real option here.

Outlook VSTO attach meta data

I am writing an Outlook addin that inserts content into an email, and I have a emailSent event that I would like send an event back to my server letting me know some content was shared.
Is there a way to attach some meta information to the email (or the word doc, which is what you are creating in outlook) so that I can grab that meta info so I can send it back to my server.
Right now, the only way I think I can do it is to search through the email on the send event looking for my content with regex and pull out the info i need, but that seems cumbersome, and also means I need to run the regex for every email sent, even when they haven't added my content.
There is the concept of MAPI user properties, which you can add to an Outlook item. Since Office 2007 the object model allows access to them. If your add-in must run also with older Outlook version, you should recurr to use Redemption (which I prefer also for higher office versions because it has more flexibility, albeit a greater footprint in distribution).
See UserProperties Interface on MSDN.

Programmatic Reaction to Receiving New Email

I'm interested in automating some reactive work I do when receiving certain emails in one of my email accounts. What I would like to have happen is:
On receipt of new email in the account
If the new email passes the "Need to React" criteria (based on body content and subject line)
3a. Scrape some content out of the email body and subject lines
3b. Populate a template form (e.g. Excel spreadsheet) with the scraped data
3c. Print the populated form and save the populated form in some folder (e.g. as a pdf)
What's the best (defined as easiest to implement by myself) approach / combination of technologies for achieving this automation?
i have not done exactly what you are asking, but I know Microsoft Outlook has a Rules engine that can take incoming messages, check for various content, and then do various actions including running applications and/or scripts.
You should look at Visual Studio Tools for Office if you are a c# person.
http://msdn.microsoft.com/en-us/vsto/default
You can write an Outlook add-on that can do pretty much everything you have outlined above.

Building Forms for Outlook 2007

I was just introduced to the concept of Outlook forms. I don't know if this will solve my problem but here is what I want to do:
I want to be able to have employees who are inside the company fill out some forms. So all I have to do is create the form and PUSH it to their Outlook? After they fill out the form, can I capture the data somehow? Has anyone does this before? Can someone recommend a good tutorial/examples?
Update: The Outlook->Access option seems like a great one, but it seems like the form must be emailed by someone. In other words, if someone wants to fill out any form they first have to be emailed a form. What if a person wants to just fill out a form? How would he do it if he has no access to the Access database?
Here are three options:
This page is a really good jump page for custom forms in Outlook. In fact, that whole site is pretty good with lots of examples and links like Outlook Forms Step-by-Step Tutorial.
However, if you also have Access 2007, I'd actually recommend something simpler and easier to create email forms that can be sent to users and collect back all of the information. Once I discovered this in Access 2007 I never went back to custom Outlook forms.
Basically, you create an Access db with the data you want to collect and then in the "External Data" tab in Access 2007, you click "Create E-mail" and a wizard will walk you through creating an email with the form in the body (which is either HTML or InfoPath, depending on which one you choose). You send this to your users (you can have a recipient list in a table as well in your Access DB) and they fill out the form (I used it for surveys) and then they click submit. It goes back to your Outlook in a special folder and as soon as you open Outlook, it will synch it with the database. Then you can slice and dice all of that database information.
Here are some great tutorials on this:
Demo: Collect data in Access 2007 by
using e-mail
How to integrate Microsoft Access
and Outlook 2007
Finally, if you just want to collect back much simpler information, like "Yes", "No", "Maybe", the easiest way is to create voting buttons. Go to New Message -> Options - Voting Buttons. You can customize this if needed by separating your choices with a semi-colon ;.
In #2 and #3 above, these are scenarios to initiate data collection.
There are other situations where someone doesn't need a prompt via email to fill something out right there, but rather just submit a form (like an expense report, or a gas mileage report). #1 above (Outlook custom forms) is generally better choice in that scenario, but:
Outlook forms have typically been
harder to deploy and teach people to
use (there are things like "public
forms", "private forms", etc.)
Outlook forms have been, in practice,
been replaced by other technologies.
In particular, InfoPath/Forms Server and
Sharepoint Forms. This is because neither
of those two technologies requires
users to do a whole lot other than
follow a link to fill out a form. I used to know, about 10 years ago, many companies who tried to use Outlook forms and most of them gave up development of them in favor of other technologies.
This isn't to say that Outlook forms are bad in any way. If you don't have other technologies available to serve as a Forms Server, then this could be a decent option to consider.
To look at other semi-lightweight ways of form submission, you can use MS Word templates as the front end and have them update an Access DB. Here are a couple of good articles on this:
Import Data Directly from Word
Forms to Access Tables
How do I... Transfer data from a
Word form to an Access database?