I am developing an Office Add-in using Visual Studio. However, I want to rename some files, delete others, and upload a file. Visual studio allows me to use HTML and JavaScript. However, neither of these allows me to access or manipulate the files on the client PC.
I could do this easily in the old VBA add-in development methodology, but I am new to the new "progressive web App" technique. I would appreciate an suggestions about how to access and manipulate client files in an Office Add-In developed with Visual Studio.
Thank You.
You cannot access the local file system (except for cookies) from an Office Web Add-in for the same reason that you cannot from a web application. It would be a security risk.
Related
I am new in Office add-in development and little bit confused about creation JS plug-ins for Outlook. Actually we can create one add-in which will be available on all platforms: Outlook on Mac/PC, Outlook.com and Outlook 365.
But what about tools for it? According Outlook development documentation, we can use Yeoman generator for creating Office add-ins. However in my VisualStudio Community 2015 is type of project like "Web add-in", where I can chose Outlook add-in. So is there some difference between Yeoman generator and VisualStudio Web add-in projects?
Visual Studio is the main tool for creating Outlook plugins. You can also use Visual Studio Code for developing web-based solutions.
Office add-in is nothing else as "manifest.xml" file + your web application (HTML + JS). Web application is what your VS Code is help you to create. The manifest part is something which you able to write yourself, coy it from an example or use YO Generator to produce it for you. More on how to build office add-ins: Office Add-ins with VS Code and how to use generator: Yo Code - Extension Generator
To answer your question "is there some difference between Yeoman generator and VisualStudio Web add-in projects?": There is no fundamental difference. First choose whether to develop your Outlook Web Add-in with VS or with some non-VS tool. If you use VS, then use the project templates in VS. If you use any other development tool, use the yeoman-generated templates.
Occasionally, templates can get out-of-date. For example, recommended practices may change, or the manifest XML schema may be expanded. As a general rule, the yeoman-generated templates are updated more frequently than the ones generated in VS. For this reason, there may be small differences in the templates (besides the differences that are inherent to the differences in the tools).
Main issue: I need to develop an automated way to create new SharePoint pages when an item is added to a SharePoint list. For example, we have a list of projects, and when a new project is added to the list, we want a custom website for that project to automatically be created from a template.
What I've tried: I have been researching this a lot, and it sounds like SharePoint Event Receivers can do what I need. So I got Visual Studio (both Visual Studio and SharePoint are 2010). However, I still cannot automate my child pages. I get an error message when I try to do anything SharePoint-related in Visual Studio: "A SharePoint server is not installed on this computer. A SharePoint server must be installed to work with SharePoint projects."
My organization is not big on new software, so getting more than Visual Studio is probably not possible. In addition, I will not be granted admin rights, so I don't know if I will even be able to use Visual Studio. (Also I'm pretty sure my SharePoint is not locally installed, but I don't know much about software set-up/configuration...I just want it to work so I can code!) I do have full rights to the SharePoint site, so that shouldn't be an issue.
Is there a way to solve this issue with only coding in SharePoint? Or is there a way to do it with just Visual Studio (non-admin) and SharePoint?
In order to develop solutions for SharePoint 2010 you need to have SharePoint 2010 installed on your dev machine. You can install SharePoint 2010 Foundation which is free.
Before you start development you need to decide which kind of solution you gonna create - sandboxed solution or farm solution.
Sandboxed solution has some limitations in functionality but you do not need admin access to the server to deploy it, only site collection administrator rights on site collection.
On the other hand farm solution allows you to use any available SharePoint object model APIs. But to deploy it you need to have admin access to the server (or at least IT guy with admin access who can run some ps scripts).
The decision mostly depends on what are you going to develop. If you have some requirements which do not fit for sandboxed solution then you have to go with farm solution.
From what you've described I think sandbox solution is enough.
We're looking into migrating to TFS 2010 in the next few weeks. However, we're unclear on what kind of tools are required for the team. We know developers need Visual Studio but what tooling is required for Project Managers and Testers that will ONLY need to manage work items? Do they also need Visual Studio to just view and edit work items?
Project Managers and Testers can use the following methods to access TFS 2010
The web access portal - this allows the ability to create/run queries of work items, and even view source/builds if they want
Excel/Project - Both have integrate with TFS. You are able to load work items directly into Excel/Project, edit them, and publish them back to TFS.
Visual Studio with Team Explorer only - This is a barebones installation of VS, with the Team Explorer only. It doesn't take all that long to install, but it will say "Visual Studio" when launched. Not sure if that is scary to testers/project managers.
Web access provides a good complete set of functionality, but having VS/Team Explorer will provide a rich client experience (read: faster, more responsive).
Additionally, in order to get the Excel/Project integration, you'll need at least the VS/Team Explorer installed on the client box, even if they never use VS. And you need a CAL (Client Access License) to use the web access portal.
So to summarize, TFS provides a lot of ways for the non-developer to interact with the system, but all of them require a CAL, and most of them require installing VS/Team Explorer on the client machine.
In short, they don't need Visual Studio. They can use Team System Web Access (formerly known as TFS Web Access) to do pretty much everything a developer can do, except associate a check-in with a work item. After you install TFS 2010, you simply browse to http://yourserver:8080/Tfs/web and you're in!
Project Managers (and all other team members) can also work with work items from Outlook using 3rd party TFS client embedded in Outlook: TeamCompanion www.teamcompanion.com. This way, assuming they otherwise use Outlook, they wouldn't need to change tools or use any additional tools at all.
As is the case with Excel or Project integration they would still need a TFS CAL and additionally a TeamCompanion license.
TeamCompanion supports much more than just work item management: Email/TFS integration, SQL Server Reports, SharePoint document integration and much more...
Full Disclosure: I am the Product Owner of TeamCompanon, so I may be biased :-).
There is a web front end which you can use to manage the work items. There is also integration to Excel and MS Project.
See http://msdn.microsoft.com/en-us/library/ms181304.aspx for more information on Team Foundation Clients
Can someone give me a quick explanation of when I would use Visual Studio 2008 Outlook 2007 Ad-In project type? and how would that compare to developing a bunch of outlook macros directly in outlook?
Basically, I want to have some sort of application read email (with attachments) from a pop3 email box, do some filtering/editing/validation of the subject/sender/content and then if certain conditions are met, save the attachments to a local file, and then add an entry into an SQL server database table (i.e. date/sender/subject/message).
Seems there are at least 10 different ways to do this....so between an outlook macro and a VS Office Project, how do I pick?
I am not clear, if I create this solution as a Visual Studio outlook add-in, where does it run? Is it loaded into outlook, does it run as a separate process and communicates back and forth with outlook? if outlook is not running, does it start it?
An Outlook Add-on is a compiled component that uses the Outlook API to perform the tasks you need. A macro/VB script is an interpreted script that actually uses the same API. The add-on approach is better if you want to deploy your functionality.
When you work on an Outlook add-on in Visual Studio, you'll be creating a .NET component, which integrates into the Outlook application, which is written in C++ so uses COM. You'll have to be careful about managed/unmanaged types and releasing objects you retrieve from Outlook.
I have recently completed just such a tool, but I chose to use Add-in Express (http://www.add-in-express.com/). These guys provide a layer of abstraction over the [challenging] Outlook API and also provide some excellent support if you're stuck.
In my case, with Add-in Express, I "run" by setting Outlook as the application command to run, in the Project properties. Add-in Express sorts out the installation of the add-on within Outlook. So when I press "Run", Outlook starts and my add-in is displayed, which may be debugged in the normal fashion. I'm not sure how VSTO (Visual Studio Tools for Office) works in this respect - or at least, I can't remember.
This is an example of an outlook add-in..
Personally, I don't see macros distributable.
Is is possible to deploy VS add-ins using ClickOnce? How can I do it?
Take a look at Securing and Deploying Add-Ins. And the subtopic Securing Add-ins by Using ClickOnce.
I haven't personally used them, but I found them while searching with a similar question as yours.
#Rob: The links you have provided is Add-in's for Applications (aka MS Office), not for Add-in's for Visual Studio (as I understand the question). The Add-in object model in Visual Studio does not support ClickOnce - unfortunately.
To deploy Add-in's for Visual Studio, visit http://msdn.microsoft.com/en-us/library/dd393694.aspx.
I'm pretty sure that you cannot do this. ClickOnce is designed for side-effect free deployments, and don't impact registry (except perhaps for file associations) or "Program Files" (having their own repository).
I'm pretty sure you'll need msi for this.