Dot Net Technology Que/Ans Set-4

31. Can a nested object be used in Serialization ?

Ans : Yes. If a class that is to be serialized contains references to objects of other classes, and if those classes have been marked as serializable, then their objects are serialized too.

32. Difference between int and int32 ?

Ans : Both are same. System.Int32 is a .NET class. Int is an alias name for System.Int32.

33. Describe the difference between a Thread and a Process?

Ans : A Process is an instance of an running application. And a thread is the Execution stream of the Process. A process can have multiple Thread.
When a process starts a specific memory area is allocated to it. When there is multiple thread in a process, each thread gets a memory for storing the variables in it and plus they can access to the global variables which is common for all the thread. Eg.A Microsoft Word is a Application. When you open a word file,an instance of the Word starts and a process is allocated to this instance which has one thread.

34. What is the difference between an EXE and a DLL? Ans : You can create an objects of Dll but not of the EXE.
Dll is an In-Process Component whereas EXE is an OUt-Process Component.Exe is for single use whereas you can use Dll for multiple use.
Exe can be started as standalone where dll cannot be.

35. What is strong-typing versus weak-typing? 

Ans:Which is preferred? Why? Ans : Strong typing implies that the types of variables involved in operations are associated to the variable, checked at compile-time, and require explicit conversion; weak typing implies that they are associated to the value, checked at run-time, and are implicitly converted as required. (Which is preferred is a disputable point, but I personally prefer strong typing because I like my errors to be found as soon as possible.)

36. What is a PID? How is it useful when troubleshooting a system? Ans: PID is the process Id of the application in Windows. Whenever a process starts running in the Windows environment, it is associated with an individual process Id or PID.

37. The PID (Process ID) a unique number for each item on the Process Tab, Image Name list. How do you get the PID to appear?

 Ans : In Task Manger, select the View menu, then select columns and check PID (Process Identifier).

In Linux, PID is used to debug a process explicitly. However we cannot do this in a windows environment.

Microsoft has launched a SDK called as Microsoft Operations Management (MOM). This uses the PID to find out which dll’s have been loaded by a process in the memory. This is essentially helpful in situations where the Process which has a memory leak is to be traced to a erring dll. Personally I have never used a PID, our Windows debugger does the things required to find out.

38. What is the GAC? What problem does it solve? Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies that are to be shared by several applications on the computer. This area is typically the folder under windows or winnt in the machine.

All the assemblies that need to be shared across applications need to be done through the Global assembly Cache only. However it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code.

There are several ways to deploy an assembly into the global assembly cache:
· Use an installer designed to work with the global assembly cache. This is the preferred option for installing assemblies into the global assembly cache.
· Use a developer tool called the Global Assembly Cache tool (Gacutil.exe), provided by the .NET Framework SDK.
· Use Windows Explorer to drag assemblies into the cache.

GAC solves the problem of DLL Hell and DLL versioning. Unlike earlier situations, GAC can hold two assemblies of the same name but different version. This ensures that the applications which access a particular assembly continue to access the same assembly even if another version of that assembly is installed on that machine.

39. Describe what an Interface is and how it’s different from a Class. An interface is a structure of code which is similar to a class. An interface is a prototype for a class and is useful from a logical design perspective. Interfaces provide a means to define the protocols for a class without worrying about the implementation details. The syntax for creating interfaces follows:
interface Identifier {
  InterfaceBody
}

Identifier is the name of the interface and InterfaceBody refers to the abstract methods and static final variables that make up the interface. Because it is assumed that all the methods in an interface are abstract, it isn't necessary to use the abstract keyword

An interface is a description of some of the members available from a class. In practice, the syntax typically looks similar to a class definition, except that there's no code defined for the methods — just their name, the arguments passed and the type of the value returned.
So what good is it? None by itself. But you create an interface so that classes will implement it.

But what does it mean to implement an interface. The interface acts as a contract or promise. If a class implements an interface, then it must have the properties and methods of the interface defined in the class. This is enforced by the compiler.

Broadly the differentiators between classes and interfaces is as follows
• Interface should not have any implementation.
• Interface can not create any instance.
• Interface should provide high level abstraction from the implementation.
• Interface can have multiple inheritances.
• Default access level of the interface is public.

40. What is the difference between XML Web Services using ASMX and .NET Remoting using SOAP?

ASP.NET Web services and .NET Remoting provide a full suite of design options for cross-process and cross-plaform communication in distributed applications. In general, ASP.NET Web services provide the highest levels of interoperability with full support for WSDL and SOAP over HTTP, while .NET Remoting is designed for common language runtime type-system fidelity and supports additional data format and communication channels. Hence if we looking cross-platform communication than web services is the choice coz for .NET remoting .Net framework is requried which may or may not present for the other platform. Serialization and Metadata
ASP.NET Web services rely on the System.Xml.Serialization.XmlSerializer class to marshal data to and from SOAP messages at runtime. For metadata, they generate WSDL and XSD definitions that describe what their messages contain. The reliance on pure WSDL and XSD makes ASP.NET Web services metadata portable; it expresses data structures in a way that other Web service toolkits on different platforms and with different programming models can understand. In some cases, this imposes constraints on the types you can expose from a Web service—XmlSerializer will only marshal things that can be expressed in XSD. Specifically, XmlSerializer will not marshal object graphs and it has limited support for container types.

