A Developer's Notes

Useful tips when using Patterns and Practices Component Application Block (CAB)

MSDN Archive — Mon, 08 Jan 2007 18:41:00 GMT

The CAB is an excellent resource for application development. With the proper techniques, it leads to clean, separated logic and definite, manageable layers of code. However, there is one problem: little documentation. With the Smart Client Factory, more example code has been added, and there is more guidance. I thought that I would make a running list of the little problems I have found and solutions that I discovered. I hope these are useful, because I have not seen any other listing with answers to these "basic" scenarios that seem necessary. The documentation would be better with an extensive FAQ regarding issues like these.

1. How to create a modal dialog:

Suppose you have a workSpace already defined (like a TabWorkSpace). Inside of a WorkItem, in the Run(IWorkspace workSpace) method, create a new workspace of type WindowWorkSpace and using a WindowWorkSpaceInfo, set the value for modal to be true. When you call the Show method, you'll see a new, modal window appear:

windowWorkSpace.Show(smartPart, workSpaceInfo);

2. How to close a window:

Calling Deactivate() on the WorkItem only makes it not the active work item. You need to do this from a WorkSpace method, assuming you only have one SmartPart:

this.WorkSpaces[ myWorkSpaceName ].Close( this.Items[ mySmartPartName ] );

Once all SmartParts are closed, the Workspace closes and then the UI window associated will go away if there are no more work items.

3. How to correctly use the Event notification mechanism

You need to make sure that you use prototypes that follow this general pattern:

public class TestStatus : EventArgs

{

}

public class Test

{

[EventPublication("event://Status", PublicationScope.WorkItem)]

public event EventHandler<Status> StatusNotification;

}

[EventSubscription("event://Status", Thread=ThreadOption.UserInterface)]

public void myClass_NotifyOnStatusChange(object sender, Status test)

{

}

Otherwise the event system will complain if the type of the event arguments involved to not have the correct parent class types.

4. Serializing a set of work actions

Normally a UI has a flow, where the user does a task. First selecting files, then clicking a button and then a dialog pops up. Well, how do I chaing work-items together to make a coherent use-case for the user? That's easy: using a WorkItem, create a new work item that gets added to the WorkItems property. When the child's Run(IWorkSpace childWorkSpace) method is called, the parent WorkItem gets deactivated and the child "gains the focus" of the application.

class MainWorkItem : WorkItem

