Wintellog

Using AppDomains to make Non-Threadsafe code Threadsafe

JeffreyR — Wed, 01 Sep 2010 20:39:41 GMT

Recently, I was involved in a Wintellect consulting engagement where a customer had some class library code that was created years ago. The code in this class library was not designed to work well in a multithreaded environment. Specifically, this means that if two or more threads called into the class library code at the same time, the data got corrupted and the results could not be trusted. Non-concurrent-ready code is easy to obtain with frequent use of mutable static fields. But, there are other common coding practices which can result in code that is not safe with multiple threads passing through it at the same time.

This customer wanted to increase the performance of their code and the best way to accomplish this is to have multiple threads processing their own data independently of each other. But, again, the class library code base would produce errant results if we did this. To demonstrate the problem, imagine this very simple static class which is indicative of the non-thread safe class library that I'm referring to:

internal static class NonConcurrentAlgorithm {

private static List<String> s_items = new List<String>();

public static void Add(String item) { s_items.Add(item); }

public static String[] GetItems() { return s_items.ToArray(); }

}

If we have two threads using this class simultaneously, the results are unpredictable. For example, let's say we have this code:

ThreadPool.QueueUserWorkItem(o => NonConcurrentAlgorithm.Add("Item 1"), null);
NonConcurrentAlgorithm.Add("Item 2");
Thread.Sleep(1000);  // To demonstrate the problem consistently
foreach (var i in NonConcurrentAlgorithm.GetItems())
   Console.WriteLine(i);

When this code runs, the console could show:

"Item 2" by itself
"Item 2" followed by "Item 1"
"Item 1" followed by "Item 2"

Clearly, this is not desireable and the problem all stems from the threads sharing the one List<String> object. In fact, the List<T> class is not itself thread-safe and so it is even possible that having multiple threads accessing it simultaneously could result in items disappearing or a single item being inserted multiple times, or worse. It depends on how the List<T> class is internally implemented which is not documented and is subject to change.

Now, one way to improve performance for the customer would be for Wintellect to take the non-concurrent code base and make it thread safe. This is the best thing to do; however, the code base was very large, the changes to the code base would have been substantial and a lot of testing would have had to be done. The customer was not too excited by this recommendation. So, what we did instead was use the CLR's AppDomain feature. This works out great because an AppDomain's state is completely isolated from all other AppDomains. To communicate across AppDomains, you must create a class derived from MarshalByRefObject. So, I created a NonConcurrentAlgorithmProxy class that wraps the methods of the static class. The NonConcurrentAlgorithmProxy class looks like this:

internal sealed class NonConcurrentAlgorithmProxy : MarshalByRefObject {

   public void Add(String item) { NonConcurrentAlgorithm.Add(item); }
   public String[] GetItems()   { return NonConcurrentAlgorithm.GetItems(); }
}

Then we modified the code that uses this class library code so that each thread creates its own AppDomain and creates an instance of the NonConcurrentAlgorithmProxy class in each AppDomain. The static field in the NonConcurrentAlgorithm class is now one-per-AppDomain and since each thread gets its own AppDomain, there is now one List<String> object per thread. Here is the new code that uses the class library code via the proxy class:

// Create Thread 1's AppDomain & proxy
var thread1AppDomain = AppDomain.CreateDomain(String.Empty);
var thread1Proxy = (NonConcurrentAlgorithmProxy)

   thread1AppDomain.CreateInstanceAndUnwrap(

      typeof(NonConcurrentAlgorithmProxy).Assembly.FullName,

      typeof(NonConcurrentAlgorithmProxy).FullName);

					
// Create Thread 2's AppDomain & proxy
var thread2AppDomain = AppDomain.CreateDomain(String.Empty);
var thread2Proxy = (NonConcurrentAlgorithmProxy)

   thread2AppDomain.CreateInstanceAndUnwrap(


					typeof(NonConcurrentAlgorithmProxy).Assembly.FullName,


					typeof(NonConcurrentAlgorithmProxy).FullName);

					
// Have 2 threads execute the same code at the same time but in different AppDomains
ThreadPool.QueueUserWorkItem(o => thread2Proxy.Add("Item 1"), null);
thread1Proxy.Add("Item 2");
Thread.Sleep(1000);  // To demonstrate the problem has been fixed

					
// Show Thread 1's list of items; guaranteed to be "Item 2"
foreach (var i in thread1Proxy.GetItems())
   Console.WriteLine(i);

					
// Show Thread 2's list of items; guaranteed to be "Item 1"
foreach (var i in thread2Proxy.GetItems())
   Console.WriteLine(i);

					
// Cleanup each thread's AppDomain
AppDomain.Unload(thread1AppDomain);
AppDomain.Unload(thread2AppDomain);

This is substantially less coding, testing, and effort than what would have been involved with making the customer's current code base thread safe! And, this technique can scale very nicely for many threads as well. Of course, there is a slight performance penalty when creating/destroying AppDomains and calling methods through the proxy. This is why it would be ideal to make the existing code base thread safe. But, this is a great compromise and the customer was quite happy with the results and the time/cost it required to improve their application's performance substantially.

Hello, MEF for Silverlight Quickstart

C#er : IMage — Wed, 01 Sep 2010 12:42:05 GMT

Published another quickstart. This is an introductory quickstart for the Managed Extensibility Framework, and is similar to the previous one except that it is specific to Silverlight. You can take a look at the article and watch the short video by clicking here ....(read more)

Zen of Paraffin

jrobbins — Tue, 31 Aug 2010 21:34:00 GMT

With Paraffin 3.5, I included this document, but thought it would be worth posting as well for those of you that aren't familiar with Paraffin. You can download the lastest release here: http://www.wintellect.com/CS/files/folders/18310/download.aspx

Introduction

When building WiX-based installers, you quickly run into the problem of maintaining the list of files you want to install. The HEAT tool that comes with WiX does a great job creating the initial fragments, but doesn't have any support for what happens during normal development: you're adding and removing files all the time. For many installs, HEAT works fine, but if you have an installer that's installing hundreds to hundreds of thousands of files, the thought of maintaining those fragments of XML by hand would fill anyone with dread.

A few years ago, I was running into that same trouble with my WiX installers right around the time .NET 3.0 and LINQ were starting their beta testing. Seeing a need to scratch my itch, I dove in and created Paraffin. The idea was simple, you could maintain your fragments without breaking component rules as files were added and removed from your installer. Paraffin has grown as more people have started using it and suggest features. Thanks to everyone who's used Paraffin!

