Deploying WebParts and Extensions in SPFx - sharepoint

We have a solution with an app extender (mega menu and some look n feel jquery teicks) and a web part.
We are trying to deploy it. It's pretty easy getting the dev version in the App Catalog and running it with local scripts. The extender doesn't seem to show up l, however the web part is working.
We want to know if we can deploy a shipping or production version without deploying Scripts to an o365 CDN. This part is not clear since we thought we could just package all and throw it into the App Catalog...
Any guidelines if we don't want to use the CDN?

If you don't want to use CDN, as a workaround, we can create SharePoint Library as CDN.
1.Create a document library(named "SPFxDeploy") in your SharePoint Site, and give read permission to all users.
2.Configure SPFx Solution for SharePoint Library, open package-solution.json file from config folder and set includeClientSideAssets value as false.
3.Update CDN Path, open write-manifests.json file from config folder and update CDN base path as SharePoint library URL.
4.Prepare the package using "gulp bundle --ship", then upload the files from "temp\deploy" folder to SharePoint library.
5.Upload package to the app catalog.
Reference: SharePoint Framework - Deploy SPFx WebParts to SharePoint Library

Related

Publish Excel Add-in via FTP

I'm playing with Excel Add-ins, and I'm not a specialist, so having read the documentation, I still find it complicated to publish and install it.
Basically, all I did was the very basic Excel Add-in described in the documentation and now I'm trying to figure out how to install it in Excel.
I see everywhere that this is vrey simple, all you have to do is to upload the XML manisfest file, etc. but using Visual Studio, I chose publish via FTP and I get 3 folders in my website:
Content
Functions
Scripts
These are full of js scripts, but I don't see the manifest file nor the home.css, Home.js and Home.html
Isn't it possible to just upload the files with Filezilla to a folder? Which files?
If so, then how do I install the addin in Excel?
Thank you so much for helping!
The manifest goes to a different place than the files in the web application part of the add-in. Please see this article and the links in it for the details of how to publish the web application and deploy the manifest: Deploy and Publish your Office Add-in.
UPDATE 1/10/19:
Some additional information in light of the OP's comments:
Please start with this article: Office Add-ins to get an overview. You will see that there are two main parts to an Office Web Add-in: (1) The manifest and (2) a web application.
The manifest can be sideloaded or deployed using several methods. For more information on publishing options, see this node of the documentation: Publish.
The web application can be published/hosted using any method or platform that you want. We don't give instructions for most methods because this information is already available on the web. However, this article, Host an Office Add-in on Microsoft Azure, explains how to do it on Azure. I recommend that you try that method of hosting first. Note that in step 6, you edit the manifest to point to the URL of your web app. When you feel familiar with the distinction between hosting the web app and deploying the manifest, you can try an alternate method of hosting the web app. No matter which method you choose, you will edit the manifest in the same way.

umbraco deployed as azure web app - content not showing on site

I've got an umbraco site which I deploy to an azure web app service. The data is on an azure sql database. I have been able to deploy this successfully, and can verify that all the data I expect to be there is present in the content view.
However I have added content on various pages, in rich text editors, and on my local site I can see this content on the site. But on my deployed site the content in rich text editors is only visible on the content view, not on the site. I've tried publishing each item but nothing will appear.
What else can I try?
Umbraco needs some additional configuration to be treated properly on Azure. It especially affects indexes and XML caching file.
Please check the following blog post made by one of the Umbraco HQ Core developers - Sebastiaan Janssen: https://cultiv.nl/blog/making-sure-your-umbraco-site-performs-on-azure/. Go step by step to ensure if your app is properly configured.
Going further you may be in need to also ensure proper configuration for load balancing, which you can find here: https://our.umbraco.org/documentation/getting-started/setup/server-setup/load-balancing/flexible
I found the answer after a much experimenting.
I had not manually included in my project (and thus not deploying) Views/Partials/Grid/fanoe.cshtml. This file includes the and I guess I was using some default template which is using this file, rather than the other grid templates in the same folder.

SPSolution Pages: Where are they found?

I am currently training on sharepoint and have few weeks experice with regards to development in sharepoint. My current task involves deploying a .wsp solution on a server farm, and did that using the powershell through the Add-SPSolution, Install-SPSolution, and did that successfully. The problem I am encountering is that in the spsolution I had a webpage named TestPage.aspx, I cant find where the page is residing such that I can access it. there a specific place where the page resides or any command which I can use?
Visual Studio usually creates a folder for application pages, so you may try:
http://server/site/_layouts/foldername/TestPage.aspx
where foldername is the name of your project/solution.
If you get "The resource cannot be found" - HTML 404 error, the site is not there.
Otherwise, even if it says "An Unexpected error has occurred" it does not mean the site is not there.
The site may exist, but has some errors. In that case the best way would be to check Windows Event Viewer and logs.
You cannot just add an aspx file and deploy on sharepoint.
Maybe what you are after is how to deploy an application page, an application page sits at the application level, so every site collection will be able to access it.
How to deploy an application page:
To add an application page do the following:
create a new empty sharepoint project
add "Sharepoint "Layouts" Mapped Folder to the project
in layouts folder create a folder (usually the name of the project)
add an application page to that folder.
that application uses sharepoint masterpage, put some content in.
Deploy using visual studio or compile and deploy the wsp using the method above
access the page in /_layouts/foldernamed/test.aspx*
If you are looking only to add some content to a sharepoint page, then I suggest you use a visual web control. it is basically a user control wrapped in a webpart. After deployed you can add it to a webpart page that you can create using the Sharepoint UI.

