I'm trying to install a default Umbraco installation on IIS7, and I'm getting the following error on my (unmodified) web.config file, any ideas?
Config Error
The configuration section 'system.web.extensions' cannot be read because it is missing a section declaration
Thanks,
I'm going to assume you are using the current version of Umbraco 4.5.2 as offered on the Codeplex site...
By default, Umbraco is configured to use .Net 2.0 (not .Net 4.0). Go to your IIS Management Console, select ApplicationPools and double-click your website. Make sure the .Net Framework is set to 2.0.
Also make sure the server you are running the IIS on has .Net 2.0 installed!
If you can provide more information from the server's error page, I can help better pinpoint the error...
Related
I am familiar with .Net in general but new to ASP.Net Core. I just had my first "self-hosted" ASP.Net Core MVC app running (created using templet and runs under Kestrel by default) . What I would like to do now it to host it in-process with IIS. But what I am struggling with is that I couldn't seem to find a clear and detailed instruction/document about what I need to do to get it to work. I have tried various configuration changes on my own but nothing works so far. I am running .Net Core 3.1 and using VS.Net 2019 on my Windows 10 environment. If someone could point me to the right direction it would be highly appreciated.
As far as I know, if you want to host the asp.net core application on the IIS. You should make sure you have installed the right hosting bundle.
Notice: No matter you use in-process or out-of-process, you all need install the IIS hosting bundle.
More details about how to install it, you could refer to this link.
After install the link, you could check your IIS module to make sure you have installed the right asp.net core module.
Then you could use VS to publish the application to right folder and create the IIS web site as below:
Create IIS website:
I am keep getting 500.19(0x8007000d) error when running my .NET core project through IIS Express.
After a bit digging, it looks like IIS doesn't recognize <aspNetCore> as a valid element in the web.config.
Here are the things I've tried:
installed URL rewrite module as someone suggested installed
AspNetCoreModule throgh here:
https://www.microsoft.com/net/download/dotnet-core/runtime-2.0.5.
installed .NET Core Windows Server Hosting bundle.
I've tried adding it as a managed module and put the path for AspNetCoreModule, but looks like it doesn't fix the issue. Enable stdoutLog doesn't work, because it simply won't generate any log file.
Any idea on how to solve this?
I got it working finally. Because all my website is under the default website, I went to install AspNetCoreModule module for the default website.
After it was installed, I noticed a change in the web.config under the default website. At the same time, AspNetCoreModule module is also listed as Native module in the module section.
The real error message is web.config was trying to install AspNetCoreModule, but it is already installed. Then I deleted the <modules> section in the web.config under the default website and it worked...
The website used to work before I turned off/on windows IIS features. Really not sure what caused this...
Repairing the core server hosting from the add remove program did the trick -
It seems like IIS was installed or changed after core windows server hosting. According to Microsoft is such case you need to repair the hosting bundle
Add Native module with path C:\Windows\system32\inetsrv\aspnetcore.dll
I have a small web app developed with Asp.Net Core 1.1 deployed on Azure and it works well. I just migrated the project to use Asp.Net Core 2.0 and tried to deploy it on Azure. The deployment went fine but when I open the site, I get a 502.5 error. When I check my Azure log stream, I get the following error:
This error occurs when a CGI application does not return a valid set
of HTTP headers, or when a proxy or gateway was unable to send the
request to a parent gateway. You may need to get a network trace or
contact the proxy server administrator, if it is not a CGI problem.
Useless to say that it works well on my development machine with the same code. Note that I'm also using Entity Framework Core 2.0 although I deactivated the database creation on Azure (to check if it was not the cause).
For information, the way I migrated from 1.1 to 2.0 is by changing the target framework settings to "netcoreapp2.0" and by using the NuGet package "Microsoft.AspNetCore.All". Just to be sure, I also deleted my publish profile and recreate one.
Is it possible that Asp.Net Core 2.0 is not yet available on Azure ? I'm fairly new to Asp.Net Core, so I don't know when new releases are made available on Azure.
EDIT
When I try to run my app with dot net CLI via the debug console as proposed by natemcmaster, I got the following issue:
Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'Microsoft.AspNetCore.Hosting.Abstractions,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
The located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
I downloaded the DLL on my desktop and check the version with Dot Net Peak and indeed, the DLL is 1.1.2, although I created the project with Visual Studio and directly publish it, so is it an issue with Visual Studio ? Or Nuget ?
the issue was actually coming from the fact that, at first, my web app was using .net core 1.1, which deploys all the DLL in the "wwwroot" folder of the web application. However, with asp.net core 2.0, it does not do that anymore as the DLL are picked up from a global store. However, as Visual Studio does not clean the destination folder before a publish, I ended up with a situation where the 1.1 DLL were in my wwwroot, so the web site was picking up these ones instead of the 2.0 ones in the store folder.
This is explained in more details here: https://github.com/Azure/app-service-announcements-discussions/issues/2#issuecomment-313816550
Others have explained the reason why this is happening. I'd like to provide another – arguably easier – solution to the problem.
Just change the settings so that you remove files that are already on Azure – see below:
Check for log files either in the portal or by remotely accessing D:\home\LogFiles.
Sometimes, the logs won't indicate what is going wrong. Another good way to investigate further is to try launching your ASP.NET Core app from the Debug Console. If you are missing a shared framework version or there is another startup error, this will be more visible from the Debug Console.
Go to
https://(your web site name here).scm.azurewebsites.net/DebugConsole/
Your site will be in D:\home\site\wwwroot. You can launch it by executing:
cd D:\home\site\wwwroot
dotnet MyWebApp.dll
If you app still fails to launch, make sure that D:\home\site\wwwroot\web.config is available and configured to use ASP.NET Core Module. https://learn.microsoft.com/en-us/aspnet/core/hosting/aspnet-core-module
In my case, It was caused by having a space in the Project Name.
I can readily add a space, publish => 502.5.
Remove space, publish => good to go.
Hard to believe but I am duplicating it readily with above.
Also using "Remove Additional Files at Destination" per #Sam's Answer
See https://github.com/Azure/app-service-announcements/issues/14
"The rollout is expected to complete by Friday June 30th."
In my case the issue occurred because AppService at that time supported 2.0.0-preview2-006497 but I had 2.0.0-preview3-006890 installed which was used on build.
So I added global.json to use preview 2 SDK and it worked then
I don't know if this could help someone one day but in my case, I was using :
-Microsoft.AspNetCore.All 2.0.5
Downdrage to Microsoft.AspNetCore.All 2.0.3 resolve my problem
This happens when your version of ASP.NET Core cannot be matched on the server.
The simplest solution is to change your settings to deploy the app as self-contained, so it doesn't matter if Azure can match the framework version. Also, delete the files already on Azure, so you don't have issues when upgrading, as explained by #Sam.
After migrating TeamCity from one server to another, and also switching to Visual Studio 2013, our build fails when using MSDeploy to push a TC-built .zip package to IIS.
The application pool that you are trying to use has the
'managedRuntimeVersion' property set to 'v4.0'. This application
requires 'v4.5'
This is a strange error since my IIS server has .NET 4.5 installed and has been happily running and being deployed to for weeks, and a 4.0 application pool will run a 4.5 targeted app.
Unfortunately, the waters are muddied by the changes to TC and VS (2013) so what caused the issue I cannot be sure of.
Note: Our TC server only has Visual Studio 2012 on it, since I'm on MSDN and got early access to 2013. This could be the culprit, but doesn't make the issue any less odd.
I'd prefer not to disabled .NET runtime version checking at all (with IgnoreDeployManagedRuntimeVersion), but instead implicit set runtime version via DeployManagedRuntimeVersion:
<DeployManagedRuntimeVersion>v4.0</DeployManagedRuntimeVersion>
Some more details: http://techblog.dorogin.com/2013/11/deploying-45-projects-with-webdeploy.html
Open your .csproj file and set the following element:
<IgnoreDeployManagedRuntimeVersion>True</IgnoreDeployManagedRuntimeVersion>
Adding it just above this element helps readability:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
Kudos to https://stackoverflow.com/users/1769923/abhishikt-n-jain for answering with this little-known config setting here:
MSBuild deploy failing after upgrade to .NET 4.5
If anyone knows why this happens, please feel free to add an answer.
Update
Disregard my comments below. While it got me past the deploy, I got a 503 Service Unavailable when I actually tried to run the web app. I backed out this change by setting the managedRuntimeVersion property back to v4.0 and added the IgnoreDeployManagedRuntimeVersion to my project. Then the deploy succeeded and the app worked. Dumb...
This happened to me after I installed .NET Framework 4.5.1 on a Windows Server 2008 R2 SP1 machine (as part of upgrading Powershell).
The IIS user interface on Windows Server 2008 doesn't give the option of setting the managedRuntimeVersion property to v4.5 even after that version is installed. However, this can be done on the command line using the appcmd utility as #3boysdad's answer shows.
appcmd is the command-line equivalent of managing IIS sites, apps, apppools, etc. It is located at %systemroot%\system32\inetsrv\appcmd.exe but it is not on the PATH as the following link explains:
http://www.iis.net/learn/get-started/getting-started-with-iis/getting-started-with-appcmdexe#HowToUse
I'm of the opinion that modifying your project (via the IgnoreDeployManagedRuntimeVersion or DeployManagedRuntimeVersion properties) is sub-optimal. The application pool should be set to use v4.5, and the only way to do that on Windows Server 2008 is to use the appcmd utility. #3boysdad's answer should be the accepted answer.
found this gem while hunting around for this same problem.
appcmd set apppool /apppool.name: <your app pool> /managedRuntimeVersion:v4.5
this will need to be executed in your \System32\inetsrv directory.
I have a project which I have upgraded to .Net 4.0, but when I try to access it, I retrieve the following error:
HTTP Error 404.2 - Not Found
The page you requested could not be displayed because of the settings for the list of ISAPI and CGI restrictions on web server.
ErrorCode: 0x800704ec
Handler PageHandlerFactory-ISAPI-4.0_32bit
Do I need to do something extra to the IIS 7 or APP pool, when converting an existing site to a .NET 4.0 site?
Also if I look at ISAPI both 32bit and 64bit of the .Net 4.0 is installed.
In IIS, enable .NET 4.
Here is image:
I take it you're running on IIS6 right now..
Open the IIS manager, and go to the Web Service Extensions area.. You'll be able to enable .NET 4 in there.. All new extensions are disabled by default :)
If you're running on IIS7, .NET might not have registered in IIS.. Then open up an admin command prompt and navigate to the .NET 4 framework folder (C:\Windows\Microsoft.NET\Framework\v4.{version}). If you're on a 64 bit machine go to the Framework64 folder instead of the Framework folder.
Then run aspnet_regiis -i in there
I had this same issue. Strangely, for me it would run in integrated mode but not in classic mode for .NET 4. After enabling the .NET 4 extensions via the Isapi and Cgi restrictions section in IIS 7, it then began working in both modes. The Isapi and Cgi restrictions section is located at the server level node in IIS manager. This option should not be confused with the Isapi Filters section at the site level.