We have Microsoft Office 365 ProPlus Subscription.
Version 1806(Build 10228.20021 Click-to-Run)
Monthly Channel(Targeted).
I have downloaded the Custom Function sample from https://github.com/OfficeDev/Excel-Custom-Functions and deployed that in my IIS. I have changed the local host accordingly in all four places. Created the manifest file .I have shared that manifest to my name. Now am able to see the "Custom Functions Sample" in Office Add-ins SHARED FOLDER but when i try to type =Contoso in my excel the custom function is not coming. Need Help on this.
I'm pretty sure you have to sign up for the Insiders program (https://products.office.com/en-us/office-insider?tab=Windows-Desktop) which appears to be something of a beta program. You run pre-release versions of office - these have the custom functions capability. You'll probably want to do this in a virtual machine if your dev machine is used to build/test production add-ins,
Related
I had developed azure function solution in Visual Studio 2019 and deployed to azure function by downloading publisher .
But accidently I had deleted entire source code in local machine where I could not get even from "recovery software tools" also.
is there any way can I get source code files from azure function development tools in azure portal? or local machine C drive?
If you open up the Azure Function App Service and navigate to the "Functions" section you will be able to open your individual functions and then select the "Code + Test" section and be able to see your function
I don't know if the type of Function you developed impacts your ability to see this source code or not.
When you deployed through Visual Studio, the source was compiled locally and only the DLLs were uploaded. Thus, you cannot directly see your code. However, you can get to your DLLs and download those. Then you should be able to use any decompiler to see your source code again (maybe not as pretty as originally...).
Go to the SCM console to see and download all files: https://{YOURFUNCTIONNAME}.scm.azurewebsites.net/dev/wwwroot/
I am developing a chatbot azure service, which I want to integrate within Microsoft Teams. So far everything is working but the "re-install" of the package in the Microsoft Teams.
I created a publish "folder-profile". Then I zip the result with the manifest.json and the icon files inside. I go to the Manage Team section and in the Apps tab I select upload a custom app. Then I choose the .zip file and the service seems to be there(Actually it is there)
It works, but when I create a new version and I repeat the described steps, it seems like Microsoft Teams is still using my old code.
I test the chatbot in the Chat by using #"APP-ID" and I see how my changes work, but installed as an App for the "Team" keeps the old version.
I tried to uninstall it, check if the bot is gone(it is gone) and then upload again, but some kind of cache is there and the bot behaves like in the previous version.
Any idea how is the correct way to deploy new versions of my app in Microsoft Teams?
I think you need to upgrade the version number in the manifest.json file (you can do it in the manifest.source.json before to generate your zip).
I am working in SCCM,while installing SAP Bussiness object Analysis ,MS Office is one of the prerequest.I need to add a condition in Task sequence to check the version of MS office architecture before installing SAP.
I got registery path to check that "HKLM\SOFTWARE\Microsoft\Office\15.0\Outlook"
BITNESS =x64 or x86. if the machine don't have outlook this wont work.
So i need a WMI query to check the bitness or a any other registry path to check the bitness of office . please help
I wouldn't bother with a WMI query, just create a task sequence for deploying SAP and use conditions to determine if Office is installed or not. It'll be much easier in the short term.
I would do this outside of the task sequence. How I will do is:
Method 1:
- Create device collection based on the condition (I would prefer using hardware inventory data to filter)
- deploy the SAP Application/package to the 'correct' collection
Method 2:
For application type of deployment, there are 'Requirement' settings on the deployment type. What you need to do is to create a registry based Global Condition (almost clicks-and-types-and-clicks) and attach this to the SAP application deployment type.
If you are not familiar with Global Condition, below is an official document link URL which will get you started:
https://technet.microsoft.com/en-us/library/gg682048.aspx
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH