Why .NET generate two web.config files in MVC.3 asp.net application?

View has its own config. If you are dealing with areas Then you will come to know about more than one config.

Actually The point is that view's Web.Config is for view specifc configutation such as blocking direct access to the views

The web.config file exists in the Views folders to prevent access to your views by any means other than your controller. In the MVC design pattern, controllers are supposed to route requests and return a rendered view to the calling client.

means localhost9999://Home/Index.cshtml should not be directly accessible.

ASP.NET configuration is stored in web.config files (XML files).

These files can appear in many directories in an ASP.NET application. They help to configure application behaviour even before after deploying, based on the fact that you can edit them with notepad. Also they keep separated your code and your configuration data.

Every web.config file applies to to the directory that it exists and ALL the child subdirectories. Web.config files in child directory may be used to override the parent's web.config file.

You have the option of overriding individual files or directories by using the location element. See LINK

The settings inheritance rules are as foillows.

First there is the machine.config file which is located usually in systemroot\Microsoft.NET\Framework\versionNumber\CONFIG\

In the same directory exists a 'master' web.config file that defines settings for ALL asp.net application that are running in the machine.

Then come your web.config files that exist in your application.

More Info:

ASP.NET configuration overview

ASP.NET Configuration file hierarchy and inheritance

I'd like to add to this that the Web.Config in the /Views folder is a great (if not thé) way to declare namespaces specifically for your views in. In a web application it is very possible almost every view gets a ViewModel (instead of your actual model) passed to it. Declaring the full namespace after @model or having the same @using App.Web.Viewmodels gets tedious. This way, all viewmodels are automatically available and you have to do extra work to get the real models in scope, which should then set of some alarm bells immediatly.

Also, usually an application can get a lot of extension-methods specifically for use in the view (the HTML-helper jumps into mind). It makes sense to define the namespace to this extension class in the /Views/Web.Config. That way you never wonder "Why cant IntelliSense find the @Html.ImageLink() method??!"