This guide is to help you get more out of Paraffin. Obviously, it assumes you are conversant with WiX and Windows Installer. If you're new to WiX, you should head over to Gábor DEÁK JAHN's excellent tutorial (http://www.tramontana.co.hu/wix/).

TWO SUPER IMPORTANT NOTES ABOUT PARAFFIN!

The first key to maximizing Paraffin usage is that you always run Paraffin updates from the same relative directory where you first created the initial WiX fragment. For example, if you change to C:\BUILD\IMAGES in PowerShell and create the initial WiX fragment for the IMAGES directory, all updates have to be run from the IMAGES directory. You can hard code starting directory paths in Paraffin, but that will probably break your builds. By running from the IMAGES directory, you are in the same place relative to the rest of the code in your WiX project every time. This allows more flexibility.

The second key is that in Windows Installer, component rules are sacred. Paraffin works very hard to avoid issues, but if you are not careful you can make your life super difficult. This warning is mainly around patching issues. Patching is far more difficult to get right than it should be. From my experience, you would be much better off sticking to making everything a major upgrade for every install. Based on many requests, I've made Paraffin much more usable in patching scenarios (minor upgrades), but you really do need to know what you're doing and have planned your install completely.

Creating Your First Fragments

Paraffin supports three modes of execution, creating fragments, updating fragments for major upgrades, and updating fragments for minor upgrades. Obviously, you first have to create a fragment in order to upgrade that fragment.

Required Parameters for Initial File Creation

Parameter	Description
-dir <directory>	This is the directory you want Paraffin to recurse looking for files. As I mentioned previously, it's best to use relative paths here to avoid hard coded drives and directories.
-GroupName <value>	Paraffin automatically creates a <ComponentGroup> element in the output file so in your main install .WXS file you can pull in all the components easily with <ComponentRef> element.
<file>	The filename for output.

Optional Parameters for Initial File Creation

Parameter	Description
-alias <alias>	By default, Paraffin uses the hard coded full name to the file in the File elements Source attribute. The -alias option allows you to substitute a text value for the starting directory (where you run Paraffin) so you can make the Source attribute relative to your main installers directory, or you can insert a WiX preprocessor variable.
-diskId <number>	The value of the DiskId attribute on component elements in case you have your installer on multiple media. WiX defaults to 1 so you only need to use this switch if you need a value of 2 or higher. The <number> specified must be an integer.
-dirref <DirectoryRef>	Paraffin defaults to using INSTALLDIR as the Id attribute to the <DirectoryRef> element. If you are using a different value to put your fragments under, specify that value with this switch.
-ext <ext>	File extensions to not include in the Paraffin output. You can specify as many -ext flags as you like. The <ext> specified does not need to include the leading period.
-includeFile <file>	Files to be added as WiX includes at the top of the output file. No validation on the contents of the file. You many have as many -includeFile options as you need.
-norecurse	Paraffin defaults to recursing the start directory and every directory underneath this, if you only want to do the -dir specified directory, use this switch.
-NoRootDirectory	Paraffin defaults to including the -dir specified directory as a <Directory> element under the main <DirectoryRef>. If you want the files in the -dir location to go directly under the <DirectoryRef> use this switch.
-regExExclude "regex"	Adds regular expression exclusions to both files and directories. The regular expression specified must be in quotes to account for spaces. Also, all regular expressions are treated as case insensitive. When Paraffin is looking at files, the regular expression is applied to just the filename. For directories, the check is against the complete drive and directory name. Specify as many -regExExclude options as necessary.
-verbose	Shows verbose output.
-Win64var <var>	If specified adds the Win64="<var>" attribute to all components. In most cases you should not use this switch but instead specify the architecture with the WiX tool's -arch switch.

Deprecated Optional Parameters for Initial File Creation

Parameter

Description

-direXclude <exdir>

This switch may be deprecated in future versions of Paraffin. Please use the -regExExclude switch going forward.

This switch allows you to specify directory names you want Paraffin to skip and not process. There is no wildcard matching only string contains matching. You can have as many -direXclude switches as necessary.

Updating Fragments for Major Upgrades

As I mentioned earlier, major upgrades are really the way to go with Windows Installer. They alleviate you of worrying very much at all about what happens when you install a new version. Before the new bits are installed, Windows Installer uninstalls the old version so there are no problems with component rules, left over goo, or anything else associated with minor upgrades. If you don't have major prerequisites, such as SQL Server, specific versions of .NET, or anything else complicated, you don't even need a boot strapper, like the long dreamed about Burn, everything can be done with just the .MSI file.

When using Paraffin to update an existing fragment for a major upgrade, any new files found in the directory are added as appropriate. The Components elements for files that no longer exist are removed. For files that haven't changed the Component element GUID and Id attributes are properly transported to the output file so the component rules don't break.

It's important to realize that Paraffin does not overwrite the existing <input>.WXS file but writes out the changes to <input>.PARAFFIN. Numerous Paraffin users have asked for Paraffin to overwrite the file, but we're dealing with Windows Installer here. It's a brittle and scary API in Windows so I'm loath to go down that route.

Required Parameters for Major Upgrade Processing

Parameter	Description
-update	This switch tells Paraffin you want to do updating for a major upgrade.
<file>	The original .WXS file to process again.

Optional Parameters for Major Upgrade Processing

Parameter	Description
-ext <ext>	Additional file extensions to not include in the Paraffin output that will be added to the ones specified when creating the file. You can specify as many -ext flags as you like. The <ext> specified does not need to include the leading period.
-regExExclude "regex"	Additional regular expression exclusions to both files and directories on top of the ones specified when the file was created. See the previous discussion of -regExExclude for more information. Specify as many -regExExclude options as necessary.
-ReportIfDifferent	If specified, Paraffin's exit code will be 4 if the input .WXS file and the output .PARAFFIN file are different. If the files are identical, the exit code is 0. The idea behind this switch is that you could run Paraffin as part of your build and know when you have forgotten to add or remove files from the main .WXS files automatically.
-verbose	Shows verbose output.

Updating Fragments for Minor Upgrades

Adding files is trivial in a minor upgrade. The problem becomes when you need to remove a file during that minor upgrade. According to the Window Installer rules, that's requires you go directly to a major upgrade. Many people have asked me to implement the scheme described by Vagmi Mudumbai in his blog: http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx, which will remove files during minor upgrades.

In WiX, the above would look like the following (word wrapped for this document). The trick is to add the Transitive attribute to the Component element, and add a nonsensical condition. The transitive forces the condition to be reevaluated and the condition is false. Thus, the file is uninstalled in a minor upgrade.

<Component Id="comp_F5B392C05B5249C2AB34810BE4A6163F"
           Guid="FD9D7BF4-550A-47E2-85A3-634D77F609FB"
           Transitive="yes">
  <File Id="file_81DD236ED61B4BBEB445FAB9E9C2DAB2"
        Checksum="yes"
        KeyPath="yes"
        Source=".\Temp\a.exe" />
  <Condition>1 = 0</Condition>
</Component>

There's one more step that's involved. The file must be there when building your install and it's also best if that file is only zero bytes long so it doesn't take up space in the .MSP. Don't worry Paraffin takes care of all of this mess for you. All you have to do is to delete the files you used to install before running Paraffin to build the minor upgrade ready file.

Once you've deleted a file for a minor upgrade, Paraffin assumes it's deleted forever. If you try to add a file with the same name and directory back, Paraffin will abort processing because you are going to break the component rules. If you need to add a file with a previously deleted name you need to use a major upgrade. While I'm sure someone will ask that I make Paraffin handle that situation, I won't because you're probably screwing up your installation.

With the minor upgrade checking, Paraffin is only looking at files it does not look at directories. If you delete or rename a directory, you need to use major upgrades. The trick of using the transitive attribute only applies to the Component element. There's no way for a minor upgrade to remove a directory so there's no need for me to implement support for it.

Required Parameters for Minor Upgrade Processing

Parameter	Description
-PatchUpdate	This switch tells Paraffin you want to do updating for a major upgrade.
<file>	The original .WXS file to process again.

Optional Parameters for Minor Upgrade Processing

Parameter	Description
-ext <ext>	Additional file extensions to not include in the Paraffin output that will be added to the ones specified when creating the file. You can specify as many -ext flags as you like. The <ext> specified does not need to include the leading period.
-regExExclude "regex"	Additional regular expression exclusions to both files and directories on top of the ones specified when the file was created. See the previous discussion of -regExExclude for more information. Specify as many -regExExclude options as necessary.
-PatchCreateFiles	If you'd like Paraffin to create the zero byte files for your removed files, this switch will take care of that for you. If you rerun Paraffin again with the -PatchUpdate switch as it checks the .WXS file for the transitive attribute on the component so it doesn't see the zero byte file as a new file.
-ReportIfDifferent	If specified, Paraffin's exit code will be 4 if the input .WXS file and the output .PARAFFIN file are different. If the files are identical, the exit code is 0. The idea behind this switch is that you could run Paraffin as part of your build and know when you have forgotten to add or remove files from the main .WXS files automatically.
-verbose	Shows verbose output.

Creating the Removed Zero Byte Files

If you're like me, you probably don't want to have these odd zero byte files necessary for the minor upgrade file removal littered through your version control system. Paraffin offers a separate command line option to go create all those zero byte files on the fly. The idea with this command line option is you'll run Paraffin with it as part of your master builds so you don't have to worry about those long ago deleted files ever again.

Required Parameters for Zero Byte File Creation

Parameter	Description
-PatchCreateFiles	Tells Paraffin to create any zero byte files you want to remove in minor upgrades
<file>	The .WXS file that has dead files in it.

Optional Parameters for Zero Byte File Creation

Parameter	Description
-verbose	Shows verbose output.

Paraffin Exit Codes

Exit Code	Description
0	Paraffin ran without errors. If -ReportIfDifferent was specified when doing either kind of update, zero also means there is no difference between the .WXS file and the .PARAFFIN file.
1	An invalid command line option was specified
2	The input .WXS file is invalid
3	The file contains multiple files per component. Starting with WiX 3.5, multiple files per components is no longer supported. Please revert to WiX 3.13.
4	If -ReportIfDifferent was specified, an exit code of 4 indicates the input .WXS file and the output .PARAFFIN file are different.

Paraffin .ParrafinMold files

In order to support more customization of the Paraffin output, Paraffin supports the concept of injectable data through files that have the .ParrafinMold extension. For example, since Paraffin does not handle COM and .NET assembly registration, which HEAT does, you may want to put the COM information into a .ParaffinMold file so it can be injected automatically.

As Paraffin is processing a directory and finds any files matching *.ParaffinMold, it will inject the contents of each .ParaffinMold file into the output file under the current element (normally Directory, or DirectoryRef if -norootdirectory is used).

All .ParaffinMold files are WiX fragment files must have a DirectoryRef element, but the Id value is ignored. Any elements under the DirectoryRef are placed directly in the output file. There is no checking done on thevalidity of any of those child nodes. Here is an example .ParaffinMold file to insert a Registry element.

<?xml version="1.0" encoding="utf-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
  <Fragment>
    <DirectoryRef Id="INSTALLDIR">
      <Component Id="INSTALLDIR"
              Guid="PUT-GUID-HERE">
        <RegistryKey Root="HKLM"
                   Key="SOFTWARE\My Company\My Product"
                   Action="createAndRemoveOnUninstall">
          <RegistryValue Name="InstallRoot" Value="[INSTALDIR]"
               Type="string" KeyPath="yes"/>
        </RegistryKey>
      </Component>
    </DirectoryRef>
  </Fragment>
</Wix>

Notes for Upgraders to Paraffin 3.5

Prior to Paraffin 3.5, Paraffin supported multiple files per component. Since one file per component is much preferred for Windows Installer resiliency, and I couldn't find anyone using multiple files per component, I removed support for it. By doing so it made my development life easier and greatly simplified the new -PatchUpdate feature. If you happen to need multiple files per component, please keep using Paraffin 3.13 you can find here: http://www.wintellect.com/CS/files/folders/8198/download.aspx.

Paraffin used to put the KeyPath attribute on the Component. It looks like now it's much better to have that on the File element itself. If you use Paraffin 3.5 to update a .WXS file created with a previous version, I swap the KeyPath attribute as appropriate. That shouldn't cause any problems for anyone, but I wanted to give you notice of the change. You'll also see yellow warning text on the screen when you run Paraffin when the attribute swap occurs.

Paraffin 3.5 – Now with Better Minor Upgrade Support

jrobbins — Tue, 31 Aug 2010 21:23:00 GMT

Slowly but surely I'm getting through the list of feature requests everyone's been asking for. This release of Paraffin brings support for the trick outline by Vagmi Mudumbai (http://geekswithblogs.net/Vagmi.Mudumbai/archive/2006/06/11/81426.aspx) of allowing minor upgrades (AKA patches) to remove files by setting the transitive bit on the component and adding a conditional element that evaluates to false.

<Component Id="comp_F5B392C05B5249C2AB34810BE4A6163F"
           Guid="FD9D7BF4-550A-47E2-85A3-634D77F609FB"
           Transitive="yes">
  <File Id="file_81DD236ED61B4BBEB445FAB9E9C2DAB2"
        Checksum="yes"
        KeyPath="yes"
        Source=".\Temp\a.exe" />
  <Condition>1 = 0</Condition>
</Component>

So if you need to delete A.EXE on a minor upgrade, delete A.EXE from disk and run Paraffin with the new –PatchUpdate switch. The output .PARAFFIN file will have the following in it for A.EXE

Those of you who've looked at Vagmi's trick are wondering about the other piece that needs to be there; the file. But you deleted the file. If you build with WiX, you'll get an error because the File element must point to a file to put in the output .MSP. To keep the patch file small, you should have a zero byte file called A.EXE to make everything work.

Fortunately, Paraffin has you covered there as well. When you specify the –PatchUpdate switch, you can add the new –PatchCreateFiles switch and Paraffin will create the zero byte files for you. Don't worry, when you rerun Paraffin again with –PatchUpdate, if the zero byte file is there, Paraffin checks if the Transitive attribute is set and makes sure to keep everything straight.

While you could keep those zero byte files in your version control system, which seems a little odd to me since they are, well, no longer needed. Because Paraffin knows which files have been deleted with the Transitive attribute on the Component element you can recreate the zero byte files at any time by using –PatchUpdate file.wxs as the command line. The idea is that you'll run this as part of your build so you never have to worry about those zero byte files.

While I believe major upgrades are really the way to go since they are much easier to manage, I know a lot of you using Paraffin are doing minor upgrades. Hopefully this will make your WiX life a little easier.

A second new feature I added is the –ReportIfDifferent switch. Several people told me they wanted a way they could tell if when updating, through –Update (for major upgrades) and the new –PatchUpdate switch, if the output .PARAFFIN file was different than the input file. As one person told me they wanted to run the update during a build and if the files were different, to fail the build in case someone forgot to update the .WXS file to reflect changes. With –ReportIfDifferent, the exit code for Paraffin will be four if the input .WXS and output .PARAFFIN files are different. If they are the same, the exit code is zero.

I did remove a feature from Paraffin, support for multiple files per component. All the people I talked to using Paraffin were using one file per component because it offers better resiliency with Windows Installer. By removing this support, it made my development life easier as well. If you need multiple files per component support, keep using Paraffin 3.13 (http://www.wintellect.com/CS/files/folders/8198/download.aspx).

Another change for upgraders is I changed to adding the KeyPath on the File element instead of the Component element. If you use Paraffin 3.5 to update a .WXS file created with a previous version of Paraffin, I swap the attributes around.

While I never cared what you did with Paraffin or its source code, not having a license in the download was freaking out many of your lawyers. Without legal language somewhere lawyers head's explode. I threw in the CPL license file to make your life easier. However, I still don't care what you do with the code. All I ask is that you let me know about any bugs you find or features you want in Paraffin.

Here's the list of minor changes I made in Paraffin 3.5.

Added a Zen of Paraffin document to help explain how to best use Paraffin.
Added the -verbose command line option for verbose output.
Now the DiskId attribute is only added if the value is not the default of 1.
Refactored the code into three different files for ease of development.
Removed deprecated command line switches and the code reporting their usage.
Warnings are written in yellow text and errors are now written in red.

Here's the program and the source: http://www.wintellect.com/CS/files/folders/18310/download.aspx.

Fluent Validation with MEF and PRISM

C#er : IMage — Fri, 27 Aug 2010 18:39:01 GMT

Validation is a topic that comes up quite frequently. One concern is how to honor DRY (don't repeat yourself) principles and create a framework that is reusable across layers. There are some very robust and tested frameworks out there, but sometimes they might be more than what you are looking for. In this post, I'll show you how to build a standalone validation library that can be shared between Silverlight and the server, then integrated via MEF and PRISM for fluent validation. Rules and Violations...(read more)

Visual Studio debugging of GPU parallel algorithms

writscher — Tue, 24 Aug 2010 20:04:33 GMT

By now you've probably heard of the steady march toward multiple CPUs in your computer. First there were two core CPU's and then a few months later there was four core ones available. The number keeps growing, with Intel predicting 80 core within a few years.

Naturally the development world looked at multiple cores and started thinking about how to write parallel algorithms. But some developers took a side road to completely different parallel programming world. These developers realized that there was another processing unit on most computers that had vastly more parallel processing power. I'm talking about your computers graphic processor unit (GPU).

Modern GPUs are designed to apply parallel algorithms to pixels. The pixel information is just byte data so some smart people figured that the GPU might be good at certain non-graphic algorithms. It turns out they were right. There are problems that lend themselves to running on the GPU. These include financial, bioscience and cryptography problems.

NVIDIA is a big player in the GPU world and they took notice of this new development. And they decided to enhance the market by creating specialized development tools. Here's what I find interesting; NVIDIA decided to build a Visual Studio extension to permit multi-threaded, parallel debugging for these new GPU applications.

In July 2010 NVIDIA released a free edition of a tool called Parallel Nsight. http://developer.nvidia.com/object/nsight.html

Quote from NVIDIA site

What could you do with your application running 5 – 50 times faster? Develop an innovative approach to cancer detection? Analyze financial options in real-time? Discover hidden oil reserves? Create award winning game physics? Process HD video to allow your customers to meet deadlines? Our partners are doing all of the above, and more.
The power of GPU Computing is already delivering game changing performance increases to the Medical, Finance, Energy, Consumer and Research fields. For over 1,000 customer stories, visit www.nvidia.com/cuda.

This tool integrates within Visual Studio 2008 SP1. According to NVIDIA they will have a working version for Visual Studio 2010 by the end of the year.

Nsight includes approximately ten tools that simplify debugging, profiling an integrated build tools. It fully exploits the Visual Studio debugging Windows.

I still find it fascinating what we can do with computers.

Coroutines for Asynchronous Sequential Workflows using Reactive Extensions (Rx)

C#er : IMage — Sun, 22 Aug 2010 08:43:00 GMT

I've been doing quite a bit with Reactive Extensions (Rx) for Silverlight lately. One idea that I keep exploring is the concept of creative intuitive sequential workflows for asynchronous operations. You can read about my explorations using Wintellect's own Power Threading Library in this post along with a simple solution using an interface and enumerators in part 2 of that series. I'm tackling the problem from a different angle. First, my disclaimers: this is more of an exploratory, "Here's what...(read more)

Still seats available in the upcoming Wintellect WPF virtual class

writscher — Fri, 20 Aug 2010 19:39:34 GMT

Once or twice a year Wintellect offers my Windows Presentation Foundation (WPF) class as a two day virtual online class. it’s a busy two days, I cram a lot information about WPF basics into a short amount of time. it is always hard for me to decide what to include in these two days; you see I have about eight days worth of the material that I’ve written over the last couple years. Yes WPF is a big framework. Anyway I put together a good two days worth of topics and the class is always a lot of fun and filled with great people asking interesting questions.

We are offering the class again this summer on August 30th. Looks like we still have some seats available for the class so please join me for the two days. I promise you’ll learn a lot about WPF and have a good time in the process.

https://www.wintellect.com/Registration/WintellectRegistration.aspx

Simplifying Silverlight Web Service Calls with Reactive Extensions (Rx)

C#er : IMage — Thu, 19 Aug 2010 11:10:00 GMT

I've been working with the Reactive Extensions (Rx) library quite a bit lately and am very impressed. While it is a new way of thinking about services, it certainly makes life much easier. In this example, I'll show you a way to simplify your web service calls using Rx. In fact, even if you don't use Reactive Extensions, you may benefit from the proxy wrappers that I'll describe. I'm assuming you are familiar with Silverlight, web services, and have some exposure to the Managed Extensibility Framework....(read more)

Managed Extensibility Framework Quickstart: Hello, MEF

C#er : IMage — Tue, 17 Aug 2010 14:55:00 GMT

I've been working on quickstarts for a community team that I'm a member of. The team is called MEFContrib . We write extensions to the Managed Extensibility Framework as well as supporting manuals and documentation. I've been tasked with the quickstarts and as I release them I'll post them for you. Obviously, a quickstart should be, well, quick, and easy. We also decided quickstarts would be independent so that you can jump into any topic without having to read the prior ones. Today's post is simply...(read more)

Sharing Commands with the Managed Extensibility Framework

C#er : IMage — Tue, 10 Aug 2010 10:50:01 GMT

View models can expose commands that are bound to controls. Commands encapsulate an action and a permission, and the advantage to binding is that controls that support commands will automatically disable when the command cannot execute. Commands can also be easily added to view models and tested. It is common to find commands that are used universally. In Windows Presentation Foundation (WPF), this is managed by a set of global commands that can be accessed via static classes. Silverlight does not...(read more)

Remote Debugging Startup procedures in WPF

writscher — Tue, 10 Aug 2010 05:05:17 GMT

This week I was debugging a problem with a WPF application. Actually, it being a WPF app had little to do with the problem. No, what I was testing was the installer process.

We’re writing a new WPF frontend for an existing system and the application needs to installed via a InstallShield installer. It’s a legacy system and has dependencies on older systems and software. For example, during the setup we install a Access 2003 mdb file into the %appdata% folder. The installer is also supposed to install the prerequisite technologies, like .NET 4.0 and copy a files to numerous locations on the local drive. Then on application start we need to dynamically find these files. Trouble was, when the app started for the first time, it immediately crashed.

Looking through event log revealed a unhandled exception as the cause of the crash. The app has an event logger, but the code didn’t seem to be running. Checking the installer logs didn’t show any obvious problems either. I decided it was time to turn to Visual Studio remote debugging for help.

Debugging on VPC

As you might have surmised by now, I’m testing the install on a virtual PC. It’s configured with undo disks, so I can roll back the install after each try. After thinking about it for a few minutes I decided put a breakpoint in the apps Main method. This is trivial in most circumstances, but I wasn’t sure how to accomplish this in my scenario. I didn’t want to install VS or other debuggers on the VPC. This seems like a prime use case for Visual Studio 2010 remote debugging.

I won’t bore you with the steps to configure you machines to enable Remote Debugging. After about 15 minutes work I had the remote debugging working. John Robbins has a nice post about setting up Remote Debugging [1] on a local Virtual PC if you want to create a similar setup.

How to hit breakpoint in Main method

Normally the way you remote debug it to start the msvsmon.exe on the VPC (be sure and run as administrator), then launch the app. Once the app is running, you return to Visual Studio and choose Debug\Attach to Process, then pick your instance of msvsmon and choose the remote process.

But thing are a little tricky here. Do you see the problem with that approach? Yes, by the time you get the app running and return to Visual Studio your program is long past executing the code in the Main method and other startup methods.

My solution, put a 30 second Thread.Sleep in the Main method. That gave me time to switch back to the other screen and get the debugger attached.

  App app = new App();
  Thread.Sleep(1000 * 30);
  .. breakpoint here
  app.MainWindow = new MainWindow();
  app.MainWindow.Show();

  app.Run();

It worked perfectly, I was able to trace the problem to a typo in the installer. I’m sure there are approaches to take however. Do you have a favorite technique?

[1] http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/06/15/vs-remote-debugging-across-workgroups-or-domains.aspx

Spending Time with my LG Windows Phone 7 “Developer” Device

writscher — Fri, 06 Aug 2010 07:29:48 GMT

Tuesday morning started out good. I was in a meeting room on the Microsoft campus, working on a Windows Phone 7 (wp7) application. About 10:A.M. my local developer evangelist came to the room. In his hand was a white and yellow box that contained my new Windows Phone. Yes, I’m talking about a wp7 device made by LG. The GW 910 is a phone that contains a slide out keyboard.

I’ve had the phone for three days now. First impressions are good, the start screen was intuitive and easy to use. I toured the included applications. There aren’t that many, but the core ones look solid. It’s a novelty to open Microsoft Excel and see the tiny spreadsheet. Pinch gestures work, so it is easy to scale the cells up to a readable size.

It took me a while to learn how to uninstall applications. On the wp7 you press and hold the application icon. After a one second wait a menu pops up which contains the uninstall menu.

There are still pending changes coming for the main UI. Those changes are still cloaked however, you’ll need to wait a few weeks to see what’s new.

I didn’t like the keyboard, I prefer the one on my HTC Touch Pro 2. One the other hand, the onscreen keyboard (known as the Soft Input Panel -SIP) was fast and easy to use, once I got use to the correct way to hold my finger in relation to the virtual keys.

Another hardware #fail, the touch screen is not sensitive enough. I find myself touching the same icon/button repeatedly with no results. This is definitely a LG issue. I spent some time with the Samsung device on Wednesday and its screen was smooth and responsive. Oh, and the Samsung was noticeably faster too.

Writing and deploying apps to the phone

If you are a Silverlight developer you are going to love programming for this phone. Silverlight just works. Most of the time your code can be ported directly to the phone. It took me less than than ten minutes to port a Bing Map demo to the phone. The only quirks are understanding what Silverlight version is on the phone. It is part Silverlight 3, some of Silverlight 4 and some extra APIs thrown in for good measure.

Setting up your computer to use the deploy to the phone takes a few steps. First, you must install all the wp7 tools and Beta SDK. (learn more at http://developer.windowsphone.com/) Then you have to install the Zune Beta (aka Dorado) on your local computer. Once that is done, you just connect a USB cable,make sure the Zune software is running on local computer, choose the device from the drop down in Visual Studio and press F5 to debug. It’s a beautiful experience.

Wintellect & devLink2010

bvananda — Thu, 05 Aug 2010 15:02:00 GMT

I am in Nashville this week for the 5^th annual devLink Technical Conference (www.devlink.net). This is my first devLink and I am very excited about this week and getting to chat with all of the folks who are attending. So if you’re at the event be sure to stop by our table to say "hi". We will be raffling off some cool prizes that you won't want to miss.

We also wanted to show our love for the developer community and we are really excited to be teaming up with our friends at Infragistics to treat 10 developers attending devLink to a night out at the movies. For every person who “Likes” Wintellect & Infragisitcs on Facebook and post’s “Take me to the movies!” on each of our Facebook walls they will be entered into a contest where we will randomly select 10 folks to win a Regal Cinemas gift card! On Saturday each company will randomly select 5 winners. Post on both Infragistics & Wintellect to double your chances of winning.

But wait there’s more, each day; Wintellect & Infragistics will give away a big prize pack that includes: a copy of Jeffrey Richter’s CLR Via C#, Third Edition book, Infragistics NetAdvantage for .NET, NETAdvantage for Silverlight Data Visualization, & NetAdvantage Icons. On Saturday, we’ll give away a Kindle Dx and a $50 Amazon.com gift card!

Unit Testing XAML Data-Bindings in Silverlight

C#er : IMage — Thu, 05 Aug 2010 09:46:03 GMT

In an interview earlier this year with MSDN geekSpeak , I discussed unit testing for Silverlight and some of the frameworks that are available. One audience member raised a very important question: "How do we test the XAML?" Specifically, what happens when we hand off XAML to a designer or another developer, and they accidently remove a data-binding or other critical element, then pass it back to us? The Problem Many developers don't realize this, but the view is not decoupled from the underlying...(read more)

Using Reactive Extensions (Rx) to Simplify Asynchronous Tests

C#er : IMage — Tue, 03 Aug 2010 11:11:00 GMT

Reactive Extensions (Rx) is a product from Microsoft Research that simplifies the management and composition of asynchronous events. If you read my earlier post on Asynchronous Workflows , you'll understand why the asynchronous programming model can sometimes lead to confusing and hard-to-maintain code. There is nothing wrong with the model, but the fact that you must subscribe to an event or register a callback means your code can end up nested and scattered to the winds. Add to that the complexity...(read more)

Changing Hardware can Invalidate your Expression Blend License

writscher — Tue, 27 Jul 2010 06:51:37 GMT

Do software crises ever happen when you have plenty of free time to troubleshoot them? I’m sure that they do, it just doesn’t seem that way for me in the last few years.

Expression Blend Warning

The first sign of trouble appeared as a gentle nag screen in Expression Blend 4. “Only 2 days left to activate your license” it whispered to me one morning.

“What the heck?” I thought to myself. I knew that I had activated the license months ago. Just to be sure, I looked it up. Yes, about a week after I installed Expression Blend I had requested a license key from MSDN and activated my copy.

Re-Activate

So I found my copy of the key and reactivated the license. This is where it’s starts to get strange.

Side Note: Some of the text is cut-off in these screen shots. This is _another_ issue with Blend. I’m running my computer in 115% DPI settings. Apparently non default DPI settings still cause problems like this. I thought the Device Independent Pixel framework in WPF took care of this. I guess not.

Starting the activation process.

First error during the activation.

Blend offers to retry. I try again.

Good news, or so I think. Activation success.

Hmm. that’s not right. I just activated the software. Apparently the success message is wrong and I do not have a valid license yet.

Blend team members help troubleshoot

I contacted the Blend team and they put some of their licensing developers on the problem. I ran some license checking software and sent the results to them to analyze. And they found the problem.

Here’s the question from Chris that put me on the right track.

“Have you made any changes to your machine?? (Replaced a DVD/CD drive or network card??). “

Hmm. now that you mention it I have. Dell replaced my motherboard a couple weeks ago. Yesterday, I replaced my hard drive. And yesterday is when the problem started.

Back from Chris comes this simple sentence .“The license software sees the change in hardware as an attempt to get around the software licensing.”

Bingo, now we know the problem.

Changing hardware may void your license

Expression Blend is not the first product from Microsoft to use this type of licensing policy. What’s surprising is that all my other Microsoft software on this same computer is happily working without the slightest hint of trouble.

So, what is the resolution you ask? I need to get a new key from MSDN. Unfortunately, my subscription only grants me three activations and apparently I’ve already used them all (VPC installs?). Time to call Microsoft support and plead my case.

Silverlight UI Automation Testing using Prism 4.0

C#er : IMage — Mon, 26 Jul 2010 15:51:04 GMT

One popular gripe about Silverlight has been the lack of integrated testing tools. There are several types of tests you may perform against a software project. Unit tests can be performed with the aid of the Silverlight Unit Testing Framework and automated with a third-party tool such as StatLight . Automation testing involves hosting the actual Silverlight application in a browser and performing a walkthrough based on a script. Typically, this script will follow a "happy path" through the application,...(read more)

Using Hints for Generic MEF Exports

C#er : IMage — Sun, 25 Jul 2010 10:36:02 GMT

It is very common to have base classes and interfaces that use generic types to define standard behaviors across business applications. One challenge with the Managed Extensibility Framework is that it doesn't directly support generic exports and imports: in other words, there is no way to effectively do the following: ... [ImportMany(AllowRecomposition=true)] public IService<,>[] GenericService { get; set; } ... While there is a GenericCatalog you can use, I wanted something a little more flexible...(read more)

The BringToFront Behavior

writscher — Wed, 21 Jul 2010 01:27:56 GMT

Are you a WPF history buff? If so you might be familiar with the attached behaviors story. It’s a short saga, but worthy of review. Back in the early days of WPF we were learning the nuances of the new XAML system. The attached property system was an interesting subsystem of WPF, revealing a clever way to add a property to an unrelated object. A few of the XAML pioneers decide to extend this idea to behavior. Their idea was to define a behavior (code) in a class, register it with the Dependency System and then ‘attach’ the behavior to other classes.

The idea had merit so the Expression Blend team brought the concept into Blend 3. They created a sub-classable type called System.Windows.Interactivity.Behavior<UIElement>, which makes it simple to create custom attached behaviors.

I’m constantly thinking of ideas for new behaviors, here’s one for moving an object to the front of the other items in a Panel.

public class BringToFrontBehavior : Behavior<Panel>
  {
    protected override void OnAttached()
    {
      base.OnAttached();
      AssociatedObject.Loaded += 
           new RoutedEventHandler(AssociatedObject_Loaded);
    }

    void AssociatedObject_Loaded(object sender, RoutedEventArgs e)
    {
      foreach (var child in AssociatedObject.Children)
      {
        child.MouseLeftButtonUp += new MouseButtonEventHandler(child_MouseLeftButtonUp);
      }
    }

    void child_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)
    {
      BringToFront(sender);
    }

    // call this method to move element to front of ZIndex
    private void BringToFront(object sender)
    {
      Panel parent = (Panel)((FrameworkElement)sender).Parent;

      int z = GetHighestValue(parent);

      for (int i = 0; i < parent.Children.Count; i++)
      {
        if (sender.Equals(parent.Children[i]))
        {
          parent.Children[i].SetValue(Canvas.ZIndexProperty, z);
        }
      }
    }

    private int GetHighestValue(Panel parent)
    {
      int highest = 0;
      foreach (var child in parent.Children)
      {
        var val = (int)child.GetValue(Canvas.ZIndexProperty);
        if (val > highest)
        {
          highest = val;
        }
        child.SetValue(Canvas.ZIndexProperty, val - 1);
      }
      return highest;
    }
  }

Sterling OODB v0.1 Alpha Released!

C#er : IMage — Sat, 17 Jul 2010 10:29:02 GMT

I'm please to share that I released the alpha version of the Sterling Object-Oriented Database for Silverlight 4.0 and Windows Phone 7.0 applications today. I dug into more details about the project in this introductory post . There have not been many significant changes to the source code since then, but I did create a set up project that installs the DLLs and configures the registry keys so they appear in the "add reference" dialog on the .NET tab for both Silverlight and Windows Phone 7 applications....(read more)

Building a component that works with different versions of a library–STATIC METHODS

JeffreyR — Fri, 16 Jul 2010 13:10:00 GMT

In my previous blog post, I discussed how to build a .NET component that works with different versions of a particular library. In that post, I demonstrated a technique for accessing instance methods that get added in a later version of a library. In this post, I’ll modify the technique some to make it work reasonably well for static methods that get added in a later version of a library.

Let’s starts by looking at Version 1.0 of some library class:

public sealed class VersioningType { // v1.0
// Other methods not shown
}

And, let’s say that version 2.0 of the same library class looks like this:

public sealed class VersioningType {     // v2.0
   public static String NewStaticMethod(String arg) {// New STATIC method introduced in v2.0
      return "Real static method: " + arg; 
   }
   // Other methods not shown
}

Now, we want to write some code in a component that calls VersioningType’s NewStaticMethod if it exists at runtime. To do this, I would add the following VersioningTypeExtensions class into my component code:

internal static class VersioningTypeExtensions {
   private static dynamic s_NewStaticMethodFound =
      new StaticMemberDynamicWrapper(typeof(VersioningType));   // Assume method exists

   /// <summary>The stub for VersioningType's static NewStaticMethod method</summary>
   public static String NewStaticMethod(String arg) {
      if (s_NewStaticMethodFound != null) {
         try {
            // We think the method exists, try to invoke it
            return s_NewStaticMethodFound.NewStaticMethod(arg);
         }
         catch (RuntimeBinderException) {
            // The method doesn't exist; in the future, avoid the dynamic/exception perf hit
            s_NewStaticMethodFound = null;
         }
      }

      // This is the default implementation we want if the method doesn't exist
      return "Stub static   method: " + arg;
   }
}

This code introduces a static method called NewStaticMethod that matches the same signature as the NewStaticMethod introduced in v2.0 of the library. Now, in my component’s code, I can call this static stub method and I get compile-time type safety at all the call sites. This code uses a helper class that I wrote, called StaticMemberDynamicObject. I show the code for this class at the bottom of this blog post. You construct an instance of my StaticMemberDynamicObject class by passing a type to its constructor. In short, by casting a reference to a StaticMemberDynamicObject object to C#’s dynamic type, you can invocate a type’s static methods, properties, or fields dynamically at runtime. It makes the type look like an object and this class for use with dynamic types. The StaticMemberDynamicObject class is useful in many programming scenarios.

Inside VersioningTypeExtension’s NewStaticMethod stub method, I use the s_NewStaticMethodFound field (which is of the dynamic type) to try to call VersioninType’s static NewStaticMethod. If our component is running against v2.0 of the library, then its NewStaticeMethod will be invoked. But, if our component is running against v1.0 of the library, then attempting to call NewStaticMethod will throw a RuntimeBinderException. My stub method catches this exception, sets the static field to null and then my code that simulates the default behavior of this method. In this case, I return a string indicating that my stub method handled the call.

The static s_NewStaticMethodFound field exists to improve performance. Once the stub determines that VersioningType doesn’t offer the desired method, this field is set to null and future invocations of the stub method avoid the performance hit of entering/leaving a try block, attempting to dynamically invoke the NewStaticMethod and the performance hit of processing the thrown RuntimeBinderException. In addition, the StaticMemberDynamicObject object can be garbage collected now.

If in the future, we decide that our component no longer needs to work with v1.0 of the library, we can build our component code against v2.0 of the library and we can leave all our code alone and it will just suffer a slight performance penalty whenever calling NewStaticMethod. Or, we can delete our stub method and then modify all of the call sites to call VersioningType’s static NewStaticMethod method directly.

The instance method technique shown in my previous blog posting used C#’s extension methods to implement the stub. This had two significant benefits. First, the code at the call site looked just like the code you would have to call the instance method meaning that no source code would have to change in order to call the V2.0 library. Second, if we build the component against v2.0 of the library, then the compiler would bind to the instance method instead of the extension method resulting in a performance improvement by not calling the stub method. Unfortunately, we don’t get these benefits with static methods because extension methods don’t allow you to extend a type with a static method. Extension methods can only extend objects with instance methods.

Below is the code for my useful StaticMemberDynamicObject class that allows you to dynamically invoke static members of a type. This class is derived from the .NET Framework’s System.Dynamic.DynamicObject class which allows instance of the class to control how its members are invoked when invoked using C#’s dynamic type.

/// <summary>Construct an instance of this class and cast the reference to 'dynamic'
/// to dynamically invoke a type's static members</summary>
internal sealed class StaticMemberDynamicWrapper : DynamicObject {
   private const BindingFlags c_bf = BindingFlags.Public | BindingFlags.Static;
   private readonly Type m_type;
   public StaticMemberDynamicWrapper(Type type) { m_type = type; }

   public override IEnumerable<String> GetDynamicMemberNames() {
      return m_type.GetMembers(c_bf).Select(mi => mi.Name);
   }

   public override bool TryGetMember(GetMemberBinder binder, out object result) {
      var members = m_type.GetMember(binder.Name, MemberTypes.Field | MemberTypes.Property, c_bf);
      if (members.Length != 1) { result = null; return false; }
      result = (members[0].MemberType == MemberTypes.Field)
         ? ((FieldInfo)members[0]).GetValue(null)
         : ((PropertyInfo)members[0]).GetValue(null, null);
      return true;
   }

   public override bool TrySetMember(SetMemberBinder binder, object value) {
      var members = m_type.GetMember(binder.Name, MemberTypes.Field | MemberTypes.Property, c_bf);
      if (members.Length != 1) return false;
      if (members[0].MemberType == MemberTypes.Field)
         ((FieldInfo)members[0]).SetValue(null, value);
      else
         ((PropertyInfo)members[0]).SetValue(null, value, null);
      return true;
   }

   public override Boolean TryInvokeMember(InvokeMemberBinder binder,
      Object[] args, out Object result) {

      MethodInfo method = m_type.GetMethod(binder.Name, c_bf);
      if (method == null) { result = null; return false; }
      result = method.Invoke(null, args);
      return true;
   }
}

Silverlight Profiling Part 2: The Easy Way

C#er : IMage — Thu, 15 Jul 2010 10:13:02 GMT

After posting about profiling Silverlight 4 out of the box, the author of a tool was kind enough to share with me his free .NET profiling tool . It's free, and it does a lot more than Silverlight. The manual is very straightforward but I wanted to make a quick an easy "light tour" to show you how I profiled the X-Fit app using the tool. In less than 4 minutes I'll run two different profiles, a trace and a memory scan. The memory scan lets you see individual classes, number of objects, size, etc,...(read more)

Shazzam Shader Editor 1.3 is now available

writscher — Wed, 14 Jul 2010 18:51:30 GMT

I work on an Open Source project called Shazzam Shader Editor. This week, we released version 1.3.

With this utility you can write, compile and test WPF/Silverlight shaders.

You can learn more about this free tool at http://blog.shazzam-tool.com.

Learn more about the features available in Shazzam 1.3.

Remove dependency on DirectX SDK
Write more complex shaders with the PS_3 specification
40 new texture maps added for multi input shaders
New Texture picker added to Try-out tab
Over 80 sample shaders
20 tutorials added
Changes to User Interface
- Rearrange Code and Tryout tabs
- Remember last shader in the Shader Loader list
- Explore Texture Maps menu item
- New hot keys
Better support options in help menu
Standard Windows Installer

Download your own copy at http://shazzam-tool.com

Taking a Look at Content Controls

writscher — Wed, 14 Jul 2010 17:23:43 GMT

A fair portion of the time, the content of a FrameworkElement is text. Some elements, like TextBox and TextBlock make this obvious, by providing a Text property. The Text Property is of type String and it trivially easy to set in XAML.

[example]

Other FrameworkElements are more flexible regarding their content. Take the ContentControls (CheckBox, Label, Button) for example. They expose the Content Property, not a Text property. Content, in this case, means a single child element. This child could be a single TextBlock or a complex nested hierarchy of children items.

[example]

    <Label Content='This control can contain text' />
    <Label>
      <Label.Content>
        <StackPanel Orientation='Horizontal'>
              
        <Image Source='geese.jpg' Width='100'/>
          <TextBlock Text='Or it can contain more complex UI' />
        </StackPanel>
        </Label.Content>
    </Label>
      <!--<TextBlock Content="This will not parse" />-->

WinForm developers are often surprised to learn the Label can work with complex content. The key thing to remember about Label in WPF it that its main purpose is NOT to show text. Rather, its prime mission is to enable 'accelerator-keys' for other controls in the XAML tree. For example, if you want to permit ALT-F to move your input cursor to the First Name TextBox. To do this you place a Label and a TextBox in your XAML. Use a binding to link the two together.

[example]

  <Label Target='{Binding ElementName=firstNameTextBox}' Content='_First Name'/>
    <TextBox x:Name='firstNameTextBox' />

Because the Label is a Content control you can show icons, bullets or other interesting UI in the Label.