Deploy custom web service to sharepoint server(2007/2010)?

According to MSDN, for deploying custom web service, we need to create *wsdl.aspx and *disco.aspx files, and put them with .asmx together under _vti_bin folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\isapi). And put the dll under bin folder of the root of sharepoint virtual directory. It works correctly for me.
However, i also found that if i put .asmx file under the root virtual directory without creating those *wsdl.aspx and *disco.aspx files. It can work as well and much easier than the above way. So i'm wondering what's the potential issues in this way?
Without the WSDL and DISCO files, folks' web service clients/consumers may have a hard time "discovering" your service's contract. If that's not a concern for you, don't worry about it.
I have created several web services in SharePoint 2007 that were simply deployed as http://.../_layouts/mySubFolder/service.asmx. It works! For SharePoint it does not matter whether the presentation layer is HTML or XML for a web service (in both cases security must be applied, can be addressed both as http://server/_layouts/mySubFolder/service.asmx and http://server/sites/subsite/_layouts/mySubFolder/service.asmx
Things that are wrong thing about it
the word "layouts" implies "something to do with how it looks like".. which is not the case when we speak about web services
when migrating to SPS2010 where WCF services come into play, it will be different. However, I have not yet played with SPS2010 and do not yet know, how different. (Somehting about it here - http://blog.mastykarz.nl/wcf-sharepoint-context/)
Quite an old post but just thought i'd add to this as I don't believe the responses to date give the relevant detail on why SharePoint is setup this way.
The reason why you deploy webservices to ISAPI\vti_bin for SharePoint is because there are specific modifications made for requests to this folder to allow SharePoint to build an accurate discovery and WSDL file for the service based on the current virtual path of the service, not the path in the IIS site.
More specifically wsdisco.aspx and wswsdl.aspx handle requests to this virtual directory and will call the relevant disco.aspx and wsdl.aspx to generate the discovery xml or wsdl xml correctly based on the current SharePoint url.
If you add a service reference to your project for http://sharepointsite.com/sitecol/subsite/_vti_bin/lists.asmx the context for requests made on that url will be relevant to /sitecol/subsite as you would expect.
However if you add a service reference to http://sharepointsite.com/sitecol/subsite/_layouts/MyCustSvc.asmx the context will be fixed to http://sharepointsite.com/ because the default wsdl generator for ASP.NET is not aware of the SharePoint virtual paths. In which case calls to SPContext in the service will not work as expected.
There is an excellent post here with examples explaining this:
Where do you deploy custom SharePoint web service files to?

Building sites besides sharepoint site template

During site creation using SharePoint, SharePoint offers some templates. If we need to create a site other than a template offered, how should we proceed?
You have 2 options:
Site Templates
Site Definitions
Many people use those terms interchangeably, but there are big differences between the two.
Site Templates
Site templates are easy to create. Basically, you create a site using a ite definition (e.g. the blank site) and start customizing it. You can add lists and libraries and setup the site however you want it. Then, go to Site Actions > Site Settings > Save site as template. You can save your site as a .STP file. The .STP file basically records everything that you added or changed on your site after site creation.
Once saved, your site template will show up in your site template gallery. You can go to the site template gallery and save the .STP file offline. Your new site template will be available in the subsite creation page in the "custom" tab. The template will only be availalbe in this site collection, unless you add the .STP file to the site template gallery of another site.
You can deploy site templates globally. So, if you want everyone to see a STP in their subsite creation page, you can run the following stsadm command:
stsadm -o addtemplate -filename BoardDirectors.stp -title "Board of Directors"
You can retract site templates whenever you want without affecting the sites that used them for creation. This makes them easy to version, as long as you don't want to push updates to existing sites.
One big problem with site templates is that you cannot staple features to them.
Site Definitions
Site definitions are collections of XML files deployed to the 12 hive. They are harder to develop; you basically have to use Visual Studio. The XML files have to be packaged into a SharePoint WSP and deployed using STSADM.
Creating a site definition gives you the most control over your site. Another benefit is that sites using the site definition will always reference the site definition's files, so updates will be recognized by sites using that site definition. For example, if you find a bug, you can fix it in one spot and all sites using that site definition will be fixed.
Note that withdrawing a site definition will break sites that use it.
Recently, many SharePoint experts have recommended staying away from creation new site definitions because of the overhead. Instead, if custom functionality is needed, they recommend coding custom features and just activating those features on sites.
Think about which option you need. In our organization, we chose not to create any new site definitions, and use site templates sparingly. Custom functionality is driven primarily by the use of features.
You are talking about custom "site definitions" and custom "site templates". Google those terms and you'll find tons of information.
You can design your own custom templates. Install VSeWSS extension for Visual Studio and it has a project type called "Blank Site" template. You can use it as a base starting point and customize the solution generated to your needs. All the information required to do so is available in the help document that comes with VSeWSS.

Resources