07-28-2017 04:04 AM
07-28-2017 04:04 AM
We have two site collections in Sharepoint online and those have respective document libraries (Say Lib1 (Site collection 1) and Lib2 (Site collection 2))
We have ASPX page on drive which are uploading through powershell inside document library.
Upload through powershell
Upload manually/ Drag drop
I am really puzzled. whats making Lib2 to download the aspx page when uploaded through power-shell.
Have you seen such issue before?
Dont think its an issue with Powershell script, as its working fine on Lib1.
Not issue with library also, as when manully ASPX is uploaded manully it opens fine in browser
07-29-2017 04:58 AM
08-01-2017 01:52 AM
Which content types does the ASPX file get in each library? Are they the same?
08-01-2017 02:40 AM
08-01-2017 02:41 AM
08-01-2017 03:12 AM
09-18-2018 01:45 PM
I have the exactly same issue ...
Anyone knows how to solve this ?
11-13-2018 12:29 AM
Same issue here. In one Site Collection I can view my ASPX pages, in another (a Microsoft Teams SharePoint site) the file is prompted for download...
11-13-2018 01:24 AM
11-19-2018 12:08 AM
05-18-2019 02:51 PM
@Steven Derveaux Worked for me too! Thank you for posting this.
10-18-2019 03:34 AM
@Rohit Devmore - Thanks for your post. I also stumbled across similar behavior of ASPX file in a Document library in SharePoint Online. Initially, I followed most of the suggestions to solve this.
Unfortunately, the issue remains same - ASPX files are downloaded in all browsers instead of rendering in browser. Even if I try to access the ASPX file with direct link SharePoint show 'Something went wrong' - 'File not found'. Here is the URL format I tried: https://[tenant].sharepoint.com/teams/team1/testlibrary/myfile.aspx
After my analysis, I found that the ASPX files should be uploaded by 'Site Owners' and not by the members or of the site. Once I re-uploaded the ASPX files as a 'Site Owner' using the standard upload feature in document library all of the ASPX files are being rendered in all browsers instead off download prompt.
It looks like SharePoint internally assign some internal flags for the ASPX files uploaded by Site Owners. If we try to 'Copy Link' we can see the differences between the files uploaded by Site Members and Site Owners.
Here is an example:
Link copied for file uploaded by Site Owner - https://[tenant].sharepoint.com/:u:/r/teams/team1/testlibrary/myfile.aspx?csf=1&e=fi6Pme
On the other hand link copied for file uploaded by Site Member - https://[tenant].sharepoint.com/teams/team1/_layouts/15/download.aspx?UniqueId=[GUID]&e=ZepFn
The later link clearly instruct the browser to download the file.
This saves my day. I thought this might help others whosoever face similar issues in SharePoint Online.
10-05-2020 05:04 PM
@tapansam Unfortunately, I don't believe this is the whole story as I am a member of the Owners group of a site but still cannot get aspx to run. I believe that the site must allow scripts to run, also. Here's a SO post that goes into it a little: https://sharepoint.stackexchange.com/questions/237928/how-do-i-allow-the-documents-library-in-an-off...
10-06-2020 10:36 AM
@SPWade In fact, let me just follow up on this a little more. Unless you have Allow Custom Scripts turned on / enabled for your site you are only going to be able to create a new aspx page via the UI (or Designer) and that page will only be allowed to run certain web parts on it. Once you try editing the page and putting any custom script on it (or just editing what's already there and adding a simple space, then saving), it will break. Even the Page Viewer webpart is not going to work for viewing, say, an HTML page or a 3rd party page without custom scripts enabled.
Obviously, this is a security lockdown because someone with editor access to a page could put in some hidden script that acts on behalf of the user to, say, post some of their information to a list or activate a workflow.
The only alternatives I can see are a) enable custom scripts, b) put your customizations into an Add-In (App) and publish them to the SP store so they are trusted, c) redirect the user away from SP to an external system that hosts the content (and optionally use the SP API to interact with data - again, sorta the App approach without the overhead of dealing with, say, SP admins), or even d) have the user sync a folder with the content down to their local system and launch the content from there. Again, that's just another variation on external hosting. And is probably a nightmare to support.
Or, e) find a new environment to work in where you don't have all the ridiculous restrictions and vulnerabilities (worldwide MSFT outages, anyone?) of SP. 5000 item list limits - from 1998 - and explaining why they are ridiculous to SP admins is so fun and productive!