{

public void Run(IWorkspace tabWorkSpace)

{

currentWorkSpace = tabWorkSpace;

loginWorkItem.Run(currentWorkSpace);

if (loginWorkItem.LoginInSuccess == false)

{

loginWorkItem.Terminate();

return;

}

SelectorWorkItem mainWorkItem = Parent.WorkItems.AddNew<SelectorWorkItem>();

mainWorkItem.Run(currentWorkSpace);

}

5. Making data available from one WorkItem to its aggregate members

The members of WorkItems' collections (called Items[]) can receive references from their parent work items using declarative or programtic methods. These members can be presenters, smartparts or any other object that is related to the WorkItem. The items in the State or Items collections are available to the children WorkItems using the following declarative syntax, and the values are applied when the child objects are added to the Item collection (via Add() or AddNew())

[State("myStateName")]

public String StateValue

{ set { this.myVariable = value; } get { return this.myVariable; }

[Dependency]

public MyClass MyClassInstanceProp

{

set { this.myVariable = value; } get{ return this.myVariable; }

}

When either of theses methods are declared, they are used at run time to fill in the values of the Properties with the values contained in the corresponding objects help by the parent's WorkItem.

This same technique works to pass information from WorkItems to the instances that are contained in its WorkItems collection, when creating a child WorkItem from inside the context of the parent WorkItem. Note that the Items[] and State[] collection is not shared amongst WorkItem instances, but is used by the ObjectBuilder to set the appropriate properties.

6. Sharing data amongst all WorkItems, or pushing data up from a child WorkItem to a parent

When you create an object instance and add it to the Services collection of the parent WorkItem, it will be available to all the WorkItems below that WorkItem. This provides a convenient method of passing data back up from a child WorkItem to a more upper layer, by using a stateful Data Transfer Object.

You can automatically get a reference to this service by using the following declarative example:

[ServiceDependency]

public IWorkItemTypeCatalogService myWorkItemCatalog

{

set { myCatalogService = value; }

}

7. Using a specific instance of an object to meet a dependency on an abstract interface

If we register a concrete object that implements an interface, we would like to use that instance when a specific dependency on that interface is specified. By default, since the types are not the same, the existing object will not be used. That is, as below, the ObjectBuilder will look for an object of type ITestSelectorView, and find none, even if an instance of a specific object exists that satisfies this requirement. In this case, the name for for the instance is just for convenience, and is not needed.

[DependencyAttribute(NotPresentBehavior= NotPresentBehavior.Throw, Name= "InstanceName")]

public ITestSelectorView ISelectorView

{ set { myView = value;} }

But, if we add this code to the WorkItem that creates the object, we can make sure it picks the correct instance, which implements the interface:

this.InnerLocator.Add(new DependencyResolutionLocatorKey(typeof(ITestSelectorView), "InstanceName"), concreteObjectInstance);

This is very useful for making use of concrete instances to fulfill abstract requirements, and it is not overly complicated.

8. Deactivating one WorkItem so that a new WorkItem will appear

If you activate the SmartParts in a different WorkItem, the current active WorkItem will be made inactive. This is the primary way in which a use case works, from one WorkItem to the next. To stop using a WorkItem and make it disappear (useful in the case of a modal WindowWorkSpace) you can call the Terminate() method of the related WorkItem.

9. Using the State collection sparingly (to avoid writing Property accessors that cast the results accordingly)

You can encapsulate the WorkItem state within a separate class which can then be used to read and write important state variables from (without having to directly use the State collection). This class then can be written to the State collection to make use of the StatePersistence service, without the overhead of having to use the State collection for every instance data member. Since the presenter contains the presentation state, the WorkItem should contain the business logic state.

The alternative is to create a property that returns the correct type once the object instance is retrieved from the State collection. This can get rather annoying quickly, and collapsing the related state into a single class is a more clean alternative.

10. Getting more ideas for using the correct patterns in your design .....

Look at the sample application, especially in the Smart Client package from the Patterns and Practices group, and look for more rich sample applications that illustrate different models or outlines which can make for consistent designs. The best way implement an application is to have all of the patterns established so that the implementation will be internally consistent.

This is one example: https://www.ideablade.com/cabana/cabana.html?=msp&p

Making WiFi secure for shared use

MSDN Archive — Mon, 08 Jan 2007 18:27:00 GMT

WiFI Hot-spot Security: Accessible and secure

The only real answer to creating a secure hotpot is via a VPN solution. There are few other alternatives which make any sense, and none of which have been widely adopted. The problems have to do with disparte WiFi technology and non-existent standard provisioning policies or protocols to deal with this and to manage this domain.

First, not all WiFi hardware has been created equal and not all WiFi security protocols are created equal. WEP is not secure and should not be used, unless backed by a layer-3 security, like IPSec and a frequent re-authentication coupled with a station-unique encryption key and IV. Only enterprise hardware is capable of meeting these requirements, and they are not suitable for a consumer-grade network like a hotspot.

WPA2 (802.11i) is the only security that can be used on a network, however, in order to authenticate with WPA, you either need a key (WPA-PSK) or to use one of the 802.1X authentication methods, which then becomes more complicated: not every OS supports the same authentication methods. Microsoft favors PEAP-MSCHAPv2, which is a doubly-secure user-name/password authentication protocol. However, this is only one step of a sign-on process; first the user must acquire (purchase) credentials, etc. which must be done using a connection. But first, if 802.1X is to be used, a common method must be found, and it must be integrated into the sign-on process. One common protocol is EAP-TLS, with a competing EAP-TTLS, but these rely on certificates, which only complicate matters. Using certificates is way more trouble than it is worth, even for the enterprise. In fact, Windows Vista now defaults to attempting PEAP-MSCHAPv2 first, because people have moved away from certificate-based authentication due to the complexities. Certificates just make things more complicated.

So, when someone wants to connect to your hotspot, how does it work? First, they must be able to connect, so the network must be Open. Then, usually, the hotspot redirects all incoming HTTP requests to their sign-in machine, protected by SSL, to allow for client to sign on and receive access. Now what? They are given access and begin to surf the net on an unsecure network. That's not a good idea.

Under a Microsoft technology called WPS (Wireless Provisioning Service), a provisioning client downloads information from the secure HTTP server during a simple authentication phase (in which the server is authenticated, and the client uses default credentials) and facilitated the connection in such a way as to provision the client to securely connect with the correct PEAP-MSCHAPv2 authentication strings (a customer-specific username and password) once sign-up was finished. Also, this connection would then work with partner hot-spots, where the credentials would also be accepted. It is a cool technology built into every Windows XP SP2 installation (now almost the entire world), allows for secure access and has a good license for other adopters. Unfortunately, uptake was slow and this technology was removed from Windows Vista except for the ability to provision a machine with profiles. Why was this so difficult to get people to adopt?

Mostly because WiFi networks are part of a larger eco-system and the technologies are disparate and everyone likes their standard. People don't want to use your protocol; they want to use their own, and it has to work with the mobile devices, mobile phones, etc.

This is why there are no elegant solutions- because the elegant solutions don’t work for everybody. The best solution is the typical open-none hotspot (accessible to everyone) with a HTTPS sign-in page and a VPN connection for security (like Open VPN, but facilitated by the hotspot). Too complicated? Unfortunately, there are no good alternatives. This is just one case of the technology getting ahead of the community collective thought process.

However, I still thing that Microsoft’s solution IS very elegant, and would be an excellent choice. Plus, is allows for a custom sign-on process that allows for support information, and a standard user-experience.

An .NET archival tool using Serialization and Compression/Encryption IOStreams

MSDN Archive — Tue, 05 Dec 2006 19:32:00 GMT

Recently I was looking at writing a file archival, encryption and compression utility in managed code. Since I didn't want re-invent anything, I wrote a simple pipe-line framework, where each section uses the output of the previous stage's stream. The head file stream is then used for any read or write IO. Each stage is configured to decrypt/encrypt, compress or expand, depending on the direction of the IO (read, or write).

FileStream <-- CompressionStream <--- EncryptionStream (Head, writing)

FileStream --> DecompressionStream ---> DescryptionStream (Head, reading)

This is all very simple, and works like a command shell IO pipe. I can write data to the top of the stream and it filters down to the bottom layers, where it eventually ends up in the file system (or in memory). When I was done, I thought it might be interesting to share regarding how .NET serialization can be combined with the IOStreams to make some cool technology with little work.

The component I specifically needed was an archiver, like TAR, plus the other pipeline stages that I use on my command line on my Linux box (gasp!)

tar cf - * | gzip -c > tarfile.tar.gz

Since the .NET Framework already offers serialization, I decided to extend that to serializing objects that represented the files, using serialization. Lets not exaggerate; TAR is much cooler than anything I wrote (and is much harder to use). But since Microsoft doesn’t supply a nice managed/unmanaged archiving tool, and WinZip is not on my test machines and doesn't offer encryption, I figured it would be faster just to write one, with the added bonus that I could make it do custom actions by plugging in different stages.

By creating a class that encapsulates the file's full path, file name (in this case only part of a file's data, not including alternate streams, or ACLs), and data, we have a simple archiving mechanism. You need to write some code that is trigged by the OnSerializing attribute and the Deserialized attribute: to read in the file data (into the fileData member) from the correct file, and then to write it out to the newly created/over-written file upon deserialzing (unpacking the archive).

[Serializable]

public class FileArchiver

{

private String fileName;

private byte[] fileData;

...

}

The archive is simply a serialization of a List instance, which contains all of the data stored in the respective files.

List filesToAddToArchive;

serializer.Serialize( stream, filesToAddToArchive);

Make sure you use the BinarySerializer, for smaller file sizes and faster archival run times! XML is cool, as cool as UTF-8 can be, but way less efficient as opposed to binary formats. I once timed the difference between a binary protocol and XML-based protocol. I think there was a 1000% difference in there transaction times. XML processing is slow, even if writing the wordy output is not necessarily much slower.

Now, what about encryption? Asymmetric encryption was important for the application, since using a shared key is less secure, and for my application I wanted to use simple RSA keys, as opposed to using certificate. These keys are usually expressed as two parts, a public and private key, and stored in a file, or a Windows Key Container (more secure). To do the actual encryption, the encryption method generates a temporal key, which is then used to encrypt the data. This key is then itself encrypted via the public part of the key, and embedded into the file, or sent apart.

In the application we want to encrypt in-line, meaning by only processing the file once. Plus this is a pipeline, and it must read and write in one go, and we are already using serialization to serialize the file archive. So logically we need to serialize the encrypted key as well.

In the case of archiving, upon initializing the encryption stage reads in the RSA public key and it writes out the temporal key from the symmetric encryption method. This key is used later in the symmetric encryption of the actual data, and you can use any symmetric algorithm you like here. The standard for symmetric encryption is AES, which is required for all government and hospital IT systems, at least in the US. I believe that this will become part of a larger standard as well. RijndaelManaged is the .NET implementation and it is definitely the symmetric algorithm to use. If you are doing any serious encryption, use a 128- or 192-bit key as well.

So, if we encrypt the temporal key and Initialiation Vector (IV) with the RSA public key, we can serialize this data into the file stream as well, using the same mechanism. Here is our simple property-bucket class to hold these two byte arrays:

[Serializable]

class EncryptedSessionKey

{

public byte[] encryptedKey;

public byte[] encryptedIV;

public EncryptedSessionKey() {}

}

Then we can start writing the rest of the data to the archival data stream; and now that the encryption module had written out the encrypted key header, it will not encrypt the data written through it, and thus the output file looks like this, with two sections, each a sort of convolution of the sum of the steps. This includes using the compressor pipeline stage, which is more obvious:

Compressed [Serialized EncryptedSessionKey]]

