I deployed a brand new site on IIS. It is in .Net 6. I am getting a 500.19 error that it cannot read the configuration file due to insufficient permissions.
\\?\D\Sites\SiteDirectory\wwwroot\web.config
The problem is this web.config file that it is pointing to is not the one for my website. It is looking for a web.config in the wwwroot directory for some reason. As a matter of fact there is no web.config that even exists at that location.
The correct web.config file exists in
D:\Sites\SiteDirectory\wwwroot\SiteName\web.config
Why is IIS looking at wwwroot? How can I fix this behavior? My other .Net Framework 4.7 sites work fine without this web.config at the root directory.
I solved it by installing this component:
Windows Hosting Bundle
"https://dotnet.microsoft.com/en-us/download/dotnet/thank-you/runtime-aspnetcore-6.0.6-windows-hosting-bundle-installer"
Related
I have attempted to migrate sites from an old IIS 7 server onto a new IIS 10 server by using the following appcmd's:
Commands ran to export from IIS 7
appcmd list site /config /xml > "h:\temp\iis export\sites.xml"
appcmd list apppool /config /xml > "h:\temp\iis export\apppools.xml"
Commands ran to import to IIS 10
appcmd add apppool /in < "h:\temp\iis export\apppools.xml
appcmd add site /in < "h:\temp\iis export\sites.xml"
This ran without errors, and the new IIS 10 listed all of the old sites. The configuration files were also altered to reflect a change in file paths and local IPs which were updated without problems.
The problem is that whenever I select a site within IIS, and go to any of the properties (in the below example logging), it throws an error stating that it cannot find the file path for the web.config.
The file path is correct, but there appears to be a \\?\ prepended to the file path. I don't know if this is the reason why this error is occurring, nor how to correct this.
Any suggestions would be grateful! Thanks, Radderz
In this instance it turned out to be that he URL rewriting module for IIS was not installed.
Annoyingly the error message produced for if a configuration file contains an element that is not installed is simply that it cannot read the config file, rather than which tag was the cause.
I opened an existing project in VS2015, made some small changes and published the MVC application to my webserver with an existing WebDeploy publishing profile. This broke the application because the web.config file on the server was overwritten with the original one for my developers machine. I have checked the settings in the Publish-wizard but the configuration was like always before. I could fix the application by manually changing the web.config on production but am afraid now to publish again.
Has anything changed in the WebDeploy publishing method with web.config transformation?
I solved it. In my case the publishing profile was renamed to "servername (production)" and the configuration setting for the transformation was only web.servername.config. After changing the name of the publishing profile to the exact same name as the config setting it worked.
I have a very simple ASP.NET MVC 4.0 website. It's got a single controller ("HomeController") with a single action ("Index") which receives a single parameter ("string id"). I have not modified the global.asax file since this kind of route is handled by default. I have not created a view for this action since the action will simply be "sending" the user a file (a PDF). If I run the site from within Visual Studio (using a default page of "home/index/3" in project properties), the page runs fine. If, however, I publish the site to our test server (https://ourserver.com/mysite/home/index/3), I get a 404--File or Directory not found.
NOTE: We're running IIS7.5 on this server.
UPDATE: The bin dir (and the appropriate DLL, i.e., one named after the project) and the web.config file are there.
So, why is this not working?
If you're using an older version of IIS and haven't installed the MVC server extensions which give you routing, you can do a BIN deployment of the necessary infrastructure files.
Edit: If you're running IIS 7.5 you should have everything you need. You mention you don't see a web.config file or any dlls - how did you publish? You should absolutely have a web.config at the root of the publish directory and a bin folder with your dll(s).
If you right-click on your web project and do Publish, you can publish to a local directory. It'll be exactly what you should see when deployed.
Edit 2: Did you check that it's configured in IIS as a web application and not just a site?
I am trying to get ASP.Net MVC 4 working on IIS6 and am running into the always fun Directory Listing Denied error.
Before you start posting about extensionless urls and how I need to read the Haacked blog post.. I have :) So with that out of the way here is the setup:
I have created a new Web Site and configured it to use ASP.Net 4.0. I had to do this because the existing Default Web Site is configured for ASP.Net 2.0 and this breaks extensionless urls. Under the new web site I created a Virtual Directory with Read/Write/Log Vists/Index this resource options selected and execute permissions set to Scripts.
I have verified that ASP.Net v4.0.30319 is in the Web Service Extensions list and is allowed. I have also verified that the .axd mapping is setup correctly in my virtual directories mapping configuration.
I am completely and totally stumped..
As a side bit of trivia I had this working with the web site pointing directly at my ASP.Net 4 web app but we need this to be done via a virtual directory instead. The fact I had this working should mean that the EnableExtensionlessUrl registry setting is not a problem.
I had faced the same problem and it got cleared when I added "Wildcard application mapping" (.*) to aspnet_isapi.dll with unchecked option "Verify that file exists"
Application -> Properties -> Directory -> Configuration -> Mappings ->
Insert -> Browse to
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll ->
Uncheck "Verify that file exists" -> Ok
Now the site is opening fine without any issues.
Similar issue: We installed MVC4 on an IIS6 box, set up everything as described, and got same error:
Directory Listing Denied
This Virtual Directory does not allow contents to be listed.
For us, the final fix was to add the UrlRoutingModule to the web.config:
<add name="UrlRoutingModule"
type="System.Web.Routing.UrlRoutingModule, System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
Which makes sense, but I don't know why we needed to explicitly add it and others didn't. (We are running in a directory under Sharepoint, maybe related...)
I just set up a simple WCF service on my dev environment, and so far the endpoints are working OK, for both SOAP and JSONP requests.
I've proceeded to deploy this solution to a staging server hosted on IIS 5.1 (old, I know, but bear with me), and the .svc files suddenly aren't working anymore. Not that IIS can't find them, but rather they're getting served as plain text files.
This is basically what shows up on my browser when I pop in an .svc file:
<%# ServiceHost Language="C#" Debug="true" Service="service.myservice" CodeBehind="myservice.svc.cs" %>
Now I've tried all the solutions I've seen around SO and other sites (including reinstalling the ASP.NET binds on IIS using aspnet_regiis and reinstating the WCF ISAPI handles using servicemodelreg.exe), but none of them work.
One quirk that may be of note is that the IIS 5.1 is serving off port 8000, because Apache is currently running on the default 80. Could this be a culprit? I've tried running servicemodelreg -s:myservice to try to hit my app path squarely, but it tells me that there's no such application on IIS:/localhost/myservice (maybe because it's supposed to be on IIS:/localhost:8000/myservice? I'm not sure.)
I've verified that I've got a functional .NET 3.5 framework down, the .aspx files are served OK. It's just the .svc files that aren't getting served properly.
Any ideas?
If servicemodelreg hasn't worked, check that the .svc is set up with an ISAPI mapping.
Go to the Home Directory tab on the properties of your web site, select Configuration...
If .svc isn't present in the list, set it up with the following parameters:
Executable: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
Extension: .svc
Limit to: GET,HEAD,POST,DEBUG
Script engine: Ticked