Can I have both Forms and Windows Authentication in Same Web Application?

Sometimes we would like to have a mixed authentication for our ASP.NET application.

We want the same application to be accessible by both Forms Authentication (a cookie based authentication) and also use Windows Authentication using the Active Directory Domain User.

Unfortunately this is not possible in IIS on the Same Web Application

The reason being
Form Authentication uses a different HTTP Protocal namely HTTP 302  Login / Redirect while the Windows Authentication uses HTTP 401 Challenge.

The good news is you could have both Windows Authentication (Integrated) and Basic Authentication in the same web application.

This way you could expose the Basic Authentication for the Internet Users (Make sure that you have a SSL certificate) as this is sent as plain text and the Windows Authentication (Integrated) for Intranet Users.

If we still want Forms and Windows Authentication. We would need to create Two Web Applications one with the Forms and the Other with the Windows Authentication. Both would be exact copies of the application but the web.config alone would be different due to the security settings.

Loading Local Symbols (PDB) for .NET application using WinDbg

In order to use WinDbg we need to give it a symbol server for understanding what are the call stacks that is being used in the Windows OS world. If we are using a .NET application, this too is part of the Windows OS world. This we shall call as Microsoft Symbols. We also need to be able to load our assemblies and our call stacks this we call as Local Symbols.

We specify the loading of Symbols in the WinDbg as part of the initial setup.

To do this we first have to open WinDbg and File -> Symbol File Path

We then enter the following make sure that we have created the folder correctly.

srv*C:\Software\MicrosoftSymbols*http://msdl.microsoft.com/download/symbols;C:\Software\LocalSymbols

The first part is for loading the Microsoft Symbols we say if you don't find a Symbol you go to this location specified in the URL and download it.

The second part of this is load the local symbols. Since we didn't specify a URL, we need to place our PDB (Program Database) that comes with compiling the application both in Debug and Release Mode into this folder location. One should always expose the PDB in release mode to external use.

Please make sure that the same PDB is used at the time of compilation for a Software version. You could generate a PDB for the same version again  but not after the version has changed. So make sure that you copy the PDB files after you compile once you are ready to deploy your application so that this could be published for debugging purposes.

You could then save the workspace in WinDbg so that you dont need to re-type this information.

To verify that the local symbols are loaded you could do the following

Take a single assembly that is specific to your application and issue the following command

!chksym YourAssembly.dll

After a lot of verbose output you should get something like this

Loaded pdb is c:\share\YourAssembly.pdb


YourAssembly.pdb

pdb sig: 97489EA7-34EB-4861-A271-CB99337D21D9

age: 1
MATCH: YourAssembly.pdb and C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\AppFolder\7ecdb58d\fdf53a2\assembly\dl3\fde54ebd\000993fb_79b5cd01\YourAssembly.dll

WinDbg loading Son of Strike (sos.dll) for .NET 4.0 and above

For loading the Son of Strike (sos.dll) for .NET 4.0 and above we need to do the following

.loadby sos clr

Developer Tip When Getting Absolute Path for .NET Applications

When obtaining the executing path for a .NET application which could be used from Web, Windows and Console Application, developer should be careful that Web applications work differently than a Windows or Console Application.

The code

System.AppDomain.CurrentDomain.BaseDirectory

Should be used carefully since in a web application there is no concept of debug / release within the bin directory, that is present in a Windows/Console application based on the build configuration. Either "debug" or "release" directory gets added automatically when you are in Visual Studio.  This is again different when we host the application where we can have only bin directory once we deploy the Windows / Console Application. Care should be taken to account for this when we write common code.

Visual Studio and .NET versions

Visual Studio originally started off as a C++ and Visual  Basic editor. Once .NET was introduced, it based itself to the .NET version and always gave an upgrade as and when new visual studio's were released. It can still be used for editing C++ content, though the use of Visual Basic with COM is no long used that often.

Here is a list of Visual Studio and their versions
Visual Studio .NET 2002 for .NET 1.0
Visual Studio .NET 2003 for .NET 1.1
Visual Studio 2005 for .NET 1.2 later renamed to .NET 2.0
Visual Studio 2008 for .NET 3.0, 3.5
Visual Studio 2010 for .NET 4.0
Visual Studio 2012 for .NET 4.5