I've created multiple custom application pages using VS 2010 and have deployed them to my SharePoint site.
I'm running into an issue when trying to reference these pages by a URL...
If I use http://myserver/sites/mysite/_layouts/MyApp/MyPage.aspx everything works perfectly, and I can view my pages.
If I use http://myserver/_layouts/MyApp/MyPage.aspx I get a HTTP 404 Not Found error.
Is there a way I can navigate to my custom page by URL without a specific site reference? Everything I've looked at says that I should be able to access this page directly from /_layouts but it doesn't seem to work.
Note: If I look at the folder "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MyApp" on my server, I see all the aspx pages...
Have you tried another browser? I only have this problem using Firefox, Internet Explorer works perfect. Tried this?
Since the page works on one Site Collection but not the other, it seems to indicate a feature scope issue. However, I'm not sure how this would interfere with pages under _layouts.
Is your application page associated with a Site Collection level (or lower) scoped feature?
If so, is that feature activated on the root Site Collection (http://myserver in your example)? Activating the feature or expanding its scope may well resolve the problem.
Related
The Problem
I have a website running in IIS. If I rename or delete one of the layout page .cshtml files under /Views/ the site immediately begins throwing following yellow screen error as expected
The layout page "_Layout.cshtml" could not be found at the following path: "~/Views/_Layout.cshtml".
What surprises me is that if I recreate or rename the file so it is exactly like it was before, the yellow screen persists. Why is this particular 500 error sticky?
I currently think that this has something to do with IIS and is specifically related to error handling. The site immediately detects that the layout page file is missing. It does not immediately realize when the file is back in place.
Thanks!
Some interesting clues
This happens on all of my sites I've tried this on so far. It isn't related to a specific site
I tried this on two websites at the same time. On one site I repeatedly and consistently refreshed the page hoping for a success. On the other, I left it alone for several minutes before checking again. The site I leave alone will resolve its problems and find the layout page on disk again. The site I continually make requests to appears to display the error indefinitely.
What I've tried
I have reproduced the problem on Umbraco websites using Umbraco's default routing as well as regular MVC pages using custom routing. The problem is the same for both.
I don't have output caching configured in IIS
When I am reproducing the yellow screen error, I am able to reproduce the error in multiple browsers, so I don't believe it is related to browser caching
I checked on the httpRuntime in the root web.config and the fcnMode is set to fcnMode="Single"
I've fiddled around with the web.config customErrors and httpErrors. Nothing I've done here has affected the problem.
I am able to reproduce the problem on websites where there is no custom code for caching. No CDN. No load balancer.
Versions
IIS: I have reproduced the problem on Windows Server 2012R2 running IIS 8 and Windows 11 running IIS 10
CMS: All of the websites I have tested on so far are Umbraco 7 sites. However, I have reproduced the problem on pages that are routed using Umbraco's out of the box routing as well as pages that are just set up using MVC and aren't leveraging Umbraco.
It appears to be part of the behavior of FcnMode="Single". See https://learn.microsoft.com/en-us/dotnet/api/system.web.configuration.fcnmode?view=netframework-4.8. It isn't an issue with caching. It is a problem with the way that the site's file change notifications (FCN) are configured.
The sticky 500 behavior on renaming files happens when I use FcnMode="Single" but not when I use FcnMode="Default".
FcnMode="Single" will result in only a single object to monitor file changes. This single object is responsible for monitoring changes to files in the main directory and sub directories.
FcnMode="Default" will result in a separate object to monitor file changes for each directory.
Umbraco sites, by default, use FcnMode="Single". This makes sense because Umbraco sites cache under very deeply nested directories in /App_Data/. This can result in so many of these monitors that it can affect the performance of the site. There is a great explanation of FcnMode and why it matters for Umbraco here: https://shazwazza.com/post/all-about-aspnet-file-change-notification-fcn/
Unfortunately, it appears that the single file monitor can miss renames of files in some cases.
After publishing a MVC5 web application of mine to my IIS server (Individual User Accounts), it would seem that the URL is accessed incorrectly.
During debug, it would be e.g http://localhost:1234/api/Account/UserInfo?=XXXXX
The debug works just fine. The only issue kicks in after I've published it via my IIS7 server.
After publishing and using Google Chrome's console, it would appear that the page is requesting for a resource at mydomainname.com/api/Account/UserInfo?=XXXX instead of mydomainname.com/WEBAPPLICATIONNAME/api/Account/UserInfo?=XXXX.
My best guess is to modify the URLs in /Scripts/app/app.datamodel.js but it would just cause more parsing problems.
I've searched around and can't seem to find any related problems. I hope someone here will be able to lend a hand.
Look like you are using relative path like "/api/Account/UserInfo". Instead i'll recommend you to use #Url.Content("/api/Account/UserInfo"). This will solve your problem
Explanation
In local system when we run application in WebDev server it never have sub folder (like WEBAPPLICATIONNAME) therefore you relative path work correctly. but when you host your application in IIS under Default website in another new website /Virtual folder (like 'WEBAPPLICATIONNAME') then "/api/Account/UserInfo" fall back to Default Website because for '/' in starting. #Url.Content or #Url.Action make sure to add virtual directory name, hence changing your path to "/WEBAPPLICATIONNAME/api/Account/UserInfo" in IIS.
I have a new SharePoint server which I've attached a content database to. The new server is configured like the old one (same deployed solutions, settings, etc) and there was no errors when we attached the content database (which is a copy of the old server's content database).
At first, it looked fine, the site on the new server was working. But then we discovered that som sites couldn't be reached, when we try, we'll get a "404 File not found" error. The strange thing is that we can clearly see the sites in Manage Content Structure but when we try to open them, we get errors.
The error only occurs for a site called "Webbplatser" and all of it's subsites. The other sites, like Sök is working just fine. I can browse all the sites under "Webbplatser" without any problem from "Manage Content and Structure". I can see the default.aspx page for all the sites but when I try to open any of them, I'll get the 404 File not found error.
Anyone recognise this error? We are using Sharepoint 2007. Please help.
Sounds like there could be some site solution missing, perhaps even custom master pages or page layouts that were added in the 12 hive on which the Webbplatser site is reliant.
Use the the url of the webbplatser site and tack on the _layouts/settings.aspx to see if you can get to the site settings and see what is set up there. Failing that I'd do a directory tree compare between your old server and the new one, focusing on the 12 hive.
This used to work fine, but recently it refuse to load the default page for an empty route, instead it lists directory contents.
for example
http://localhost:1234/ should take me to the same page as http://localhost:1234/Home/Index assuming global.asax hasn't been modified, however recently it just takes me to "Directory List -- /" and lists out the content of the project folder.
This is using the ASP.NET Development Server. The sites work fine when deployed into IIS on a server.
Does anybody have any ideas, this is really annoying!
I would check the project settings like suggested on this other question:
Launching my debug MVC3 application opens a specific .cshtml file in the browser
Through trial and error I've determined that this is caused by the IBM RTC plug-in, when disabled it works normally.
I find this very surprising, but I've double checked and it is definitely that!
I'm using Visual Studio's built in web server to test and EPiServer applicaiton. When I have the app running in IIS, if I hit the root of the virtual directory, EPiServer will take over and server the defaul page to me. Using the Visual Studion server (which I am doing for license reasons with the SDK), it always gives me the 'Directory Listing' view of my site. Does anyone know how to configure this web server to not allow the directory listing/browsing?
Additional Information:
This problme only seems to effect the root of the visual studion web server (i'll call it cassini from here on in). As an example, if I run a site from localhost:6666, then what I will find is that localhost:6666/en/ will work just fine and the EPiServer VPP will know what it is doing. If I use localhost:6666/, then the VPP never kicks in (or so it seams). It seems to me that when the root of cassini is hit, it checks to see if the page exists (which it does not as I have no default). If it decides that the page does not exist, then it serves up the directory listing, rather than 404. The first thing to do for me is to dispable directory browsing in cassini, then look at why the VPP is not being actioned correctly.
So I suppose the base of the question is: Is there a way to modify these settins in Cassini when it is Visual Studio starting everything off?
(EPiServer may be a red herring, but just in case, it's CMS version 5)
Further Update
I managed to get hold of the source for Cassini 3.5 and gave that a whirl. 3.5 works just fine and behaves like IIS in this instance. I.e. the lack of default document does not lead to a Directory listing, rather if allows the HTTP handlers to kick in and then EPiServer does the rest! So the question is, can I achieve the same in Visual Studios effort at a web server?
Make sure you have a ~/Default.aspx file. It won't render, but it's needed in cassini for the virtual path providers to get a chance to handle the request for '/'.
Of course, if you make it anyway you might as well use it for the start page :-)
Even if you could get the server to not show the directory listing, could you get EPiServer to take over?
EDIT: From comments
The fact that it works with /en/ makes me think this is something that Microsoft could fix. I suggest you ask the vendor if they have a workaround. If they do not, then please create a suggestion at http://connect.microsoft.com/visualstudio/. Be sure to specify details about EPIServer, URL to the vendor, etc.
Be clear that it works with /en, but you want a setting permitting it to work at the root.
Once you create the suggestion, please edit your question to include the link to the suggestion you create. That way, others reading your question can vote on how important they think this is.
The EpiServer part confuses me. However, if you are asking how to set the default page for the VS development server (based on the Cassini code), you're expected to do that in the project properties (right click on web project), Web, Start Action, Specific Page, foo.aspx.
I suspect the cassini/VS development server doesn't have a default page feature-- the source code for the cassini server (the ancestor of the VS development server) is on the web and you can check that and add a default page by building a custom version. And it doesn't have a very long list of other features that IIS has.
Which EPiServer version are you running?
Did you install it using EPiServer Manager?
There has always been some differences in the configuration between running the site at the root of a host name or as a (virtual) directory.
Check the site settings block in web.config and make sure you have a default.aspx at the project root.