One of the disadvantages of using Visual Studio.NET and the .NET framework to develop applications has been the lack of cross-platform support. Since the introduction of the .NET framework and common language run time a few years ago, there have been a few projects designed to bring the .NET framework to other platforms, including Linux and UNIX. The DotGNU project is touted as the "Free software alternative to .NET" and encompasses a number of projects, including DotGNU Portable .NET, which is designed to be used to compile and run C# and C applications on a multitude of platforms, including GNU/Linux, FreeBSD, Mac OS X, and Windows. One of the main features of the product is it's compatibility with EMCA standards for C# and the Common Language Infrastructure (CLI), as well as Microsoft's own CLI implementation in the .NET framework. The project chose to go with a "Virtual Machine" implementation, where bytecode is transformed into a simple instruction set which is then passed to a "Converted Virtual Machine", which then are executed through an interpreter. This approach is different to other open source .NET implementations, but provides more flexibility when porting the project to other platforms. At the core of the project is the runtime engine (ilrun) and compiler (cscc) with an implementation of System.Windows.Forms that makedeveloping for the platform easier, as it doesn't required translation through another toolkit or toolset. (More...)

A private assembly is used only by a single application, and is stored in that application's install directory (or a subdirectory therein). A shared assembly is one that can be referenced by more than one application. In order to share an assembly, the assembly must be explicitly built for this purpose by giving it a cryptographically strong name (referred to as a shared name). By contrast, a private assembly name need only be unique within the application that uses it. By making a distinction between private and shared assemblies, we introduce the notion of sharing as an explicit decision. Simply by deploying private assemblies to an application directory, you can guarantee that that application will run only with the bits it was built and deployed with. References to private assemblies will only be resolved locally to the private application directory.There are several reasons you may elect to build and use shared assemblies, such as the ability to express version policy. The fact that shared assemblies have a cryptographically strong name means that only the author of the assembly has the key to produce a new version of that assembly. Thus, if you make a policy statement that says you want to accept a new version of an assembly, you can have some confidence that version updates will be controlled and verified by the author. Otherwise, you don't have to accept them. For locally installed applications, a shared assembly is typically explicitly installed into the global assembly cache (a local cache of assemblies maintained by the .NET Framework). Key to the version management features of the .NET Framework is that downloaded code does not affect the execution of locally installed applications. Downloaded code is put in a special download cache and is not globally available on the machine even if some of the downloaded components are built as shared assemblies.The classes that ship with the .NET Framework are all built as shared assemblies. (More...)

The remoting infrastructure allows you to create two distinct types of remote objects.

1.Client-activated objects - A client-activated object is a server-side object whose creation and destruction is controlled by the client application. An instance of the remote object is created when the client calls the new operator on the server object. This instance lives as long as the client needs it, and lives across one to many method calls. The object will be subject to garbage collection once it''s determined that no other clients need it.

2.Server-activated objects - A server-activated object''s lifetime is managed by the remote server, not the client that instantiates the object. This differs from the client-activated object, where the client governs when the object will be marked for finalization. It is important to understand that the server-activated objects are not created when a client calls New or Activator.GetObject. They are rather created when the client actually invokes a method on the proxy. There are two types of server activated objects. They are:

I. Single call . Single-call objects handle one, and only one, request coming from a client. When the client calls a method on a single call object, the object constructs itself, performs whatever action the method calls for, and the object is then subject to garbage collection. No state is held between calls, and each call (no matter what client it came from) is called on a new object instance.

II.Singleton - The difference in a singleton and single call lies in lifetime management. While single-call objects are stateless in nature, singletons are stateful objects, meaning that they can be used to retain state across multiple method calls. A singleton object instance serves multiple clients, allowing those clients to share data among themselves. (More...)

. Single Threading: This is the simplest and most common threading model where a single thread corresponds to your entire application's process. Apartment Threading (STA): This allows multiple threads to exist in a single application. In single threading apartment (STA), each thread is isolated in it's own apartment. The process may contain multiple threads (apartments) however when an object is created in a thread (i.e. apartment) it stays within that apartment. If any communication needs to occur between different threads (i.e. different apartments) then we must marshal the first thread object to the second thread. Free Threading: The most complex threading model. Unlike STA, threads are not confined to their own apartments. Multiple treads can make calls to the same methods and same components at the same time. (More...)

There are 2 types of temporary tables, local and global in sql server.

Local temporary tables are created using a single pound (#) sign and are visible to a single connection and automatically dropped when that connection ends.

Global temporary tables are created using a double pound (##) sign and are visible across multiple connections and users and are automatically dropped when all SQL sessions stop referencing the global temporary table. (More...)

Find questions, FAQ's and their answers related to .NET, C#, Vb.Net, Sql Server and many more.

Now you can find lots of .NET, C#, Vb.Net, SQL Server,Windows, ASP.Net related Questions and their Answers here at www.dotnetspark.com. Our aim is to help you pass your certification Exams (MCP, MCSD, MCAD etc.,) with flying scores and get good name in your company.

So, Start looking our Interview Question section daily and improve your .NET Skills. You can also help others by posting Interview Questions and their Answers in this section.