What should be the values for apppooluser and apppoolpassword?

A walkaround for the debugging issue it to start the application without Debugging, make the Identity changes and reattach to the ISS Worker process w3wp.exe

I used this solution and am facing problems with debugging my application. Any updates on the solution for this problem?

One thing to mention is that for the original code to work, you must have the "IIS Metabase and IIS 6 configuration compatibility" installed. If you do not have that installed, you'll run into fancy COMExceptions. The pure IIS7 solution would be like below. Besides that, you might also have to 'hammer' the config change if you run multiple web roles.

string appPoolUser = GetDevelopmentMachineSettingFromRegistry("DomainUserName");
string appPoolPass = GetDevelopmentMachineSettingFromRegistry("DomainPassword");

Action iis7fix = (appPoolName) =>
{
bool committed = false;
while (!committed)
{
try
{
using (ServerManager sm = new ServerManager())
{
var applicationPool = sm.ApplicationPools[appPoolName];
applicationPool.ProcessModel.IdentityType = ProcessModelIdentityType.SpecificUser;
applicationPool.ProcessModel.UserName = appPoolUser;
applicationPool.ProcessModel.Password = appPoolPass;
sm.CommitChanges();
committed = true;
}
}
catch (FileLoadException fle)
{
Trace.TraceError("Trying again because: " + fle.Message);
}
}
};

// ServerManager in %WinDir%System32InetSrvMicrosoft.Web.Administration.dll
var sitename = RoleEnvironment.CurrentRoleInstance.Id + "_Web";
var appPoolNames = new ServerManager().Sites[sitename].Applications.Select(app => app.ApplicationPoolName).ToList();
appPoolNames.ForEach(iis7fix);

Thanks for the additional details, Christian!

One thing to mention is that using ServerManager directly in multiple web role instances can trash IisConfigurator. See here for more details:

http://blogs.msdn.com/b/chg...

Christian

Wade's point about picking up Microsft.Web.Administration.dll from %windir%system32inetsrv is *very* important. On my Windows 7 box, the version of this DLL is 7.0.0.0. The IIS Express installer also places a copy of this DLL into GAC, marked version 7.9.0.0.

If you happen to add a reference from your project to the 7.9.0.0 copy of Microsft.Web.Administration.dll, you get strange errors about not finding applicationHost.config in a path rooted from c:users (e.g. the %USERPROFILE% path). By referencing the native IIS copy (7.0.0.0), the implementation attempts to open the correct applicationHost.config file (correct for Azure, that is) at %windir%system32inetsrvconfig.

Another idea - I found that I can use “bitsadmin” to set the proxy for networkservice to an instance of fiddler running as me. Fiddler can, by virtue of running as me, talk to the interent. Debugging works for me with this setup.

bitsadmin /util /SETIEPROXY NETWORKSERVICE MANUAL_PROXY 127.0.0.1:8888 NULL

This works for me.

When you start Fiddler, it sets the WinINET proxy for the logged on user to 127.0.0.1:8888. However, the Dev Fabric sets the IIS App Pool to run as NETWORK SERVICE and so this does not know of any proxy config and does not route HTTP requests through Fiddler. Therefore, I have been getting DNS resolution failure when using this Azure storage connection string: "UseDevelopmentStorage=true;DevelopmentStorageProxyUri=http://ipv4.fiddler".

By running "bitsadmin /util /SETIEPROXY NETWORKSERVICE MANUAL_PROXY 127.0.0.1:8888 NULL", NETWORK SERVICE now uses Fiddler as a proxy, resolves ipv4.fiddler to localhost, and traces all my HTTP traffic to and from the dev storage emulator.