The server is Windows 2008 R2 SP2 with IIS 7.5. I am running a PreReq utility to confirm it is setup prior to installing Infor Approva 10.0.
The utility keeps returning the above error. After some research it seems that error is usually thrown because IIS Express is installed and the wrong reference is being used which is fixed by either uninstalled IIS Express or changing the binding in aspnet.config. However I've confirmed that IIS express is not installed, so I was wondering why this error is being thrown? There aren't any existing references in the aspnet.config or the machine.config files.
Microsoft.Web.Administration.dll is located in folder %windir%\System32\inetsrv. You can find it on your machine and check its version.
I think this issue is caused by a wrong assumption of Approva's PreReq, and you should contact their technical support for assistance.
It is very likely that the vendor misunderstood IIS and IIS Express, and had a wrong reference to MWA set in their product.
Related
I'm configuring Windows 10 machine for web development. Installed Visual Studio and want to configure websites. Installed IIS manager but for some reason it doesn't have... anything. No websites, no application pools, no features at all. And it doesn't let me to add any of that.
Has anyone faced this kind of behavior?
Found it. It turned out that something messed up IIS config files (in Windows\System32\inetsrv\Config). So all IIS features were referencing invalid DLLs in the GAC and therefore were silently failing. I only found a trace of that in the Windows Event Log.
Took clean administration.config file and IIS started correctly.
We had a classic ASP application that had to be migrated to a new Windows Server (Windows Server 2012 R2 Datacenter). IIS was already setup and we migrated the files configured the URL and DNS, as well as setting up the classic ASP components for IIS. The web application initially opens okay but the error below pops up on the server continually.
We checked the relevant site was configured to run 32bit and we ensured that in the sites "Debugging properties" the "Enable Server-side Debugging" was set to false. Also, all those testing the site we ensured in Internet Options >> Advanced the two values of "Disable script debugging" were checked. But this did not resolve the error. I believe we have all the necessary components setup in the server roles
I then followed this URL and deleted certain registry entries and restarted the server.
https://learn.microsoft.com/en-gb/visualstudio/debugger/just-in-time-debugging-in-visual-studio?view=vs-2015
This seemed to take away the above error but then the relevant application pool continually stops. I checked the application logs and at each time the application pool stops there is an error stating below
Since creating this ticket I installed DebugDiag 2 and set up a rule for IIS "Crashing". Ran the application until the relevant IIS Application Pool stopped and examined the Dump files created by the rule. All of them appear to have one error concerning "VCRUNTIME140.dll". See image below.
I found that this was a common issue and related to Visual C++ Redistributable 2015. I looked at installed programs and there was versions 2010, 2013 and 2017 installed. Microsoft state that after version 2013 subsequent versions incorporate the last. So I installed the latest version of Visual C++ Redistributable and restarted the server. This made no difference. So I uninstalled the latest version and installed version 2015 and restarted but again the application pool still stops after several actions on the web application.
Does anyone know how do I resolve this please?
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
My office just gave me a new machine with Windows 10 and both VS2013 and VS2015 installed. I transferred an existing VS2013 project to the machine, but when I attempt to run, I get a ERR_SSL_PROTOCOL_ERROR error in Chrome. There doesn't appear to be a Repair IIS Express application in Win10. I considered uninstalling IIS Express 10 and install 8, but I'd need to get permission for that and it wouldn't be an easy sell. What else can I look at?
I couldn't find a solution anywhere online that would help me out until I removed the bindings that I was trying to access via the IIS site bindings in IIS manager - see below :
This was the only binding I kept - I removed the other bindings which were pointed at the ports that I needed.
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.