Advanced lightSwitch debugging (part 2 of N): Debug in local IIS with ability to log in with any application user apart from ‘TestUser’.


This time we are not dealing with applications already deployed to production or even not deployed to your development workstation, but we are talking about the normal daily LightSwitch local debug scenario in visual studio but… with something extra.

You want to login in debug time with different credentials

Great, but why would I want this?

Some application are designed as a multi-tenant application or have complex row level security. That scenario is difficult to test without deploying the application (at least it was difficult).

When you want to do test on this type of applications in debug and you have only one account “TestUser”, you are stuck.

This scenario is possible when we debug the application in a local full IIS rather than the normal IIS Express. It is still even possible to hit breakpoints in this scenario.The only thing you need to do explicitly is attach from visual studio to the IIS worker process.

This article presumes you are familiar with IIS (internet information services).

How to host an application under debug in full local IIS ?

Of course we presume you have an application, which you compile already once. Open this one in visual studio which you start with administrator privileges. I presume also that you activated forms authentication.

Go now to your local IIS (make sure it’s well configured and that you tried to deploy already once a LightSwitch application in it) and right click on the default website (or any other) and select “Add Application”:



Give as physical path the   {my LightSwitch project}bindebug folder:



Go now to explorer and right click on this debug folder  and give the user “EveryOne” full access to this folder:



Create now a new application pool, call it “DebugAppPool” and give it as identity your current user account:


Set the identity:



Open now the AppHost.config file from here: C:WindowsSystem32inetsrvconfig

And do a search on “DebugAppPool” (or something else if you took another name for the app pool) where you need to add to attributes to the Process Model:

<add name=”DebugAppPool” autoStart=”true” managedRuntimeVersion=”v4.0″>
                 <processModel identityType=”SpecificUser” userName=”paulv_000″ password=”[enc:IISWASOnlyAesProvider:3nQfdwwo3bwqvdefEw8ViBgwqy4jtk9y66HyvEseskpCE=:enc]” loadUserProfile=”true” setProfileEnvironment=”true” />

So, loadUserProfile and setProfileEnvironment needs to be added.


Give now this application pool to the newly added app:



Admitted, the step of patching the HostConfig file and creating the app pool is cumbersome, but luckily you need to do this only once. If you tomorrow you have an other application to debug in IIS, simply re-use the same application pool.


Test the application running in the IIS

I called the application virtual directly “MyTestApp”, so I can browse to : http://localhost/MyTestApp/DesktopClient/Default.htm

Houston we have a problem:


Holy cow, where can I get the username password?

Luckily, you can still login via visual studio in the same app. F5 visual studio after you activated the Security Admin permission in debug. Add a user and give her a password.

Try again to app in  the IIS path and you can log in.

Attaching a debugger to the application running in IIS


Start you app via the browser in http://localhost/MyTestApp/DesktopClient/Default.htm

Open now visual studio with the project and attach the debugger to IIS:


Atttach to the w3wp process:



Put somewhere a breakpoint and you will see:



Using the local IIS in debug mode has probably more usage than I’m currently thinking. But at least, due to the ability to log on with different credentials, you can easily debug now complex row level security rules.