Is VB.net secured? Could anyone expound as how could it facilitate to having a heavy security for its' users.

In the .NET world, Mscorcfg.msc and Caspol.exe can be used to modify all aspects of security configuration.

.NET defines machine-wide and application-specific configuration files, and allows for enterprise, machine, and user security policy configuration, whose intersection provides the effective policy for the executing user. These file have fixed names and locations, most of them residing under the Common Library Runtime (CLR) tree, at: %CLR install path%\Config

For .NET v1.1, the location is: C:\WINNT\Microsoft.NET\Framework\v1.1.4322\CONFIG.

Multiple versions of CLR may co-exist on the same computer, but each particular version can have only a single installation. Since security policy files cannot be specified as runtime parameters of .NET applications, this centralized approach hurts co-existence when applications require conflicting policy settings.

Three security configuration files (enterprise, machine, and user) contain information about configured zones, trusted assemblies, permission classes, and so on. The general machine configuration file, on the other hand, contains machine-wide settings for algorithms, credentials, timeouts, and so on. Additionally, certain parameters (for instance, ASP.NET authentication/authorization parameters) can be configured or overriden in the application configuration file. The files' names and locations are listed below:

• User security configuration file: %userprofile%\Application data\Microsoft\CLR security config\vxx.xx\Security.config
• Machine security configuration file: %CLR install path%\Config\Security.config
• Enterprise security configuration file: %CLR install path%\Config\Enterprisesec.config
• Machine configuration file: %CLR install path%\Config\machine.config
• Application configuration files: <AppName>.exe.config (or Web.config for ASP.NET) in the application or web project's main directory

In .NET, CLR always executes natively compiled code; it never interprets it. Before IL is compiled to native code, it is subjected to validation and verification steps. The first step checks the overall file structure and code integrity. The second performs a series of extensive checks for memory safety, involving stack tracing, data-flow analysis, type checks, and so on. No verification is performed at runtime, but the Virtual Execution System (VES) is responsible for runtime checks that type signatures for methods are correct, and valid operations are performed on types, including array bounds checking. These runtime checks are accomplished by inserting additional code in the executing application, which is responsible for handling error conditions and raising appropriate exceptions. By default, verification is always turned on, unless SkipVerification permission is granted to the code.

thanks

__________________
Karpagarajan. R
Necessity is the mother of invention