Dot Net Interview Questions - Dot Net Faq
Microsoft dot net is a software that helps us to develop the application for different environments and for different devices. We can build XML web services and web application for the environment like the Internet. We can also window-based application server components and applications, integrated) on PC and mobile devices such as dot net different applications and devices using standards such as HTTP (Hyper Text Transfer ProtocolXML and SOAP(Simple Access Protocol)
The feature that must be supplied. NET is so popular, written exchange of data between two applications in different languages and different environments. XML Web Services enable the exchange of data. Another possibility here is in. NET Remoting, which help us, the exchange of data between two calculated using binary or HTTP protocols. This turns on all Web protocols.
The one of main component in .net framework is CLR. It provides run time environment and various services to our applications. There are various components in CLR too. This component provides runtime environment and infrastructure to our applications.
Some brief works of CLR components are:
? Class Loader: It loads classes at runtime;
? MSIL: It converts msil code to native code.
? Password Manager: Manages code during execution.
? Garbage Collector: Automatic memory management.
? Security engine: performance and security restrictions.
? Type Checker: Helps in strict type checking.
? Thread support: support multi-threaded applications.
? Exception Manager: Handle runtime exceptions;
? Debug Engine: debug environment different types of applications.
? Com stories: exchange data with COM application;
? Base Library support: for the application type.
How the Runtime Locates Assemblies
To successfully deploy your .NET Framework application, you must understand how the common language runtime locates and binds to the assemblies that make up your application. By default, the runtime attempts to bind with the exact version of an assembly that the application was built with. This default behavior can be overridden by configuration file settings.
The common language runtime performs a number of steps when attempting to locate an assembly and resolve an assembly reference. Each step is explained in the following sections. The term probing is often used when describing how the runtime locates assemblies; it refers to the set of heuristics used to locate the assembly based on its name and culture.
Note You can view binding information in the log file using the Assembly Binding Log Viewer (Fuslogvw.exe), which is included in the .NET Framework SDK.
Initiating the Bind
The process of locating and binding to an assembly begins when the runtime attempts to resolve a reference to another assembly. This reference can be either static or dynamic. The compiler records static references in the assembly manifest's metadata at build time. Dynamic references are constructed on the fly as a result of calling various methods, such as System.Reflection.Assembly.Load.
The preferred way to reference an assembly is to use a full reference, including the assembly name, version, culture, and public key token (if one exists). The runtime uses this information to locate the assembly, following the steps described later in this section. The runtime uses the same resolution process regardless of whether the reference is for a static or dynamic assembly.
You can also make a dynamic reference to an assembly by providing the calling method with only partial information about the assembly, such as specifying only the assembly name. In this case, only the application directory is searched for the assembly, and no other checking occurs. You make a partial reference using any of the various methods for loading assemblies such as System.Reflection.Assembly.Load or AppDomain.Load. If you want the runtime to check the global assembly cache as well as the application directory for a referenced assembly, you can specify a partial reference using the System.Reflection.Assembly.LoadWithPartialName method. For more information about partial binding, see Partial Assembly References.
Finally, you can make a dynamic reference using a method such as System.Reflection.Assembly.Load and provide only partial information; you then qualify the reference using the <qualifyAssembly> element in the application configuration file. This element allows you to provide the full reference information (name, version, culture and, if applicable, the public key token) in your application configuration file instead of in your code. You would use this technique if you wanted to fully qualify a reference to an assembly outside the application directory, or if you wanted to reference an assembly in the global assembly cache but you wanted the convenience of specifying the full reference in the configuration file instead of in your code.
Note This type of partial reference should not be used with assemblies that are shared among several applications. Because configuration settings are applied per application and not per assembly, a shared assembly using this type of partial reference would require each application using the shared assembly to have the qualifying information in its configuration file.
The runtime uses the following steps to resolve an assembly reference:
- Determines the correct assembly version by examining applicable configuration files, including the application configuration file, publisher policy file, and machine configuration file. If the configuration file is located on a remote machine, the runtime must locate and download the application configuration file first.
- Checks whether the assembly name has been bound to before and, if so, uses the previously loaded assembly.
- Checks the global assembly cache. If the assembly is found there, the runtime uses this assembly.
- Probes for the assembly using the following steps:
- If configuration and publisher policy do not affect the original reference and if the bind request was created using the Assembly.LoadFrom method, the runtime checks for location hints.
- If a codebase is found in the configuration files, the runtime checks only this location. If this probe fails, the runtime determines that the binding request failed and no other probing occurs.
- Probes for the assembly using the heuristics described in the probing section. If the assembly is not found after probing, the runtime requests the Windows Installer to provide the assembly. This acts as an install-on-demand feature.
Note There is no version checking for assemblies without strong names, nor does the runtime check in the global assembly cache for assemblies without strong names.
Steps:
Step 1: Examining the Configuration Files
Step 2: Checking for Previously Referenced Assemblies
Step 3: Checking the Global Assembly Cache
Step 4: Locating the Assembly through Codebases or Probing
Posted in: C# and .NET| Tags: NET Application CLR Runtime Assembly language framework deploy assemblies locates defaultNew enhance: .NET 4.0 Security
The first beta of the v4.0 .NET Framework is now available, and with it comes a lot of changes to the CLR's security system. We've updated both the policy and enforcement portions of the runtime in a lot of ways that I'm pretty excited to finally see available. Since there are a lot of security changes, I'll spend the next month or so taking a deeper look at each of them. At a high level, the major areas that are seeing updates with the v4 CLR are:
- Security policy
- Security transparency
- APTCA
- Evidence
- AppDomain Managers
Like I did when we shipped the v2.0 CLR, I'll come back and update this post with links to the details about each of the features we added as I write more detailed blog posts about each of them.
One of the first changes that you might see to security in the v4 CLR is that we’ve overhauled the security policy system. In previous releases of the .NET Framework, CAS policy applied to all assemblies loaded into an application (except for in simple sandbox domains).
That lead to a lot of interesting problems. For instance, one of the more common issues people ran into was that they would develop an application on their local machine that they wanted to share with other people on the network. Once the application was working on their machine, they would share it out, but nobody could run it over the network because CAS policy provided a lower grant set to assemblies loaded from the intranet than it does to assemblies loaded from the local machine. The usual result was unexpected and unhandled SecurityExceptions when trying to use the application.
Generally, the only solution to this problem was to either manually update the CAS policy on each machine that wanted to run the application, deploy the application some other way (for instance via ClickOnce), or use native code.
One of the worst things about this problem was that the additional pain of not being able to just share a managed app over the network wasn’t actually buying any security. If an application wanted to attack your machine, it could bypass the sandbox that the CLR was setting up simply by being written in native code.
Effectively, running an executable is a trust decision – you’re saying that you trust the application that you’re running enough to execute with the privileges your Windows account has.
That leads to an interesting observation – the CLR isn’t the correct place to be setting permission restrictions for applications that are being launched directly (either from the command prompt, or from Windows explorer for instance). Instead, that should be done through Windows itself using mechanisms like SRP, which apply equally to both managed and native applications.
In the v3.5 SP1 release, these observations (writing managed code to use on the network was harder than it needed to be, and it wasn’t even buying any extra security) led us to relax CAS policy for LocalIntranet applications slightly. We enabled applications that were run directly from an intranet share (and any assemblies loaded from immediately next to that application) to be fully trusted by pretending that it had MyComputer zone evidence instead of LocalIntranet.
In the v4.0 release of the runtime, the CLR has taken that a step further. By default, unhosted applications are not subject to managed security policy when run under v4.0. Effectively, this means any managed application that you launch from the command prompt or by double clicking the .exe in Windows Explorer will run fully trusted, as will all of the assemblies that it loads (including assemblies that it loads from a location other than the the directory where the executable lives).
For applications run from the local machine, there really should be no observable change. However, for applications that are shared out over a network, this means that everything should just work – just as if you had run the application from your computer while you were developing it.
Posted in: C# and .NET| Tags: NET Security .NET 4.0 CLR New Enhance AppDomain system framework beta lotWhat is new in Common Language Runtime (CLR) 4.0
The following sections describe new features in security, parallel computing, performance and diagnostics, dynamic language runtime, and other CLR-related technologies.
Security
The .NET Framework 4 Beta 1 provides simplifications, improvements, and expanded capabilities in the security model. For more information, see Security Changes in the .NET Framework 4.
Parallel Computing
The .NET Framework 4 Beta 1 introduces a new programming model for writing multithreaded and asynchronous code that greatly simplifies the work of application and library developers. The new model enables developers to write efficient, fine-grained, and scalable parallel code in a natural idiom without having to work directly with threads or the thread pool. The new Parallel and Task classes, and other related types, support this new model. Parallel LINQ (PLINQ), which is a parallel implementation of LINQ to Objects, enables similar functionality through declarative syntax. For more information, see Parallel Programming in the .NET Framework.
Performance and Diagnostics
In addition to the following features, the .NET Framework 4 Beta 1 provides improvements in startup time, working set sizes, and faster performance for multithreaded applications.
ETW Events
You can now access the Event Tracing for Windows (ETW) events for diagnostic purposes to improve performance. For more information, see the following topics:
*
CLR ETW Events
*
Using Event Tracing for Windows to Log CLR Events
Performance Monitor (Perfmon.exe) now enables you to disambiguate multiple applications that use the same name and multiple versions of the common language runtime loaded by a single process. This requires a simple registry modification. For more information, see Performance Counters and In-Process Side-By-Side Applications.
Code Contracts
Code contracts let you specify contractual information that is not represented by a method's or type's signature alone. The new System.Diagnostics.Contracts namespace contains classes that provide a language-neutral way to express coding assumptions in the form of pre-conditions, post-conditions, and object invariants. The contracts improve testing with run-time checking, enable static contract verification, and documentation generation.
The applicable scenarios include the following:
*
Perform static bug finding, which enables some bugs to be found without executing the code.
*
Create guidance for automated testing tools to enhance test coverage.
*
Create a standard notation for code behavior, which provides more information for documentation.
Lazy Initialiation
With lazy initialization, the memory for an object is not allocated until it is needed. Lazy initialization can improve performance by spreading object allocations evenly across the lifetime of a program. You can enable lazy initialization for any custom type by wrapping the type inside a System..::.Lazy<(Of <(T>)>) class.
Dynamic Language Runtime
The dynamic language runtime (DLR) is a new runtime environment that adds a set of services for dynamic languages to the CLR. The DLR makes it easier to develop dynamic languages to run on the .NET Framework and to add dynamic features to statically typed languages. To support the DLR, the new System.Dynamic namespace is added to the .NET Framework. In addition, several new classes that support the .NET Framework infrastructure are added to the System.Runtime.CompilerServices namespace. For more information, see Dynamic Language Runtime Overview.
In-Process Side-by-Side Execution
In-process side-by-side hosting enables an application to load and activate multiple versions of the common language runtime (CLR) in the same process. For example, you can run applications that are based on the .NET Framework 2.0 SP1 and applications that are based on .NET Framework 4 Beta 1 in the same process. Older components continue to use the same CLR version, and new components use the new CLR version. For more information, see Hosting Changes in the .NET Framework 4.
Interoperability
New interoperability features and improvements include the following:
*
You no longer have to use primary interop assemblies (PIAs). Compilers embed the parts of the interop assemblies that the add-ins actually use, and type safety is ensured by the common language runtime.
*
You can use the System.Runtime.InteropServices..::.ICustomQueryInterface interface to create a customized, managed code implementation of the IUnknown::QueryInterface method. Applications can use the customized implementation to return a specific interface (except IUnknown) for a particular interface ID.
Profiling
In the .NET Framework 4 Beta 1, you can attach profilers to a running process at any point, perform the requested profiling tasks, and then detach. For more information, see the [IClrProfiling::AttachProfiler]IClrProfiling Interface::AttachProfiler Method method.
Garbage Collection
The .NET Framework 4 Beta 1 provides background garbage collection; for more information, see the entry So, what’s new in the CLR 4.0 GC? in the CLR Garbage Collector blog.
Covariance and Contravariance
Several generic interfaces and delegates now support covariance and contravariance. For more information, see Covariance and Contravariance in the Common Language Runtime.
Posted in: C# and .NET| Tags: NET Security Programming .NET 4.0 CLR New Common Language Runtime Runtime Information language framework performance computing model