|
Instead of programmatically registering the object and channel, both the client and the host can use configuration files. The app demonstrates the format and syntax of the configuration files. The app uses Visual Basic .NET.
|
|
|
|
Instead of programmatically registering the object and channel, both the client and the host can use configuration files. The app demonstrates the format and syntax of the configuration files. The app uses Visual C#.
|
|
|
|
Demonstrates creating new app domains, and injecting objects in it.
|
|
|
|
Firing .NET Events is by default synchronous. But you could fire them asynchronously with a few simple lines of code. The zip file contains the required code, and a test client.
|
|
|
|
.NET provides built-in support for invoking methods asynchronously. There are several available programming models, with a few permutations of polling and callback mechanism. The zip file contains a demo client that uses every possible way of invoking methods asynchronously: call and forget, poll, callback and waiting on an event object, as well as providing special call identifiers and state objects.
|
|
|
|
One of the most beneficial steps you can take to achieve a robust application and faster time to market is adding a logging capability to your application. The logbook is a simple custom component service that allows you to automatically log method calls and exceptions. By examining the logbook entries, you can analyze what took place across machines. The logbook uses custom context attribute.
|
|
|
|  |
|
The easiest way to synchronize access to your object by multiple threads is to put it in a protected run-time environment, called context. Calls into a context are intercepted, and services are added as pre and post call processing. One of such a service is multithreading synchronization, using a special context attribute. The Synchronization attribute defines a synchronization domain -- a collection of objects that can only be accessed by one thread at a time, all with zero effort on the part of the developer. The zip file contains a demo client that creates threads that access a synchronized object.
|
|
|
|
.NET automatic serialization assumes every level at a class hierarchy is serializable, and .NET throws an exception if not. This behavior makes it difficult to subclass a serializable class from a non-serializable base class. The utility provides automatic serialization of the base class (or classes) via custom serialization, using reflection.
|
|
|
|
A sample custom context attribute that lets you extend a .NET context. This sample adds a color attribute to a .NET context. The zip files contains a comprehensive demo client with graphic illustrations of the actual activation context.
|
|
|
|
This is a full-blown back up utility, that uses .NET system IO to copy and backup files. You can select normal or incremental backup. It also serves as a demo application for file properties manipulation in .NET.
|
|
|
|
.NET provides two types of threads: background and foreground threads. The two are identical except a background thread will not keep the runtime alive once the last foreground thread has exit. The app demonstrates the difference between the two types.
|
|
|
|
System Programming .NET provides support for automatic object serialization, both for object persistence and for remoting and marshaling. Objects can be sterilized to either binary or SOAP format. The zip file contains a generic serialization example - the same client code is used to serialize an object into selected format, using IFormatter. The demo also shows how to use .NET stream-based serialization.
|
|
|
| |
|
When client on thread T1 calls a method on an object, that method is executed on the clients thread, T1. However, what should be done in cases where the object must always run on the same thread, say T2? Such situations are common where thread affinity is required. For example, .NET Windows Forms windows and controls must always process messages on the same thread that created them. To address such situations, .NET provides the ISynchronizeInvoke interface. The zip file contains a helper class called Synchronizer. Synchronizer is a generic implementation of ISynchronizeInvoke. You can use Synchronizer as-is by either deriving from it or contain it as a member object, and delegate your implementation of ISynchronizeInvoke to it.
|
|
|
| |
|
The .NET Thread class has no built-in support for graceful thread shut down. If you call Thread.Abort(), the thread is aborted, without a chance for cleanup (such as closing and releasing resources), and Abort() is not guaranteed to succeed. The zip file a contained the WorkerThread class template, that demonstrates a structured and correct way to kill a thread.
|
|
|
|
.NET remoting requires a lease and a sponsor for a remote object, so that it will be kept alive. The app demonstrates how to develop and deploy a sponsor, how objects can provide their own custom lease, and the required configuration and administration entries.
|
|
|
|
Demonstrates using manual reset events for cross-threads communication.
|
|
|
|
Demonstrates using monitors for cross-threads communication.
|
|
|
|
A host, class library and a client, all using Visual Basic .NET without configuration files.
|
|
|
|
.NET provides support for distributed applications. Remote applications can accept calls in binary or SOAP format (on either TCP or HTTP channels). A remote application must register the objects it exports and the channels it is willing to accept calls on, and a client application must register the objects it wishes to access remotely, and indicate the activation channel. In addition, there are three activation modes, and three ways to create remote objects. It is therefore no wonder that .NET remoting baffles many. The zip file contains a comprehensive demo of a remote application and a client, demonstrating the various permutations and scenarios using a simple user interface, as well as how the host application and the client can easily share the server metadata.
|
|
|
| |
|
When using remote events, the roles are reversed: the server becomes the client, and the client the server. There are a few configuration changes required to enable remote events, as demonstrated by this app.
|
|
|
|
When developing a distributed .NET application, you need to provide a host for your objects. The host must be running when the first call takes place, so using a system service is an obvious choice. The demo app contains a service, test clients and an installation program for the service.
|
|
|
|
The app demonstrates basic .NET role-based security, and the required app domain initialization steps.
|
|
|
|
Until version 2.0 of .NET, by default, communication between two machines using .NET (without Enterprise Services) is not secure. The Remoting team has released a secure channel for .NET remoting, available here. The only problems with the article are that the code and configuration samples have errors or insufficient information on how to apply it. This sample app provides a working sample of the secure channel.
|
|
|
|
Developers often resort to locking the object at the scope of methods. This demo app demonstrates how to use the MethodImpl attribute to have the compiler generate the synchronization code automatically.
|
|
|
|
.NET provides thread-specific heap, where application can store thread specific data. The data is in the form of either named value and value pairs, of simply data slot objects. Thread local storage come in handy when developing frameworks and large applications. The zip file contains a demo client, that uses thread local storage both as named slots and slot objects, as well as showing the proper way of doing a clean up.
|
|
|
|
The thread pool allows developers to queue requests for execution for the pooled threads, and it is often an easy alternative for managing your own threads. The app demonstrates using the thread pool.
|
|
|
|
Developers often create thread or use message loops to periodically call back into their application. .NET provides three timer mechanisms just for this purpose. The zip file shows the correct way of using these timers, and contrasts them.
|
|
|
|
All waitable handles are polymorphic with the base class WaitHandle. This allows developers to write synchronization code than is independent of the actual handle type. The app demonstrates using a manual and automatic reset events for cross threads communication.
|
|
|
|
WorkerThread is a wrapper class around the underlying managed thread. It provides easy to use overloaded constructors, Kill() and Start() methods, and a better programming model than the basic Thread class. Once expanded, you will have a Visual Studio.NET project for the WorkerThread class and a test client, as well as XML-based documentation.
|
|
|
|