Compressed[Encrypted{Serialized List}

Cool serialization trick, certainly not novel, but still interesting. Make sure you configure the symmetric encryption to use padding for writes that do not follow block sizes, otherwise you may not be able to write the encrypted data. By default, I believe a padding format is enabled.

The reverse of this process has exactly the same steps, and the only difference is that the objects are deserialized and each pipeline is configured to do the reverse of what it was doing before.

.NET Enumerators vs. STL- STL.NET is still not released

MSDN Archive — Sun, 03 Dec 2006 18:44:00 GMT

As a frequent STL user, I can say that iterators are indispensable, but often an Achille's heel for those new to STL. It is easy to use iterators incorrectly, such as by not obeying the conventions, or modifying the collection in an inobvious way such as to invalidate the iterator.

One common STL problem is deletion, in this case, if the last element is deleted, the iterator it be moved beyond the end of the collection. This is a typical beginers mistake; the STL environment provides for an implementation of this algorithm that correctly deals with the iterator (using a while loop). Beyond that, STL is just a little more complicated for the uninitiated, but Iterators are not the most complicated part, and they are generally easy to use and straightforward.

for (it = collection.begin(); it != collection.end(); it++)
{

if ( (*it).BoolMethod() )
it = collection.erase( it );

}

Sadly, .NET's Enumerators are a far cry from STL's and they leave us with much less control or power. Inorder to reverse traverse a collection, you either must reverse the collection (an O(1) operation) or simply write a different loop with an index that moves through the elements in reverse (as opposed to a reverse iterator)

for ( int i= collection.Count-1; i >= 0; i--)
{
// Do work
}

"i" in this case is a fairly poor iterator. This is a concrete value that defines the boundaries of a class, and is not an extensible object.
The advantage is that this is much more understandable to the VB user; Iterators and Generics are much more complicated. It is something that happens in the .NET space; the interface speaks to the average developer, not the C++ developer. Or the Java developer.

On the other hand, less power means fewer bugs! During a discussion with a co-worker, it was pointed out that adding more complicated features would increase the number of bugs. In the practical sense, this is true; if you have no features, there can be no bugs. But finding the mid-point between useful features and unneeded complexity is important, and you need to consider the people who will use them is another.

STL.NET (STL/CLI) Preview release (Sept. 2006) for use with the pre-release of VS 2005+1 ( called "Orcas", which is the next release of Visual Studio).

STL.NET Release announcement
https://blogs.msdn.com/nikolad/archive/2006/09/30/STCLRinOrcasSeptemberCTP.aspx

STL.NET Primer

https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvs05/html/stl-netprimer.asp

ClickOnce problems: Windows Authentication and the ClickOnce boot-strapping process

MSDN Archive — Fri, 01 Dec 2006 14:34:00 GMT

I was testing my "Hello World" application today and validating that it worked correctly with the ClickOnce deployment tools and with our SharePoint setup. The requirements of the final application include that it be launchable from external partner sites and via a secure SharePoint site (over HTTPS, using NTLM authentication). I discovered that this is not a well-covered scenario and the ClickOnce works only for users logged into domain account (on domain-joined machines), and in some cases, when they are in the same enterprise (domain forest). This really surprised me. And the latter issue also blocked me personally as well from using my test "deployment" because of the peculiarities of my own domain account and the group I am currently working in. I'll explain the problem below ...

After reading the MSDN articles, I found out that ClickOnce only supports NTLM "Windows Authentication" when using HTTP/S. This means that no other authentication methods will work, except for no authentication. Furthermore, the default Windows log-on credentials are used. If the HTTP/S request fails, then the "boot loader", which handles the downloading and initialization of the application, fails.

There are two situations in which this does not work: the first is where the user is not logged into a domain account, and has opened the application's deployment URL via Internet Explorer. IE will graciously ask for difference credentials if the default ones do not work. The ClickOnce bootloader is not so intelligent, at least in .Net Framework 2.0. So the application manifest is visible to the user in IE, but not to the ClickOnce bootloader.

The second situation is if your domain credentials are for some reason not good enough. There are cases where the domain needs to be fully specified for the authentication to succeed. For example, I may log in as DOMAIN1\Brian, but in order to properly authenticate with the server, I need to provide my name as brian@DOMAIN1.subdomain.mycompany.com, giving the fully qualified domain name. Why is this? I have not bothered to find out, it is some problem with how the domains authenticate with each other. However it is definitely annoying and does not seem consistent.

To summarize these limitations let me say that ClickOnce will work in the following cases: no authentication, custom application authentication (not officially supported) or NTLM authentication. I was really disappointed by this because in my situation, there is no work around. The users will not be using domain joined machines, and I cannot give open access to the SharePoint deployment site due to IP requirements and company policy (obvious). Likewise, custom authentication methods (or the HTTP proxy solution suggested by the article) are just not adequate. Anything non-standard or less than secure is just not an answer to be considered.

The article below talks about the authentication mechanisms used and possible work-arounds to authentication issues:

https://msdn2.microsoft.com/en-us/library/aa480721.aspx

For now, I'm going to have to deploy my application as a traditional MSI package and implement an updater to keep the client machines up to date as new versions of the software package is created. This will probably involve using the Updater Application Block.

Patterns-based frameworks for .NET

MSDN Archive — Fri, 20 Oct 2006 12:56:00 GMT

With the first major project that I worked on .NET for a private company, I realize that we would have benefited from having richer, deeper patterns for doing the development that would have served as a guideline when trying to tackle such important issues as testability and maintainability. In .NET, many programmers are coming aboard from the Visual Basic camp and are therefore using the same programming methods as before, without the advantage of patterns-based design with specific, goal orientated designs (testability, componentization, ease of configuration, for example).

This leads to VB6-style programming in the modern environment of .NET 2.0; the quick and dirty apps, some simple and fast data-binding vis a vis a few clicks, and then done. This works fine, up until a certain point, which is usually the dividing line between a small project with a short life span and a large one. Visual Studio for .NET started off better than Java’s initial offerings and has offered better WSIWYG graphical builder, which is a real seller for doing quick work, part of the reason VB6 became so popular. On the other hand, Java has a head start design-wise on .NET with their Swing toolkit, and the accomplished programmer steeped in more enterprise-grade development will probably find themselves more at home in a Java environment than in a .NET one, at least as far as User Application programming is concerned.

The Microsoft Patterns and Practices group has developed Application Blocks which provide exactly this type of rich, deep functionality that provides the basis for enterprise-class applications. Furthermore, the application Guidance Explorer brings enterprise-level intelligence to a small software firm that most shops would never have access to “in build”, along with the rest of their Visual Studio development tools. It is a great package, and freely available.

Since I’ve been working with, I’m going to be writing several articles about using different components from Patterns and Practices to create applications, and discuss implementation and design questions when using these frameworks.

You can find the home page for Patterns and Practices here:

https://msdn.microsoft.com/practices/