In this doc, it is mentioned that
The following features aren't yet supported in the Developer Preview.
... ...
Publishing add-ins to the Office Store or Office 365 centralized
deployment that use custom functions.
I just want to make sure it means that at the moment we cannot submit to Office Store any add-in that has custom functions; what we can do is only internally deploying add-ins with custom functions, right?
Your interpretation of that guidance in the documentation is correct. i.e., an add-in that uses custom functions cannot currently be published to the Office Store or via Office 365 centralized deployment.
For information about other ways to publish an add-in, see Deploy and publish your Office Add-in.
Was meaning to reply back to this, but add-ins with custom functions are available to be submitted to the Office Store, as announced here: https://developer.microsoft.com/en-us/office/blogs/office-extensibility-build-2019/
Note: Centralized Deployment is still being deployed through all tenants and that will take a few more weeks to complete.
Related
I have an OfficeJS Excel add-in that I want to deploy in an environment, where neither centralized deployments, nor a SharePoint catalog is available for distribution.
Loading the add-in via a shared network drive works, but according to the microsoft docs this is not an option for a production deployment.
Other add-ins in that environment are all VSTO based.
Now my question is, if it's somehow possible to deliver the web-based add-in via a VSTO wrapper?
Would it alternatively be possible to provide the manifest on the the local drive for each user somehow?
EDIT:
Just to make it clearer - still want to serve the web-app via a server. I basically only want to distribute the manifest differently.
Loading the add-in via a shared network drive works, but according to the microsoft docs this is not an option for a production deployment.
When production options are not available, all other possible ways are good.
my question is, if it's somehow possible to deliver the web-based add-in via a VSTO wrapper?
To deliver the manifest is not enough, so you need to sideload the add-in by adding the manifest file to the Office application. Isn't better to provide URL to the network share where manifest resides to users? VSTO is useless in that scenario. OfficeJS (not Excel) doesn't provide any API for loading web add-ins programmatically.
Would it alternatively be possible to provide the manifest on the the local drive for each user somehow?
There is no need to keep the manifest on the local drive. You can provide URL of the manifest to sideload the add-in if the centralized deployment is not available (via the Office365 admin center).
Read more about possible routes in the Deploy and publish Office Add-ins article.
I started recently to build a office add-in (the web-based ones, not VSTO) and I would like in addition to have it in the office store (the preferred method of distribution) to also distribute the manifest through a setup file. Is this possible?
I searched around the web but the only things that come up are for VSTO add ons.
Web add-ins are not designed for distributing via standalone installers like MSI. You/administrator can sideload them for the organization unit (OU) or just install them from the store. See Centralized Deployment via the Office 365 admin center for more information.
I am developing with Word Web AddIn by Office.js. Now I want to publish it to my on-premises environment.
After check Deploy and publish your Office Add-in, it seems only SharePoint catalog supports SharePoint on-premises. But for this docuemnt, it shared the steps for Sharepoint Online instead of premises.
Interesting. It seems that when Microsoft renamed "apps for Office" and "apps for SharePoint" to "Office Add-ins" and "SharePoint Add-ins", the UI of SharePoint Central Administration was not changed. But whoever wrote that second article that you linked to thought that it had been changed. (Or maybe it was, but your SharePoint on-premise doesn't have an up-to-date build.) I think that when you get to step 2 of the article you linked to, you will find an "Apps" on the left side of the page instead of a "Add-ins". So just follow the directions in that article but in your mind replace "Add-in" with "App" in all the steps.
Another possibility is this article I found. Try using this, if the suggestion above doesn't work: Manage the App Catalog in SharePoint Server.
I have a question about Sharepoint Online debugging.
I've created a Sharepoint app with Visual 2015, destined to sharepoint-online and it's sharepoint hosted. Inside, I have a very simple workflow.
When I try to debug it, the following message appears:
Is it necessary to have an Azure account to debug a workflow? Are there any other options in workflow development?
If it helps, the deployment environment is Office 365.
It is necessary to have an Azure account to debug SharePoint Online/Office 365 workflows. This is because you can't access certain components that are used for debugging a local SharePoint workflow. Instead Microsoft created the Relay Service component of the Microsoft Azure Service Bus. (A secure component that they charge for hosting)
Before this component was released it does't appear debugging was possible. (See article below)
Debugging Workflows In SharePoint 2013 Online using Azure.
If you have an MSDN subscription or work for a Microsoft partner organization you should receive some free access to Azure.
Workflow debugging for SharePoint Online requires a Windows Azure Service Bus connection.
To enable remote debugging:
With a project selected in Solution Explorer, Right click on the Project menu ans select Properties.
Click the Debug tab.
Select the Use remote machine check box.
In the Use remote machine field, enter the name of the remote machine, using the format \\domain\machinename.
I'm looking at upgrading my current TFS instance and planning to copy and restore databases as per Microsofts Advanced Upgrade which means I am pretty much installing the new product from scratch and restoring the databases then running a migration tool.
I see in the installation notes that you can integrate SharePoint with it as an optional extra. Why would I do this? Is the idea to store project documentation in a SharePoint Document library per project and be able to link to that content rather than as an attachment to the Backlog Items and Bugs in TFS?
I'm having trouble finding any documentation of team workflows with SharePoint and TFS and I suspect that its because no one really does it.
More importantly would SharePoint integration impede future product upgrades or moving to Visual Studio Online?
In my eyes, SharePoint as a TFS portal has become much less desirable due to the improvements in Team Web Access (eg Charting) but it still has some uses.
With the integration enabled, you will see a Documents tab in Team Explorer which will take you to the dedicated SharePoint Portal (created when you create the TFS Team Project) where all your documentation can be stored. Of course without SharePoint integration you can still happily link Work Items to documents in SharePoint, you just don't have a dedicated portal created for you.
If you are using one of the MSF process templates then some useful documents are created for you on SharePoint when you create the Team Project (xlsx reports etc). However, if you are using the much better VS Scrum template then no documents are created even if you have SharePoint integration enabled.
If you are using the Enterprise edition of SharePoint then you get some good dashboards (bugs, code quality etc.) and you can also publish your custom excel reports easily. This functionality requires Excel Services and so is not available in the standard edition (there are some dashboards created but they aren't that useful).
Share information using the project portal
https://msdn.microsoft.com/en-us/library/ms242883.aspx
Your team can use the SharePoint portal to share information in the following ways:
Share data contained in reports or dashboards
Share team progress using predefined or customized dashboards.
Share documents, files, images.
Share team knowledge and processes using the SharePoint wiki.
Reference process guidance for select team project artifacts.
If you want to add a portal to an existing project:
Configure or add a project portal
https://msdn.microsoft.com/en-us/library/ms242865.aspx