.NET Remoting relies on the pluggable implementations of the IFormatter interface used by the System.Runtime.Serialization engine to marshal data to and from messages. There are two standard formatters, System.Runtime.Serialization.Formatters.Binary.BinaryFormatter and System.Runtime.Serialization.Formatters.Soap.SoapFormatter. The BinaryFormatter and SoapFormatter, as the names suggest, marshal types in binary and SOAP format respectively. For metadata, .NET Remoting relies on the common language runtime assemblies, which contain all the relevant information about the data types they implement, and expose it via reflection. The reliance on the assemblies for metadata makes it easy to preserve the full runtime type-system fidelity. As a result, when the .NET Remoting plumbing marshals data, it includes all of a class's public and private members; handles object graphs correctly; and supports all container types (e.g., System.Collections.Hashtable). However, the reliance on runtime metadata also limits the reach of a .NET Remoting system—a client has to understand .NET constructs in order to communicate with a .NET Remoting endpoint. In addition to pluggable formatters, the .NET Remoting layer supports pluggable channels, which abstract away the details of how messages are sent. There are two standard channels, one for raw TCP and one for HTTP. Messages can be sent over either channel independent of format.

Distributed Application Design: ASP.NET Web Services vs. .NET Remoting
ASP.NET Web services favor the XML Schema type system, and provide a simple programming model with broad cross-platform reach. .NET Remoting favors the runtime type system, and provides a more complex programming model with much more limited reach. This essential difference is the primary factor in determining which technology to use. However, there are a wide range of other design factors, including transport protocols, host processes, security, performance, state management, and support for transactions to consider as well.

Security
Since ASP.NET Web services rely on HTTP, they integrate with the standard Internet security infrastructure. ASP.NET leverages the security features available with IIS to provide strong support for standard HTTP authentication schemes including Basic, Digest, digital certificates, and even Microsoft® .NET Passport. (You can also use Windows Integrated authentication, but only for clients in a trusted domain.) One advantage of using the available HTTP authentication schemes is that no code change is required in a Web service; IIS performs authentication before the ASP.NET Web services are called. ASP.NET also provides support for .NET Passport-based authentication and other custom authentication schemes. ASP.NET supports access control based on target URLs, and by integrating with the .NET code access security (CAS) infrastructure. SSL can be used to ensure private communication over the wire.

Although these standard transport-level techniques to secure Web services are quite effective, they only go so far. In complex scenarios involving multiple Web services in different trust domains, you have to build custom ad hoc solutions. Microsoft and others are working on a set of security specifications that build on the extensibility of SOAP messages to offer message-level security capabilities. One of these is the XML Web Services Security Language (WS-Security), which defines a framework for message-level credential transfer, message integrity, and message confidentiality.

As noted in the previous section, the .NET Remoting plumbing does not secure cross-process invocations in the general case. A .NET Remoting endpoint hosted in IIS with ASP.NET can leverage all the same security features available to ASP.NET Web services, including support for secure communication over the wire using SSL. If you are using the TCP channel or the HTTP channel hosted in processes other than aspnet_wp.exe, you have to implement authentication, authorization and privacy mechanisms yourself.

One additional security concern is the ability to execute code from a semi-trusted environment without having to change the default security policy. ASP.NET Web Services client proxies work in these environments, but .NET Remoting proxies do not. In order to use a .NET Remoting proxy from a semi-trusted environment, you need a special serialization permission that is not given to code loaded from your intranet or the Internet by default. If you want to use a .NET Remoting client from within a semi-trusted environment, you have to alter the default security policy for code loaded from those zones. In situations where you are connecting to systems from clients running in a sandbox—like a downloaded Windows Forms application, for instance—ASP.NET Web Services are a simpler choice because security policy changes are not required.

Conceptually, what is the difference between early-binding and late-binding?
Early binding – Binding at Compile Time
Late Binding – Binding at Run Time

Early binding implies that the class of the called object is known at compile-time; late-binding implies that the class is not known until run-time, such as a call through an interface or via Reflection.

Early binding is the preferred method. It is the best performer because your application binds directly to the address of the function being called and there is no extra overhead in doing a run-time lookup. In terms of overall execution speed, it is at least twice as fast as late binding.

Early binding also provides type safety. When you have a reference set to the component's type library, Visual Basic provides IntelliSense support to help you code each function correctly. Visual Basic also warns you if the data type of a parameter or return value is incorrect, saving a lot of time when writing and debugging code.

Late binding is still useful in situations where the exact interface of an object is not known at design-time. If your application seeks to talk with multiple unknown servers or needs to invoke functions by name (using the Visual Basic 6.0 CallByName function for example) then you need to use late binding. Late binding is also useful to work around compatibility problems between multiple versions of a component that has improperly modified or adapted its interface between versions.