January, 2012

...now browsing by month

 

Deploy .Net 4.0 Website to Local IIS7

Wednesday, January 18th, 2012

I had a website that was upgraded from .Net 2.0 to v.4.0; normally I used Web Deployment Project to pack it and deploy to remote IIS6 server using xcopy and had not encountered the need to deploy to local IIS which is IIS7 now. Today I did, and ran into a few errors before getting it to run, so I recorded the steps and fixes here to refresh myself and help others from being hassled by these again:

  1. Used Web Deployment Project to deploy the solution (Output Assemblies setting: Merge all outputs to a single assembly and Treat as library component checked)
  2. I did not check the “Create an IIS virtual directory for the output folder option as I wanted to create the website manually.
  3. Opened IIS7 and added a new website, called it “NewAdmin”; went to binding and changed port to 8081 as other default ports were already taken by other sites; left the application pool to use the default one created by the system.
  4. By default every new site created in IIS7 uses ASP.Net v2.0, obviously, changed that to .Net v.4.xxxx, and left the Integrated mode and ApplicationPoolIdentity unchanged.
  5. Now browsed to the site and got this error, “There is a duplicate ‘system.web.extensions/scripting/scriptResourceHandler’ section defined”, and some more, “There is a duplicate ‘system.web.extensions/scripting/webServices/jsonSerialization’ section defined”..
  6. Googled and read postings from here, and led me to doing the next step
  7. Removed these sections from the sectionGroup:<section name=”scriptResourceHandler” type=”System.Web.Configuration.ScriptingScriptResourceHandlerSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ requirePermission=”false” allowDefinition=”MachineToApplication”/><section name=”jsonSerialization” type=”System.Web.Configuration.ScriptingJsonSerializationSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ requirePermission=”false” allowDefinition=”Everywhere”/>
    <section name=”profileService” type=”System.Web.Configuration.ScriptingProfileServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ requirePermission=”false” allowDefinition=”MachineToApplication”/>
    <section name=”authenticationService” type=”System.Web.Configuration.ScriptingAuthenticationServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ requirePermission=”false” allowDefinition=”MachineToApplication”/>
    <section name=”roleService” type=”System.Web.Configuration.ScriptingRoleServiceSection, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ requirePermission=”false” allowDefinition=”MachineToApplication”/>

     

  8. Browsed to the site again, a different error was displayed “The page you are requesting cannot be served because of the ISAPI and CGI Restriction list settings on the Web server.” what’s going on?
  9. Well, actually this should have been done in step 3) – I need to lift the ISAPI and CGI Restrictions on the site just created. By default, IIS7 shutdowns everything; this is far different from IIS6 and earlier version, so be aware!
  10. Went back to local host node, clicked on Features View, then double clicked on ISAPI and CGI Restrictions – saw that By default ASP.Net v4.0.30319 was restricted. Changed that to “Allow”.
  11. That’s it.

NT AUTHORITY\NETWORK SERVICE does not have write access to ‘..\Temporary ASP.NET Files’.

Wednesday, January 4th, 2012

Got this error while trying to browse to a WCF service from IIS7: The current identity (NT AUTHORITY\NETWORK SERVICE) does not have write access to ‘D:\WINDOWS\Microsoft.NET\Framework\v4.0.3019\Temporary ASP.NET Files’. 

What happened? There must be some recent Windows updates to IIS7 that had messed up the previously security settings, but this was just my guessing. Important thing was how to fix this quickly. Found a post here granting access to IIS configuration and other directorys used by ASP.Net, and executed this line of command:

C:\Windows\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -ga “NT Authority\Ne
twork Service”

And that took care of it. “Network Service” is the identity used by the Application Pool used by the WCF service.