I developed an Microsoft Office Add-in for Outlook which forwards e-mails including some specific user-managed content. The add-in is hosted as a static website on GCP according to this Microsoft documentation. Everything works fine, but I need to know where data is transferred to and how I can prove it.
I need to prove that the Add-in only reads (GET) from GCP (the HTML, CSS & JavaScript files) and storages them locally (temporarily). This should be the case, because when I load the Add-in and then take down the GCP server, the Add-in including all functionalities still works for +/- 15 minutes.
How can I best prove that my Add-in reads the static files from GCP and stores them locally? I cannot find any Microsoft documentation on this.
Your add-in acts like a web site which is loaded locally and cached temporarily depending om the MIME header property values.
The Office cache folder is described in the Clear the Office cache article. Don't forget about the browser cache folder.
I am new in Office 365 Add-ins. I want to know about caching. I am working on a Add-In using Office.js. I want to manage caching.
Scienario:
1- Add-In will get data from server once in a day. Data can be in MBs(i.e 5 MB).
2- It should store somewhere. So, user can use it even there is no internet connection.
Is there any internal caching mechanism provide by Office APIs?
I was also thinking to store in File. Is it possible to create and manage File using Office Add-ins in Windows and Mac?(I am just curious about File permission in Mac)
Please suggest
You need to read through the following resource: Persisting add-in state and settings. Depend on the Office application you are writing your add-in for you would need to use different objects or approaches (for example use HTML5 web storage, etc.)
I am creating a wp7.1 silverlight application and want to access azure blob and table storage directly. Searching all over the internet I can see using web application but I dont want to use web application for my silverlight application.
Is there a direct way to access azure storage directly from wp7.1 application?
You can use WP7AzureQuickstarts Library to start your project. This library has following 4 C# based project with full source code:
WP7AzureDirectory
WP7AzureLocator
WP7AzureNextGroupEvent
WP7FacebookAzure
If you download WP7FacebookAzure source code and look for WindowsPhoneCloud.StorageClient library which has full source code to access Azure Blob, Table and Queue storage directly from WP7 client application. You may need to understand security, SAS etc going forward.
Also you can download Windows Azure Toolkit for WP7 source and modify the source code the way you would want to use.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
We've developed a custom Outlook 2003 form based on ipmNote. I need a way to push this to all the other users in the organization. At the same time we'll also be installing a custom Add-in built with VSTO so we could do the form install as part of that.
Currently I can't use the Organizational Forms Library, because the exchange admins don't want to turn on public folders.
Why do you need it to appear in the user's Personal Form Library? If it's being published to everyone in the company, you would normally publish it to the Organisational Forms Library on the Exchange Server.
When your users opened the form for the first time, it would be pulled down to their local machine and stored in an application folder within their Documents and Settings.
Have a look at http://www.outlookcode.com/article.aspx?id=34 for some helpful information