It turns out that it was a stupid mistake on my part. The above is enough for ASP.NET v4 applications to work when the parts that I did not include (user actions and property definitions) are correct.
In my case, I accidentally quoted the path to aspnet_isapi.dll , so in fact it was not correctly raised.
The IIS extension does not consider the version of the managed version of execution on IIS-6, so the application does not have a set of ASP.NET versions.
This is partly true. Despite the fact that when setting up the application pool it does not use a managed version of execution, IIS actually selects the version of ASP.NET as soon as something is correctly mapped to aspnet_isapi.dll . As soon as I corrected the path, everything worked correctly.
If I use aspnet_regiis.exe -s APP_PATH to register it after it is created, it overwrites the wildcard mapping (and I donโt know the command line that I can run to restore it).
You can use adsutil.vbs to manage this if necessary:
C:\Inetpub\AdminScripts>adsutil.vbs enum w3svc/998577302/root/AppName KeyType : (STRING) "IIsWebVirtualDir" ... ScriptMaps : (LIST) (1 Items) "*,C:\WINDOWS\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll,1,GET,HEAD ,POST"
Using the set command in adsutil.vbs , you can set the ScriptMaps property as needed.
source share