The IDesign serviceware downloads is a set of original techniques, tools, utilities and even breakthroughs
developed by the IDesign architects. The utilities are largely productivity-enhancing tools, or they compensate for some oversight in the design of .NET or WCF.
The demos are also used during our Master Classes to demystify technical points, as lab exercises or to answer questions.
The classes' attendees find the demos useful not only in class but after it. The demos serve as a starting point for new projects, and as a rich reference and samples source.
There are two categories of downloads: .NET and WCF. The downloads are the result of 13 years of applying .NET and educating the industry about it, covering C#,
essential .NET concepts, .NET application frameworks, system issues and Enterprise Services. The WCF downloads provide some essentials WCF demos as well as a rich reference for contract design,
instance management, operations and calls, faults, transactions, concurrency, queuing, security and the Windows Azure AppFabric service bus.
You can rework the SvcUtil or VS generated proxy so that the same proxy will offer both synchronous and asynchronous calls. To download demonstrates the required code changes, as well as where to place the fault contracts.
WCF offers a the client a facility for dispatching calls to the service asynchronously. This is strictly a client-side feature, and the service itself is completely unaware that it is being called asynchronously. The client obviously needs a way to be notified when the calls complete and be able to harvest returned values or catch exceptions. All that is doe using a simple directive to SvcUtil: the /asyc switch that generates an asynchronous proxy. The download contains a sample asynchronous and synchronous proxy and a matching client, that uses a complete method to be notified when the call returns.
By default WCF will not let a service callback within a service operation to its clients. The reason is that by default the service uses single-threaded access – only one client is allowed to call it at a time. If the service were to allow to call back to its client it could result with a deadlock if the client will call to the service as a result of the callback to the client. To allow callbacks, you need to configure the service for reentrancy – that is, release the lock before the callback, as show in the demo.
The solution demonstrates IDesign CallbackThreadAffinityBehavior - a custom endpoint behavior attribute that makes all callback instances (regardless of the worker threads used for the callbacks) execute on the same thread. The attribute uses IDesign custom .NET 2.0 synchronization context that always marshals the calls to the same thread. This is instrumental is advanced cases such as thread local storage and COM interop as well as advanced synchronization needs.
By default, WCF calls execute in the order received by the service. This solution contains CallsPriorityBehavior attribute - a custom attribute that relies on a custom synchronization context, which marshals the calls to a pool of threads. The calls are sorted based on priority, then executed. The client provides the priority to the proxy constructor.
Instead of having a service update a form, how about making the form itself the service? The solution demonstrates IDesign FormHost<T> - an abstract class that simply by deriving from it makes your Windows Forms form a WCF singleton.
When a service needs to update UI, if the service is not using the UI synchronization context, the service must manually marshal the call (which comes in on a worker thread) to the UI thread. The easiest way of doing that is using an anonymous method and a synchronization context, as shown in the download.
You can quite easily have your service update some UI on the host side. All you have to do is open the host on the UI thread after establishing the Windows Forms synchronization context. In fact, nothing prevent you from having multiple UI threads, each with its own set of Forms and services, as shown in the download.
While the main motivation for reentrancy configuration is callbacks, it has its use in with cyclic calling: Service A calling B calling C calling back into A. Without reentrancy this would mean a deadlock, as shown in the download.
by default, the completion callback of an asynchronous WCF call comes in on a thread from the thread pool. If the callback needs to execute on a particular thread (such as updating the UI with Windows Forms), you must marshal the call. The solution is IDesign's AsyncClientBase proxy base class, that will automatically marshal the call to the client synchronization context (if present).
Calls enter the service on worker threads. If the service needs to update Windows Forms forms and controls, it must marshal the update to the UI thread(s). Instead of using the synchronization context directly which serializes all calls to the service, you can use IDesign set of thread-safe Windows Forms controls - any service can access them as if running on the UI thread. This enables the same service to update multiple forms on multiple threads, and only marshal when necessary.
By default, WCF will establish an affinity between the service host and the synchronization context it was created on. Since by default there is no synchronization context, client calls are services on arbitrary worker threads. The download contains IDesign custom .NET 2.0 synchronization context that always marshals the calls to the same thread. By installing the custom synchronization context and then opening the host, all client calls are always routed to the same thread, thus establishing thread affinity between all instances and all endpoints of the service.
The solution demonstrates IDesign ThreadAffinityBehaviorAttribute - a custom service behavior attribute that makes all service instances (regardless of the service instance mode or concurrency mode) execute on the same thread. The attribute uses IDesign custom .NET 2.0 synchronization context that always marshals the calls to the same thread. This is instrumental in advanced cases such as thread local storage and COM interop as well as advanced synchronization needs such as when creating a window (or a popup window) to be updated by the service.
By default, WCF calls execute on threads from the I/O completion ports thread pool. For some high-end scenarios, you may want to allocate a dedicated pool of threads to all calls of your service. This solution contains the ThreadPoolBehavior attribute which lets you specify the size of that pool. A pool size of one will generate thread affinity. The technique used here is a custom synchronization context that marshals all incoming calls to the dedicated pool of threads.
The download contains an interesting concept – a service that acts like a timer, calling back to its clients on requested intervals. The service actually uses the .NET timer and delegates, and is a nice demo of how to bridge the two technologies - the timer delegates and the WCF callbacks. In addition, it demonstrates WCF ability to marshal the callbacks correctly to the UI thread the client it running on.
By default callbacks enter the client on worker threads. If the client is a Windows Forms object, you must marshal the calls to the UI thread. By default this is exactly what WCF will do if the client is a Windows Forms form. But if the client uses a worker thread to dispatch the calls, there will be no marshaling. The client may do so to avoid a deadlock if the service tries to call back during a service call. The download shows such a client that uses its own synchronization context to post messages back to its own UI thread to process the callbacks and avoid a deadlock.
When callbacks enter the client, they do so on a worker thread. If the callback object is a Windows Forms object, that worker thread cannot access the form directly, and instead, the call must be marshaled to the UI thread. Fortunately, WCF can do that automatically for you. Simply call the proxy on the UI thread, and the callback will be marshaled to the UI thread in turn. The download demonstrates this behavior.
While C# and VB will let you overload interface methods, by default, WCF will not let you overload contract operations. However, using simple aliasing you could provide both the service and the client the overloaded programming model, as shown in the download.
The MetadataHelper class provided for a runtime way of parsing and querying the contracts of a running service. It allows the client to find out programmatically if the service supports a specified contract, it obtains all contracts of a running service, or the operations of a specified contract. These powerful and useful features are often required during setup or in administration applications and tools.
On the service side, WCF lets you define and use a contract hierarchy simply by applying the ServiceContract attribute at every level of the interface hierarchy, deriving and implementing it. The service can even expose a single endpoint for all contracts. However, the imported metadata definitions on the client side do not maintain the interface hierarchy. The solution shows the simple steps required to rework the client side definitions to reflect correctly the contract hierarchy and maintain an is-a relationship between the imported contracts.
Even after reworking the imported definitions of a contract hierarchy, you still have a single proxy class. You can however have the client use a hierarchy of proxies that provided an is-a relationship between the proxies, yielding a much smoother programming model. The solution demonstrates this technique we call proxy-chaining.
When serializing a data contract type into or from a service operation, the compiler will gladly let you pass in a sub class of the data type. However, this will by default fail the call because WCF will not know how to serialize or deserialize the sub class. For that, you have to apply the KnownTypeAttribute at the proxy or contract level, as show in The download. You will also need to apply the attribute on the service side if the service needs to return matching sub classes.
WCF will let the service define a contract that returns a custom collection. While you cannot share the definition of the custom collection across the service boundary, you can apply the CollectionDataContract attribute to have it exposed to the client as a custom generic list, as shown in The download.
While the default behavior of a data contract type is to simply ignore extraneous unexpected members, you can instruct it to still store and pass it along to and from the service by implementing IExtensibleDataObject. This enables a round-trip scenario, where a new client is calling an old service with the new data contract, and the service can even pass the data contract unaffected to another service or client, as shown in the download.
The download demonstrates WCF ability to use ADO.NET data tables as-is in operation parameters. You can even use type-safe data tables, and the imported proxy file contains an imported data table definition. You can remove that definition if the client has a local definition already of the table.
While WCF lets you freely pass ADO.NET data tables to and from a service, it is a questionable practice at best if the service needs to work with non-.NET clients. It is better in such cases to rerun the items in a neutral array. The solution demonstrates the use of the IDesign helper class DataTableHelper which converts the table to an array.
The WCF provided known type resolver requires dedicated coding for each and every sub class, and also to manually install the resolver on the host and the client. IDesign's generic resolver addresses all that, and to a large extent, makes the whole issue of known types simply go away. The generic resolver uses reflection to find all possible known types in all referenced assemblies and as long as the compiler allowed them, the resolver resolves it automatically. You can also instruct it to resolve only specific known types. On the service side, you can use the GenericResolverBehaviorAttribute to allow the service to accept any sub class of its data contracts. You can also use the AddGenericResolver() host extension method to attach the reso
With .NET 4.0, WCF provides for a simple programmatic way of resolving a known type issue. Whenever the serializer encounters a type it does not know how to resolve, allows the developer to resolve it at runtime by deriving from DataContractResolver and calling ResolveName() during deserialization to return the resolved type or TryResolveType() to return the name and namespace of a type being serialized. The demo shows how to implement such a resolver for a particular case. You will also see how to install the resolver on the host and the client sides. As you can see, it is very labor intensive. This issue is addressed with the Generic Resolver provided by IDesign.
While you typically apply the KnownType attribute at design time to allow sub classes of your data contract, this is of no use when the client passes in a new sub type later on. You can compensate for that by including the known type information in the config file, as shown in the download.
When generating an equivalent data contract to an already existing one, it is insufficient to alias the type and the members. You also need to ensure that the order of serialization is maintained – first by class hierarchy then alphabetically. In case of a discrepancy, you can compensate by setting the Order property of the DataMember attribute as shown in the download.
WCF lets the client and the service version independently their definitions of the same data contract. If the client sends a type with a missing member the service expects, the missing member on the service side will be initialized to its default value. If the data type contains a member the service is unaware of, it will be silently ignored. In addition, WCF allows both sides to explicitly require a particular data member or else fail the call. The download contains three solutions demonstrating these behaviors.
<a name="Discovery">The solution demonstrates several important points often used in conjunction with discovery. The service uses the standard MEX and discovery endpoints, as well as relying on the host to implement the discovery and metadata exchange endpoints. This means you have to explicitly add the default endpoints. The service also picks up an available TCP port on the fly, dynamically. The client uses two techniques to invoke the service. The first is regular discovery of the address while having a priori knowledge of the binding. The second is with the IDesign DiscoveryFactory, which first discovers the service metadata address, then obtains the metadata, and uses the address and the binding in the metadata to create the proxy.
The demos shows how to configure all hosts in the process to automatically announce their state (Hello/Bye). The client uses the IDesign AnnouncementSink<T> to receive the announcements. While AnnouncementSink<T> hosts internally an instance of AnnouncementService, it improves on its deficiencies. First, AnnouncementSink<T> offers two event delegates for notifications. Unlike the raw AnnouncementService, AnnouncementSink<T> fires these delegates concurrently. In addition, AnnouncementSink<T> disables the synchronization context affinity of AnnouncementService, so that it can accept the announcements on any incoming thread, making it truly concurrent. AnnouncementSink<T> filters the contract types and only fires its events when compatible en...
If the service knows the clients will use discovery, then there is no need to deploy the service pre-configured ports or pipes. The host can simply pick up any available port or pipe on the fly, at runtime. This is exactly what you can do with the IDesign helper class DiscoveryHelper and its properties AvailableTcpBaseAddress and AvailableIcpBaseAddress. provide those to the host as base addresses and enable discovery.
Using raw duplex for events couples the publishers to the subscribers. They each have to know where the other is, both have to be running to publish or receive events, subscribers cannot subscribe to a type of event, and publishers cannot broadcast an event to subscribers they do not know about. The publish-subscribe design pattern decouples the publishers from the subscribers by introducing a dedicated subscription service and a dedicated publishing service in between. You can also have transient subscribes which are live subscribers using callbacks and persistent subscribers which are services to invoke like any other service, and can even be not-running. The download contains IDesign framework for implementing in only a few lines of code
When calling ServiceHost.Close(), calls in progress are allowed to complete gracefully, and only future calls are denied. ServiceHost.Abort() on the other hand is an ungraceful exit, and it aborts calls in progress, resulting with an error on the client side. This simple demo lets you experiment with the differences between Close() and Abort().
By default, the service host class creates the service instance in the same app domain as its caller. This solution contains the IDesign custom service host AppDomainHost that injects the service instance in a new app domain, thus better catering for fault and security isolation.
With .NET 3.5, WCF provides three context bindings (BasicHttpContextBinding, NetTcpContextBinding, WSHttpContextBinding). These support a context protocol for passing custom parameters from the client to the service in the form of a dictionary of strings keys and values. This is a general technique for passing out-of-band parameters to the call, in effect giving the service a custom context, not unlike the other WCF contexts, such as transaction or security. Using the context binding on both sides requires intricate interaction with the operation context and the proxy. To automate, IDesign provides the ContextManager helper class which streamlines reading and writing into the context binding and ContextClientBase<T>, which derives ClientBas
The solution contains an IDesign helper class called InProcFactory - a WCF factory designed to streamline and automate hosting services in the same process as the client. There is no need for any config file or programmatic calls to create the host or configure the binding. All the in-proc factory requires is the type of the service and the type of the requested contract. It is as close as you can get in WCF to the Win32 API of LoadLibrary() and it is the easiest way to shim up a class as a service instead of using the class as a traditional CLR class.
WCF lets the service execute in the client’s process. This hosting mode is called In-Proc hosting. You should use named pipe binding, and you can even have a single config file for both the client and the host. This simple demo demonstrates in-proc hosting.
A WCF client can add into the message headers any custom information, and the service can in turn read those headers. Message headers are a general techniques for passing out-of-band parameters to the call, in effect giving the service a custom context, not unlike the other WCF contexts, such as transaction or security. Using the headers on both sides requires intricate interaction with the message, the operation context and the proxy. To automate, IDesign provides the GenericContext<T> helper class which streamlines reading and writing into the headers any custom context, and HeaderClientBase<T,H>, which derives IDesign's InterceptorClientBase<T> and automates passing the parameters from the client. The demo shows how to provide for a simp...
The Metadata Explorer is a helper utility that visualizes the available service endpoints of a running service. This is done using metadata exchange - roughly the WCF equivalent of .NET reflection. Metadata contains not just contracts and operations but also information about security, transactions, reliability and faults. WCF makes it easy to programmatically query and discover the metadata of a service. The tool uses WCF's MetadataExchangeClient and MetadataImporter, and WsdlImporter to obtain and parse the metadata into endpoints. The Metadata Explorer tool simply visualizes the information returned and is very useful in seeing what a service has to offer without resorting to development tools. The tools also utilizes discovery, allowing
A service is not limited to a single endpoint. As The download demonstrates, the service can have any number of embonpoints with any combination of addresses, bindings, and contracts. Similarity, the client can decide to consume a particular endpoint or all of them. The demo shows the required configuration on both the service and the client side.
While .NET 3.5 provides the NetTcpContextBinding, NetBasicHttpContextBinding and WSHttpContextBinding, it does not provide a matching support for IPC. IDesign rectifies this oversight by providing NetNamedPipeContextBinding. The demo shows both the steps required to implement such a custom binding, the supporting configuration-enabling types and also how to register it so that you could use it like the built-in binding in a config file.
Both the service and the client can use either a configuration file to list the endpoints and the related binding or behavior configuration or they can use programmatic calls to achieve the same effect. The solution contains a simple client and service that configure themselves programmatically. It is the same demo of the multiple endpoints only programmatically.
Using IIS or the WAS does not mean you cannot use a custom host. All you need is to provide a custom service host factory that derives from ServiceHostFactory, instantiate your custom host, provide the custom host initialization and return the host reference, as shown in this solution.
The zip file contains a Visual Studio 2005 custom snippet that automates generating a simple WCF contract and the matching implementing service. The service uses the best practices for transaction context, transaction voting, and instance management.
A class library containing all the IDesign helper classes, utilities and tools. The library also contains a comprehensive catalog of ServiceModelEx, containing short documentation of each type, its category and reference to related classes or types.
This demo shows how to use the IDesign Generic Interceptor framework to implement a simple trace of pre and post calls including parameters. The Generic Interceptor framework is nothing short of extensions for the WCF extensions.
<a name = "WCFEssentials">With IIS7 on Windows Vista and Windows Server 2008, you can use the Windows Activation Service (WAS) to host your WCF services. While very similar to IIS6 and IIS5 hosting (virtual directories, svc files, etc), with the WAS you are not limited to HTTP and can use TCP, named pipes (IPC) and MSMQ. There is a one-time setup step (done in the included cmd file) to allow these interactions, where you assign a port number for your web site and allow the protocols for your application (the WCF service). The rest is regular WCF as shown in the demo.
The solution demonstrates IDesign fault handling framework, this time on the client side. The CallbackErrorHandlerAttribute is applied on the callback client-side class. It installs an error handler on all callback dispatchers. The error handler promotes all exceptions to matching fault exceptions if found in the fault contract of the callback contract, and it logs the exception to a dedicated logbook service. The log entry contains a detailed stack and context dump. The solution also contains the logbook viewer application.
WCF lets the service be configured to return all unknown exceptions as faults, even if there are not listed in the fault contracts. This aspect of the service behavior is especially useful during debugging. The download shows how to turn on this feature only for debug builds using the IncludeExceptionDetailInFaults property of the service behavior.
While the combination of IncludeExceptionDetailInFaults and the propagation of ExceptionDetail to the client lets the client (for debugging purposes) examine the original exception thrown by the service, programming against FaultException<ExceptionDetail> is cumbersome, and, it does not fault the channel, unlike the real exception. The client can compensate by extracting the original exception, and even recursively build the inner exception tree. To streamline, the client can use the IDesign DebugHelper class to automate these steps, and even encapsulate its use in the proxy, including faulting the channel, as shown in the solution.
<a name ="Faults">The solution demonstrates IDesign fault handling framework. The class ErrorHandlerHelper automates implementing IErrorHandler: it promotes all exceptions to matching fault exceptions if found in fault contract, and it logs the exception to a dedicated logbook service. The log entry contains a detailed stack and context dump. The solution also contains the logbook viewer application. The attribute ErrorHandlerBehaviorAttribute wraps the use of ErrorHandlerHelper and automatically installs the error handler by attaching it to all dispatchers.
By default all service side exceptions are indistinguishable from communication exceptions. WCF lets developer use the FaultContract attribute to explicitly return a known fault from the service. Such faults would also not fault the channel and allow subsequent calls, as shown in the download.
If you want to change the default error handling and propagation on the service, you can add a custom service behavior that also supports the IErrorHandler interface, and add that behavior to every dispatcher. The solution shows a service that implements the custom behavior and IErrorHandler directly, and the affect it has on the client side reported exceptions.
<a name = "InstanceManagement">Normally, WCF deactivates a session-full service when the sessions ends. However, instead of waiting for the client to close the proxy or a timeout, you can use the context deactivation feature of the OperationBehavior attribute to deactivate the service, before, after or before and after the call, as shown in the download.
Normally, WCF deactivates a session-full service when the session ends. However, if the session has a particular lock-step state machine, you can configure operations on the contract to terminate the session, or to not be the first operation in the session, as shown in The download.
For durable services that use the DurableService attribute to have WCF serialize and desterilize their state between calls, you need to configure the host with the details of a persistence provider in the config file. You need to derive from PersistenceProviderFactory and override a simple set of methods. The demo contains IDesign's FilePersistenceProviderFactory and FilePersistenceProvider, which as their name imply, persist the state of the service into a file. you will also see how to provide custom parameters in the config file (such as a file name) in the constructor of the persistence provider factory. The client still needs to manage the instance ID on its side, and that is done using the dedicated IDesign helper classed for context
For durable services that use the DurableService attribute to have WCF serialize and desterilize their state between calls, you need to configure the host with the details of a persistence provider in the config file. You can use the WCF-provided SQL persistence factory of SqlPersistenceProviderFactory. The client still needs to manage the instance ID on its side, and that is done using the dedicated IDesign helper classed for context binding and instance ID. You will also see when to set the CompletesInstance property of the DurableOperation attribute to remove the instance state from the store, and how the client picks up a new instance ID on subsequent calls.
WCF supports three classics instance management modes: per-call assigned a new instance per request, per-session assigns a private instance for the client for the duration of the session, and a singleton instance serves all clients regardless of sessions and connections. You control these modes using the InstanceContextMode property of the ServiceBehavior attribute and the contract itself. The download contains three solutions letting you examine the differences between the three modes.
Throttling is a host behavior. Before opening the host, you can programmatically throttle various communication thresholds of your service such as the number of concurrent calls or instances, as shown in the download.
When passing large payloads in WCF, you can run into max message size constraints, timeouts, and large bandwidth consuming retries. One way to address that is to chunk up larger payloads into a series of chunks that get sent as individual messages so that if one fails you only need to retry for that single item. If combined with reliable messaging, you can get ordering assurance and automatic retries. This sample shows how to put a thin layer on the client and service side that does the chunking and reassembling of the payload for a file stream, keeping it from ever being loaded into memory as a single large buffer. The same technique could be applied to a large object graph by serializing the large object graph in the shim layer and sending it in chunks then deserializing in the receiving layer.
<a name = "Operations">When dealing with a duplex contract, every operation carries with it the callback reference. In most applications the client also would like to explicitly start or stop receiving callbacks. You can do that by adding a Connect/Disconnect methods to the contract, as shown in The download.
When using the WSHttpDualBidning for callbacks, WCF will use by default port 80 for the callbacks. This will likely conflict during development time with local installation of IIS, and is of little use in Intranet deployment. However, as The download shows, you can configure the client callback base address in the client-side config file to have a different port.
When using the WSHttpDualBidning for callbacks, WCF will use by default port 80 for the callbacks. This will likely conflict during development time with local installation of IIS, and is of little use in Intranet deployment. Instead of using a config file to hard-code the callback port or making programmatic calls at run time, you can use the IDesign's ClientBaseAddressBehaviorAttribute to configure the port, either hard-code it or select an available port at run time. The attribute implements the IContractBehavior interface, as shown in the download.
The classic use for callbacks in WCF is for events. The service can maintain a list of callbacks, and notify them when some event takes place on the service side. The service contract can define subscribe and unsubscribe operations, and take a masked enum to allow the clients to chose which event to subscribe or unsubscribe to. In fact, you can even use delegates on the service side to manage the subscribers. This use in an interesting bridging concept: the service uses conventional delegates to manage and publish events, when the events are delivered using WCF duplex callbacks.
All WCF bindings support one-way calls – the ability to fire and forget a method. Simply set the IsOneWay property of the OperationContract attribute to true. However, as The download demonstrates, one-way calls do not equate asynchronous calls, or even concurrent calls - because the calls are queued up on the service side, the client may still block, as a product of concurrency mode, the instance mode, the binding and the reliable session.
When using the WSHttpDualBidning for callbacks, WCF will use by default port 80 for the callbacks. This will likely conflict during development time with local installation of IIS, and is of little use in Intranet deployment. Instead of using a config file to hard-code the callback port, you can use the IDesign's WsDualProxyHelper class to select any available port at run time, as shown in the download.
A small framework for implementing a discovery-driven publish-subscribe pattern for events firming and subscriptions. Unlike common techniques for supporting the publish-subscribe design pattern, a discovery-based solution is the only publish-subscribe case which requires no explicit steps by the subscribers or administrator. When utilizing discovery, there is no need to explicitly subscribe either in code or in config. In turn, this significantly simplifies the deployment of the system and it enables great volatility in the presence of both publishers and subscribers. You can easily add or remove subscribers and publishers without any additional administration steps or programming. The subscribers can provide a discovery endpoint so that t
By default the message has to be received in it’s entirely by the service or the client before being processed. Instead of buffering the message, you can return a stream, and have WCF on the receiving end start processing the message while it is being streamed. The classic example for streaming is large media files. The download is a simple music download service and a player client using streaming. In addition, you may have to configure the maximum allowed message size, as shown in the download.
This sample shows how to chunk up a payload that has been loaded into memory and leverage distributed transactions to ensure that the bits get to the client and get persisted successfully. One of the samples keeps the bits in memory on the server until the whole payload is received and reconstructed and then stores it in the DB. The other one persists the chunks in the DB as they arrive so they do not all have to be held in memory for the entire transfer.
The WCF provide duplex proxy DuplexClientBase is object-based and is thus not type safe. In addition, the context class InstanceContext is also object based. The compiler does not verify the relationship between these objects, and there is no verification of the relationship between the callback contract type and the service contract. However, you can fix most of these using generics. The solution contains IDesign InstanceContext<C> and DuplexClientBase<T,C> which provide the added degree of type safety, as well as a matching duplex factory called DuplexChannelFactory<T,C>.
An occasionally connected service can issue direct synchronous calls when connected and queued called over MSQM when disconnected. The download contains a service that exposes both a queued and regular endpoint. The client uses the network events to monitor the network status, and uses the queued endpoint automatically when disconnected (such as when the network is disabled).
When a message continuously fails, it is deemed as a poison message. WCF lets you configure in the binding how many attempts to try before considering the message as poisonous. This demo shows a service that always throws an exception thus always failing. The service uses an error handling extension to log the errors using the logbook, error extension and viewer provided by IDesign. The repeated attempts are logged, and then the last exception (MsmqPoisonMessageException) indicating a poison message.
Using the NetMsmqBinding WCF lets the client post messages to an MSMQ queue instead of a service. When the service host is connected, WCF will dispatch to it the queued calls. The download contains a simple queued service and client.
The MSMQ binding only works in the Intranet. However, The client may want to queue up calls to services over WS bindings, and WS-binding enabled service may want to queue up calls before executing them. The solution is to use an intermediary bridging queued client and queued service. The client uses queued calls locally and the client-side queued bridge service uses WS binding to call service-side bridge across the Internet. The service-side bridge uses queued calls against a local service. The solution demonstrates the required configurations and contract adjustments required.
Which a queued per call service, every client calls gets a separate MSMQ message. If the client is also transactional, all those messages get posted to the queued as one batch, as shown in the download. The messages will be played independently, each to a new service instance.
Which a queued and session full service, all the client calls get packaged in a single MSMQ message. If the client is also transactional, that message is posted only on successful completing the client transaction. As shown in The download, when the single message is dequeued all the calls are played to the same instance in the order the client issued them, then the service instance is disposed.
This download uses the IDesign framework for implementing a publish-subscribe service in conjunction with queued calls. The publisher can fire the event synchronously or queued. The persistent subscriber can be regular or queued. You can experiment with both a queued publisher and a queued subscriber.
<a name = "Queuing">This solution demonstrates how a singleton can accept queued calls, and how the singleton shares its state across clients and queued calls. You will see how to configure a transactional queued service.
A queued service may need to report results or errors to its caller. However, queued called are one-way calls, and callbacks are not possible. However, the service can report back to a client-side queued service called a response service. There are some details to work out: correlating methods, passing the response service address, and so on. The solution contains IDesign helper framework for supporting response service. The extraneous information (the ResponseContext data contract class) is stored in a custom message header, and other helper class creating a response service proxy on the service side and headers management. You will also see how to wrap the proxy in a response-service aware proxy, how to correlate me
The demo shows how you can use a form as a queued response service. It uses IDesign's framework for a queued response service, with FormHost<F> for turning the form into a service, a queued service in this case.
By default WCF will use the security token on the calling client for authenticating it. However, you can easily supply alternative credentials (usually via some log-on dialog) as shown in the download.
A WCF service may opt for not authenticating its clients and allowing anonymous access, and yet it should do so without compromising the message privacy and integrity. The download shows the required configuration setting for allowing anonymous access and still using the service certificate for security the message.
Two interoperating business partners may often opt for a private, secure communication using each other certificate for mutual authenticate. The download shows the required configuration on the service and client side, a batch file for generating and installing the certificates, how to deal with test certificates, and how to configure for message transfer security using certificate.
While using a certificate to authenticate the client, you can still rely on ASP.NET security. The download demonstrates the required steps to configure the host and to add the certificate to the ASP.NET role provider.
By default, WCF offers very limited support for partially trusted clients, and most scenarios require full trust. To restore support for partially trusted WCF clients, IDesign provides PartialTrustClientBase<T>, used very much like the regular proxy base class, without compromising on the WCF programming model or on code-access security. PartialTrustClientBase<T> supports partial trust callers. It analyzes the context of the call and demands the appropriate permissions. This is a collection of some 16 demos showing various cases of partial trusted clients trying to rely on various aspects of WCF.
By default, WCF offers very limited support for partially trusted hosts, and most scenarios require full trust. To restore support for partially trusted WCF clients, IDesign provides AppDomainHost, used very much like the regular host, without compromising on the WCF programming model or on code-access security. AppDomainHost supports hosting a service in a partial trust environment. It analyzes the context of the hosting and demands the appropriate permissions. The service itself is hosted in a separate app domain, and you can provide the exact permissions for the service app domain to execute in partial trust sandbox. This is a collection of some 14 demos showing various cases of partial trusted hosts trying to rely on various aspec
Even though the hosting code may have full trust, you may want to host the service itself in partial trust, to reduce the surface area for attack and to run the service in a virtual secure sandbox. You can use IDesign's AppDomainHost to specify exactly the permissions to grant the service, and AppDomainHost will place the service in a separate app domain with those permissions You can specify the permissions individually, or using a permission set file, or use a standard permissions set. You can even host the same service multiple times, each with a different permissions set, as shown in the demo.
Both Internet and Intranet applications often require a custom store for user accounts and roles. ASP.NET 2.0 provides an out-of-the-box provider model as well as a SQL Sever database just for that propose. Unfortunate, the only way to administer the credentials databases is via Visual Studio 2005, and only for local web applications. This solution is a full-blown custom security management application that administrators can use. The application presents a rich user experience, and can administer the store remotely. The application wraps the ASP.NET 2.0 providers with a WCF service that can be self-hosted or hosted in IIS, and even adds missing features. The download contains the Credential Manager client, the CredentialsService and host.
WCF lets the client provide custom credentials and have the service authenticate the client by looking up the credentials in the ASP.NET membership data base in SQL Server. Once authenticated, the service can use role-based security to authorize the user against the custom roles in the data base. The download shows how to configure both on the client and service side the certificate used to encrypt the credentials and the message body itself, and how to configure message transfer security for ASP.NET providers on the service and the client, how to configure for ASP.NET providers membership and roles, how and when to supply the application name, and additional settings required for the providers. The service also displays identity report.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting. The solution demonstrates using SecurityBehaviorAttribute to configure alternative Windows credentials in the Intranet.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting, and there is a matching client side helper class and proxy. The solution demonstrates using SecurityBehaviorAttribute to configure anonymous yet secure and private access to the service.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting, and there is a matching client side helper class and proxy. The solution demonstrates using SecurityBehaviorAttribute to configure using ASP.NET providers for custom credentials when the service is exposed to the Internet.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting, and there is a matching client side helper class and proxy. The solution demonstrates using SecurityBehaviorAttribute to configure business to business security (such as between two trading partners) using certificates on both sides for mutual authentication.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting, and there is a matching client side helper class and proxy. The solution demonstrates using SecurityBehaviorAttribute to completely turn off security.
<a name ="WCFSecurity">The IDesign ServiceSecurity also offers the SecurityAuditEnabled property which lets the service declare its need for a security audit. This properly complements the config setting, and will not override the value in the config file. By setting it to true, WCF will log all security events for the service.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting. The solution demonstrates using SecurityBehaviorAttribute to configure security to use the ASP.NET providers over TCP in the Intranet to pass custom credentials.
Security is the most intricate WCF aspect, and there is no built-in declarative model. To avoid, simplify and streamline security, IDesign developed a declarative attribute based security model. The SecurityBehaviorAttribute service attribute is used like any other service attribute to configure the security scenario. The attribute offers a few simple properties that default to reasonable setting, and there is a matching client side helper class and proxy. The solution demonstrates using SecurityBehaviorAttribute to configure the service and the client to use Windows accounts and yet communicate securely over the Internet using the WSHttpBidning.
When using the Intranet bindings, WCF allows the contract developer to demand a protection level when dealing with sensitive contracts or operations. The download demonstrates this technique by setting the ProtectionLevel property of the ServiceContract attribute.
This demo shows how to use the IDesign Generic Interceptor framework to propagate the entire stack of callers (their identities, authentication level, operations, etc) in every call. This offers a secure alternative to impersonation, allowing every stop along the call chain to find out the identity of the callers (and the original caller). You still need to protect and sign the stack of callers yourself. the demo uses both IDesign support for managing message headers and the Generic Interceptor framework. The Generic Interceptor framework is nothing short of extensions for the WCF extensions.
WCF supports security audits - it can dump to the event log security related events in your services such as authentication and authorization attempts, their time and location, and the client’s identity. This solution demonstrates the required config settings to use the ServiceAuthorizationBehavior.
WCF lets the client provide simple username and password credentials to the service. The credentials can in turn be mapped to Windows accounts on the service side, as shown in The download. In addition, The download shows how to configure both on the client and service side the certificate used to encrypt the credentials and the message body itself, and how to configure message transfer security for username credentials type.
When using Windows accounts, the client can restrict to what degree the service can impersonate it. The service can decide to use its own identity or try to impersonate the client. The download contains a client that provides UI for custom credentials and also allowed impersonation level. The service will try to impersonate the client using the OperationBehavior attribute and a custom hosting behavior the impersonates all callers automatically. In addition, the service displays a detailed report in its constructor and in the operation. The report contains the incoming client identity, the process identity, and the principal identity.
By default WCF will use Windows groups to authorize the caller. You can use the PrincipalPermission attribute to demand that the caller is a member of such a role, as shown in the download. The caller can use its own interactive security token or custom credentials.
WCF allows you to combine the work of multiple threads in a single transaction. You need to provide each worker thread with a clone of the original transactions, and signal to the original client thread when the worker threads have completed their work. The download shows a simple banking application where the client uses multiple threads to interact with the account services, demonstrating this complex topic and a few related issues such as passing the transaction between threads and synchronizing completion.
In general, transactions and duplex callbacks do not mix well. Callbacks are usually one-way operations which cannot flow transactions, and transactional services are often single-threaded, which precludes flowing the service transaction to the client during a service call. However, the service can be configured for reentrancy and to disable releasing the instance once the transaction completes. Doing so will enable the service to flow its transaction to the callbacks. The service can also store the callback references for later use, in which case, as shown by The download, a service-side transaction can flow to the client. You will need to configure the callback client for transaction just as with a service.
When using the Client/Service transaction mode, the service is configured to allow transaction flow, and yet WCF will not enforce the use of a transaction-aware binding at all, or the use of a transaction-aware binding with TransactionFlow enabled. To tighten this loose screw use the IDesign BindingRequirementAttribute to enforce the use of a transaction-ware binding with TransactionFlow set to true. The BindingRequirementAttribute is a nice example for a general-purpose technique you can use to enforce any binding requirement. For example, BindingRequirementAttribute has another property called WCFOnly which enforces the use of WCF-to-WCF bindings only, and a property for requiring reliability. You can also use the BindingRequirementAttrib
<a name = "Transactions">In WCF transaction flow between the client and the service is a product of the TransactionFlow value in the binding, the TransactionFlowOption in the contract operation. In addition the service will use the client transaction only if it configured for requiring a transaction scope and if the client has a transaction to flow. The download contains a simple banking application showing how to configure the system so that the client can interact with two different account services and yet scope both in a single transaction.
The IDesign TransactionalBehavior attribute lets you maintain the regular non-transactional programming model of statefull services with normal member variables, and yet have the service automatically roll back any change to those members if the transaction aborts. This has the same effect as if all members were volatile resource managers. The attributes utilizes the durable services support in WCF to store the instance state into the IDesign transactional dictionary, used as as a persistence provider.
By default a transactional singleton behaves like a per-call service. You can however disable releasing the instance once the transaction completes and maintain the semantic of the singleton. You will also need to have at least one transactional method as shown in the download.
This demo shows how to combine the IDesign TransactionalBehavior attribute with the in-proc factory, so that you could mimic the conventional programming model of C#, without any of the ownership overhead of WCF (managing hosts, proxies and config files) and still benefit from transactions.
This demo shows how to combine the IDesign TransactionalBehavior attribute with the in-proc factory, and how to encapsulate the very use of the factory with the IDesign WcfWrapper class, that complete hides the very use of WCF. As a result, you program just as with normal C#, without interacting with any hosts, proxies and config files and still benefit from WCF.
A transactional service can interact not just with databases but also with volatile resource managers. The download makes use of IDesign’s implementation of the transactional collections (now part of MSDN). The service and client configuration is exactly the same as with the database-centric solution.
.NET 2.0 allows you to resolve conflicts with type name collisions by aliasing one of the references. Using the extern alias directive, you can instruct Visual Studio 2005 to root the reference in the alias, not the global namespace. The application demonstrates this technique.
<a name="Essentials">There is a lot of details involved in implementing a bullet-proof Dispose() and Finalize(), especially when inheritance is involved. The file is a generic template that handles class hierarchy, threading, multiple calls to dispose and finalization.
This sample demonstrate using interfaces to define a contract between client code and components that will be dynamically loaded as providers after the client has been built and shipped. It uses a generic type factory method to dynamically load provider assemblies and invoke their functionality based on a provider interface contract. It also demonstrates the use of Visual Studio 2005 Settings to enter runtime information into the config file and access it through the strongly typed settings class. The zip file contains a readme.doc with more information on the structure and use of the sample.
In some cases (such as unit testing or assembly decoupling), one assembly may need to access the internal types of another assembly. .NET 2.0 supports this using the InternalsVisibleTo attribute. The zipped application not only demonstrates this technique, it also contains a helper utility that you can use to browse to a client assembly, and copy to the ClipBoard the fully configured InternalsVisibleTo attribute.
Common techniques for implementing a Back link on a web page involve using the browser-side script. There are a number of disadvantages to this solution: the application has no control over where the user is going to be redirected. Often you want to keep the user inside the application, and you do not want them to wonder off to other pages, and it only works if the browser supports client-side script. The biggest disadvantage is that it is not consistent with the ASP.NET programming model of server-side controls. There is also no easy way to enable or disable the back link based on server-side event processing. The download contains a server-side user control, which provides the Back functionality. Simply add it to your toolbox, and drop it on your forms.
.NET 2.0 introduces a new asynchronous method invocation pattern, which makes sure the callbacks to the client are always made on the correct thread (as if BackgroundWorker was used). Several controls and classes support this pattern. The demo applications used the PictureBox ability to download an image asynchronously using this pattern, and it also demonstrates related PictureBox techniques such as cancellation, progress reports, and async temporary image to be used while downloading.
Windows Forms applications often require some sort of asynchronous invocation option. Windows Forms poses a set of complicated design and implementation issues when it comes to asynchronous invocation due to the underlying Windows messages processing. .NET 2.0 provides the BackgroundWorker component to facilitate easy asynchronous invocation with Windows Forms. The demo shows how to use the component correctly and when and where to set and access its methods and properties.
Even after .NET 2.0 ships, Windows Forms 1.1 developers are forced to use a cumbersome programming model when it comes to asynchronous execution of background work. The download contains IDesign's implementation of the .NET 2.0 BackgroundWorker control, done as a .NET 1.1 component, so that .NET 1.1 developers can use it, and ease the transition to Windows Forms 2.0.
The class BindingList<T> can be used like a normal linked list, with one important additional feature – you can receive events when the state of the list changes. This is instrumental in replacing timers or polling techniques used to monitor the linked list (and update user interface for example). The demo contains a simple Windows Forms client that uses BindingList to keep a list box up to date with the content of the list.
Composite Extensions for Windows Forms allows you to use the patterns and capabilities of Composite Application Guidance for WPF (aka Prism) in a Windows Forms application as well. Specifically, you can use the modular loading and loosely coupled pub-sub events model of Prism using some extensions written by IDesign architect Brian Noyes that build on top of the CAL libraries that come with Prism. You can also use dynamic injection of views into a region in a similar form to the way Prism does it using the IoC container, demonstrated in the sample application included in this code.
This simple code snippet simplifies property declaration complying with the IDesign coding standard. Specifically, member variables on a class should be private, with a wrapping public property. The name of the member variable should be the name of the property, prefixed with m_.
.NET 2.0 adds support for interface-based web services. Separation of interface from implementation is crucial for component-oriented development. Doing so allows the web service consumer to program against an abstract service definition (the interface), and switch service provides (interface implementers) without affecting its code. However, also need to tweak VS 2005 to expose and consume those interfaces for you using partial classes and shim classes. The sample is a web service that is interface, not method based, as well as a test client.
Smart client applications often need to store application settings in a partial trust environment. For strongly typed settings building applications with Visual Studio 2005, user settings can be written in partial trust once .NET 2.0 releases. In addition, sometimes you may need to store ad-hoc settings in separate files and you may not want to use user settings for those settings. Isolated storage provides a good place to put custom settings that can be written to in partial trust. This helper class allows you to read and write custom settings
Demonstrating VS 2005 ability to share files across assemblies by linking them. This allows for solution-wide info file, containing version number and other solution level attributes such as strong name, without the need to duplicate files.
.NET 2.0 makes it possible to monitor network events, in particular, the NetworkChange.NetworkAvailabilityChanged event, which lets you know when the network connectivity status has changed. This is instrumental is writing smart client applications that communicate with the server over the network, and can switch to a disconnected mode and back to on-line mode. The demo application monitors this event and changes its status and UI accordingly. All that is missing is the ability to query for the status of the network on start up time, and the demo application demonstrates how to do that as well.
Windows Forms requires that only the thread that created the window or control can access it. This imposes a cumbersome error prone programming model. The zip file contains a few common controls that derive from the built-in controls and can be accessed from any thread, as if no threads were involved. These control are likely to be updated by worker threads when multithreading is involved. The list includes a safe button, a safe label, a safe list box, a safe progress bar, a safe status bar and a safe text box.
This tool allows you to run an arbitrary SQL script against a SQL 2005 Express database. To use it, you provide the path to the SQL Express database (the .mdf file) and a SQL script. You can either load an existing script from file, or you can type one into the textbox in the form. The script needs to have each Data Definition Language (DDL) statement terminated by a GO statement and a line feed. When you press the Execute button, a connection will be opened to the database file and the script executed against it.
<a name="Frameworks">Visualizers are an impressive feature of Visual Studio 2005 allowing you to provide custom debug-time visualization of data types. The zip file contains three such visualizers – bitmap visualizer, RGB color visualizer and sound visualizer (nicknamed Au
Web services are tightly integrated with ADO.NET 2.0 type-safe tables and data sets. The tables are serializable, not just type safe. It is possible to load and store an entire type-safe datasets using web services. This demo provides all that, including XML conversion of the dataset, and a Windows Forms test client that presents the remote dataset, allowing the user to update and store it using the web service.
The demo shows how to send messages from a Windows Forms application to another Window, and how to intercept Windows messages in a Windows Forms app. These techniques are especially useful when interacting with legacy Windows applications.
This sample includes a Visual Studio 2005 Add-in project that creates an Add-in that makes designing Windows Forms much easier. When you design a form, you drag and drop controls on the form from the Toolbox, and then you have to go select each one and set its properties. You end up setting the (Name) and Text properties for almost every control on the form, but doing so requires a lot of mousing around to select the controls, then the appropriate property in the Properties window, and then you repeat over and over for each control. With this add-in, you just bring up the Control Decorator, and you can rapidly set the (Name) and Text properties for each control on the form through rapid keystroke entry. The readme file in the project direct
By default, every time a Windows Forms application starts, .NET launches a new process. This utility contains an alternative Application object which enables a singleton application - if an instance is already running, it ignores the request to create a new instance. It also uses a .NET 2.0 named pipe channel to restore the existing window.
A collection of IDesign’s helper classes and utilities for Windows Forms, including: BackgroundWorker for .NET 1.1, custom security controls wrapping ASP.NET 2.0 security providers and matching custom principals for any custom credential store, safe controls that can be called by any thread, a singleton Windows Forms application, network connection utility for disconnected applications, EventsHelper for safe synchronous and asynchronous event firing, visual events base classes, splash screen and imported functions from Win32 API, useful when interoperating with legacy applications.
In C# 2.0, the Array class and List<T> come with built-in generic methods to easily manipulate and streamline the underlying data structure, there is no such support available for any other collection, such as Dictionary<K,T> or LinkedList<T>.
In C# 3.0, the LINQ infrastructure adds that and much more for virtually any collection.
The demo contains a utility static class called Collection, that similar to Similar to Array and List<T>, uses the same generic delegates to offer a comprehensive set of helper methods, and not only that, Collection adds many of the LINQ features to mere C# 2.0 applications.
When publishing events in C#, you need to test that the delegate has targets. You also must handle exceptions the subscribers throw, otherwise, the publishing sequence is aborted. You can iterate over the delegate’s internal invocation list and handle individual exceptions that way. The zip file contains a generic helper class called EventsHelper that does just that. EventsHelper can publish to any delegate, accepting any collection of parameters. EventsHelper can also publish asynchronously and concurrently to the subscribers using the thread pool, turning any subscriber’s target method into a fire-and-forget method. EventsHelper also marshals the callbacks correctly to a Windows Forms client, and best of all, it can be type safe as well.
The Array class offers numerous generic static methods that automate and streamline many common operations on arrays. The methods are especially handy when combined with anonymous methods, as shown by the demo.
This console application demonstrates reflection of a generic type. The application reflects the name of the bounded type and its bounded generic type parameters, as well as reflecting the unbounded types with the generic type parameters.
This demo is a micro-benchmark application, which executes a stack in a tight loop. The application lets you experiment with value and reference types on an Object-based stack and a generic stack, as well as changing the number of loop iterations to see the effect generics have on performance.
.NET Events are method based. If you want to subscribe whole interface, you have to subscribe multiple times, once per method, and you are coupled to the publishing class' event member variables. The zip file shows how to subscribe interfaces instead of individual methods, and how well-encapsulated the publishing class becomes as a result. It also approximates the Indigo callback programming model.
<a name="CSharp">C# 2.0 makes it trivial to implement and support the iterator design patter using the yield return statement. The demo application shows how to use this feature to support iteration over a generic linked list. It shows how to correctly implement IEnumerable<T> by delegating from the non-generic base interface to the generic interface, and it also shows what will be involved in implementing the same iterator manually.
The List<T> class offers numerous generic methods that automate and streamline many common operations on list (similar to the static methods of the Array type). The methods are especially handy when combined with anonymous methods, as shown by the demo.
The My class in VB often simplifies and streamlines many operations, from Network programming to clipboard, to audio access, and so on. What takes sometimes a programming fit in C# can be done in one line using the My class in VB. If VB has Me and My, then C# should have this and That. The That class is the C# equivalent of the VB My class. It is a static class that uses the VB implementation as much as possible, and it requires adding a referencing to Microsoft.VisualBasic. The That class is instrumental when working in heterogeneous environments and when dealing with in porting of VB to C# or visa-versa.
The C# 2.0 Iterators feature shines especially when it comes to implementing an iterator over a recursive data structure such as a binary tree. The demo shows a simply binary tree that supports IEnumerable<T> using recursive iteration.
This tool allows you to easily set up a custom build event to shut down Enterprise Services server applications and remove all their components as part of a development build process in Visual Studio. Using this tool as a pre-build event for an Enterprise Services class library project, in combination with additional post-build events to re-register the assembly and components will help you have a smooth, repeatable build process for developing Enterprise Services applications.
.NET Enterprise Services provide a mechanism for loosely coupled event subscription and publishing. This mechanism relies on COM+ events, not on delegates, and it improves on many of the delegate model shortcoming. This sample demonstrates persistent subscribers.
.NET Enterprise Services provide a mechanism for loosely coupled event subscription and publishing. This mechanism relies on COM+ events, not on delegates, and it improves on many of the delegate model shortcoming. This sample provides transient subscriber support, something that does not exists in .NET out of the box. Any class (not just a ServicedComponent-derived class) can be a transient subscriber. In addition, the demo uses generics to enforce type safety with the subscribers.
The installer is a utility that automates a clean installation of your serviced components. You will need to add it to a setup and deployment project so that you can create an MSI to deploy all your serviced component class libraries to a server and get them registered in the GAC and pre-registered with COM+ in one easy step. The enclosed zip contains the installer class that you add to each ES class library project and a short set of instructions stepping you through the creation and configuration of the Setup and Deployment project to create the MSI.
The Enterprise Services logbook is a comprehensive logbook for serviced components. It logs almost every aspect of the invocation, such as location, types, methods, serving as your Enterprise application flight recorder. The logbook logs into SQL Server, and it supports both in-line logging and queued logging (first to MSMQ then to SQL server). You can also use it to manually add entries to the logbook. The logbook can be set up to be in a separate transaction and in a separate process.
Allows a non-serviced component to act as if it is in a transactional context, by introducing a middleman that creates components for it. Without it, the semantic of the transactions created will be wrong, and often deadlocks will happen. This is one of the ways you can approximate TransactionScope in .NET 1.1.
Web services are tightly integrated with Enterprise Services. Web methods can be the root of a new transaction, even if the web service is not a serviced component. The app demonstrates a transactional web service.
A set of helper utilities including a base class for a service, a base class for a data access component, a transaction context object, transient subscription manager, event class filter, and unified security principal.
Both Internet and Intranet applications often require a custom store for user accounts and roles. ASP.NET 2.0 provides an out-of-the-box provider model as well as a SQL Sever database just for that propose. Unfortunate, the only way to administer the credentials databases is via Visual Studio 2005, and only for local web applications. This download is a full-blown custom security management application that administrators can use. The application presents a rich user experience, and can administer the store remotely. The application wraps the ASP.NET 2.0 providers with a web service and even adds missing features. The zip file contains the Credential Manager smart client, the CredentialsService web service, and a help file.
Using the ASP.NET 2.0 security credentials store, you can authenticate the credentials of callers to your web service using a dedicated log-in method, and even provide a log-out method. The zip file contains a base class you can derive from, which defines these methods, installed a principal, and records the fact the caller is authenticated. You can even use the standard PrincipalPermission attribute to insist on authentication for sensitive methods. The zip contains a test client as well.
You can store custom credentials in the ASP.NET 2.0 database, and then use SOAP headers authenticate calls to your web service. The demo shows how to use SOAP headers for authentication, and it contains a test client as well.
When using SOAP headers for authentication, you pay the overhead for authentication in each call. This demo shows how to use cookie to record the fact the caller is already authenticated, and it contains a test client as well, and doing all that while using the built-in security store of ASP.NET 2.0.
<a name="Security">A custom .NET security principal that retrieves the role-based security information from the COM+ catalog. This allows even non-serviced .NET components to take advantage of the COM+ explorer to configure roles. The custom principal can use COM+, .NET or both for roles information (look both in the COM+ catalog and in the Windows groups for a match). Using the unified security principal requires only adding a single line of code to your application Main(). The zip file contains the custom principal, a client project and an MS
This demo application shows how Windows Forms application can take advantage of the ASP.NET 2.0 credential management store and provider model. It contains the AspNetLoginControl – a custom Windows Forms control that authenticates users directly against the ASP.NET 2.0 configured credentials store in SQL Server 2000. It also installs custom security principal that authorizes users against the roles in the database, and enforces authorization. The application provides the login dialog and other controls such as a log in status bar. The application also contains a custom code-access security permission set that should be granted to the application under partial trust.
This demo application shows how Windows Forms application can take advantage of the ASP.NET 2.0 credential management store and provider model. It contains the WSLoginControl – a custom Windows Forms control that authenticates users using a web service that wraps the ASP.NET 2.0 credentials store in SQL Server 2000. Doing so caters for partial trust deployment, because the web service does not flow the server-side security demand to the client. The web service can be used by any number of applications, and the applications can in turn consume any web service that supports the same interface for credentials management. The log-in control also installs custom security principal that authorizes users against the roles in the database. The application provides the login dialog and other controls such as a log in status bar. The Visual Studio 2005 also contains the required security permissions when deploying the client app using ClickOnce.
If the callers to your web service have Windows accounts, you may want to impersonate them. This demo shows the required steps: it logs on the caller, impersonates it, and attaches a custom principal for the HTTP context and the thread with the new identity. Once the call returns, the identity is reverted. The zip contains a test client as well.
You can approximate .NET 2.0 TransactionScope using Service Domains. This provides you in .NET 1.1 the superior programming model of .NET 2.0 and Indigo. Note that the approximation only works on Windows 2003 Server, or on Windows XP Service Pack 2, and that it does not support promotion (always uses the DTC). Given those prerequisites, you can start using TransactionScope in .NET 1.1, and make a seamless transition into .NET 2.0 in the future.
.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.
System.Transactions allows you to combine the work of multiple threads in a single transaction. You need to provide each worker thread with a clone of the original transactions, and signal to the original client thread when the worker threads have completed their work. This application demonstrates this complex topic and a few related issues such as passing the transaction between threads and synchronizing access to state.
A sample custom context attribute that lets you extend a .NET context. This sample adds a color attribute to a .NET context. The zip file contains a comprehensive demo client with graphic illustrations of the actual activation context.
In .NET, you can bounce a call from one thread to another using synchronization context. The canonical example is when updating user interface (such as Windows Forms) from a worker thread, since Windows Forms has its own synchronization context. But the synchronization context is a general-purpose mechanism, used whenever an affinity to a particular thread or a group of threads is needed. While using a synchronization context is straightforward, developing one requires some advanced .NET programming. The download contains two custom synchronization contexts- one used to establish an affinity to a custom pool of thread, that is, the calling thread can bounce the call to the custom pool, and the second synchronization context is used to estab
You can use context and interception to provide for declarative transaction support for context bound object, ala ServicedComponent, yet without Enterprise Services. The demo application installs a transnational message sink, that uses TransactionScope to ensure that the rest of the call chain down stream is transactional, and a demo client and server.
This is a full-blown back up utility, which 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. The application updates the Windows Forms controls correctly on multiple threads using IDesign's dedicated controls.
This demo uses GenericSerializationInfo – a wrapper class around SerializationInfo, because SerializationInfo was designed without generics in mind. GenericSerializationInfo provides for easy, elegant and type-safe custom serialization, even when not serializing a generic type.
The IFormatter interfaces and the binary and SOAP formatters that support it were all defined in .NET 1.0, before generics were available, and as such, are not type safe. The zip file contains the definition and implementations of IGenericFormatter, a generic wrapper around the basic formatter. In addition, the demo shows how to define and use the serialization events.
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 contains 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. The demo uses IDesign's SponsorshipManager utility to manage the sponsors. SponsorshipManager is a generic implementation of a client –side object that manages all the sponsors for the client. The Sponsorship Manager unregisters itself on application shutdown. It also uses a practical heuristic to correctly renew the leases.
When using remote events, the roles are reversed: the server becomes the client, and the client the server. There are a few configuration changes (such as type filtering) required to enable remote events, as well as user interface updates, demonstrated by this app.
The WaitHandle class provides in .NET 2.0 a set of SignalAndWait() methods that allow you in one atomic operation to signal one event while waiting on another. This is important when synchronizing execution of multiple threads wanting them to execute in unison. The zip file contains the Rendezvous class – a compound lock that allows you to do just that, and a demo application that uses it.
.NET provides support for automatic object serialization, both for object persistence and for remoting and marshaling. Objects can be serialize to either binary or SOAP format. The zip file contains a 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.
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.
The application demonstrates the new features of System.Transactions in .NET 2.0: how transaction flows between clients, services, and code scopes, how to use TransactionScope and how transactions manage consistency in the application.
.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 comes 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.
Developers often create thread or use message loops to periodically call back into their application. .NET provides 3 timer mechanisms just for this purpose. The zip file shows the correct way of using these timers, and contrasts them, all while correctly marshaling calls between threads.
Transactional programming has traditionally been the privilege of database-centric applications. Other types of applications did not benefit easily from this superior programming model. The zip file contains a generic resource manager called Transactional<T> that enables you to transact any type, from integers to strings to arrays. In addition, the zip file contains transactional version of all the generic collections in .NET 2.0, such as TransactionalList<T> and TrasnactionalArray<T> that are used just like their predecessors but with the added value and protection of transactions.
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. It exposes only the good methods of the thread class and disallows the bad. It also allows you to wait on the thread handle for termination, something the basic thread type does not. Once expanded, you will have a Visual Studio solution for the WorkerThread class and a test client, as well as XML-based documentation.
This Excel spreadsheet enables earned value technique for both project planning and project tracking.
The technique is covered in this webcast: http://www.msteched.com/2010/NorthAmerica/ARC201?webcasts/Planning and Tracking.wmv
The IDesign Method has three elements: it is a method for decomposing a system into modules or services based on the system top-level uses cases, the IDesign Method offers a set of very simple design notations to capture the design decisions, and the Method is a near-mechanical approach to automating the design decision of rarely discussed topics such as allocation of services to assemblies, allocation of services to processes, transaction boundaries, identity management, authorization and authentication boundaries, synchronization and more.
Similar to queued calls over MSMQ, by default, there is no way to get results or errors out of a call to a buffer. The demo shows the IDesign helper classes that solve that by providing a response buffer for the service to respond to. The IDesign framework automates passing the response buffer and the individual calls IDs in the message headers, as well as creating host, proxy, and a proxy to the response service. It yields the same programming model exactly as with the MSMQ response service.
The default programming model of the service bus buffers is to interact directly with raw WCF messages. The result is a cumbersome, tedious, non-structured, non object-oriented and not type safe programming model. The demo shows the IDesign framework for a structured, type-safe programming model over the service bus buffers. A dedicated host and proxy classes allow you the same programming model as with regular WCF, while the calls actually go to and from the service bus buffers. The framework uses some advanced WCF techniques, such as converting raw WCF messages into calls on a WCF channel.
Similar to the attribute-based declarative security for regular WCF, IDesign provides support with the SecurityBehaviorAttribute for the service bus. The attributes defaults to anonymous message security, but can be configured for having credentials as well. No other transfer security configuration is needed.
The NetTcpRelayBinding supports duplex callbacks through the service bus. Setting up the duplex calls, accessing the callback reference and all the other details of the duplex callbacks are identical to the regular TCP binding. Presently, NetTcpRelayBinding is the only relay binding which supports duplex callbacks.
<a name="ServiceBus">When securing a service bus call with the NetOnewayRelayBinding (and the NetEventRelayBinding), as with the other bindings, you can use transport or message security. Unlike the TCP or the WS relay bindings, using message is sufficiently different, because the is no certificate negotiation. You will find here several ways of configuring end-to-end security with the oneway relay binding: transport security, anonymous message security, and message security with username credentials as Windows credentials or as ASP.NET providers. you will also see the IDesign helper classes that streamline the client and the host side.
A collection of demos showing many ways of configuring transfer security with the NetTcpRelayBinding: transport (the default), anonymous message security, message security with user name credentials as Windows credentials, message security with user name credentials as ASP.NET providers credentials, message security with certificate credentials, and mixed transfer security, both with interactive and alternative Windows credentials. In addition, there are several demos showing the IDesign helper classes and base classes that automate configuring message security both for the client and for the host.
The WS relay binding (WS2007HttpRelayBinding) only supports Transport and Mixed (TransportWithMessageCredentials). It does not support Message security. This is a collection of demos showing several ways of configuring transport security, mixed transfer security, both with interactive and alternative Windows credentials. In addition, there are several demos showing the IDesign helper classes and base classes that automate configuring security both for the client and for the host.
When configured with TcpRelayConnectionMode.Hybrid, the service first connects to the relay service and then the client connects. However, at this point, the relay service will promote the connection to a direct connection between the client and the service, by telling the client how to reach the service directly, allowing the client to continue calling the service directly. The hybrid mode should be the preferred connection mode of NetTcpRelayBinding. However, it has one drawback: it requires the binding to use Message security which requires additional configuration and setup. The demo shows the IDesign extensions that automate and streamline hybrid configuration.
When using the NetEventRelayBinding, you treat the service bus as an events hub, rather than a mere relay service. However, out of the box, there is no support for subscribing for discrete events, and the subscribers receive (and pay!) for all the events, even those they do not care about. This demo shows the IDesign helpers classes that enable a sophisticated publish-subscribe patter with support for discrete events. There is a dedicated host type and a proxy class, complete with message security.
This demo shows how to use the service bus to distribute events (with the NetEventRelayBinding) and have the events update some user interfaces. It uses the IDesign FormHost<F> as well as extensions for security.
The .NET Service Bus service utilizes the Access Control Service (ACS) of the Windows Azure AppFabric platform to authenticate its callers. The client and the service need to present a security claim issued by the ACS. The service host must always authenticate, and so does the client (by default). However, the host may exempt the client from authenticating. This is a collection of several demos showing service bus authentication: how to provide the ACS shared secrete programmatically, how to provide the shared secrete in a config file, how to configure the host and the client to exempt the client from authentication (both in the behaviors and in the binding). The demos also contains the IDesign helper classes and extensions that greatly sim
When using the NetEventRelayBinding, you treat the service bus as an events hub, rather than a mere relay service. This demo shows how to use the service bus to support a simple publish-subscribe pattern. It is simple, because the subscribers have no way of subscribing to discrete events.
A simple demo showing that the NetOnewayRelayBinding works well in an unknowns service state, that is, the service may or may not be running, and that there is never a transport session with the service instance (unless a singleton), every call always gets a new instance.
An important tools that takes off the blinders when using the service bus. The tool visualize your service bus assets, both services, subscribers and buffers. The tool accepts the service namespace to explore, and after logging in to the feed will visualize for you the running services. All the explorer does is parsing the ATOM feed and placing the items in the tree to the left. You can explorer multiple service namespaces, and see in the right pane your Windows Azure AppFabric platform service bus administration pages.