omnispace

The CollectionViewSource class is used when we want to bind to a CollectionView from XAML in addition to setting various properties such as SortDescriptions and GroupDescriptions. If your design is based on Model-View-ViewModel, you may be using it to bind your ViewModel’s observable collection to the View.

<CollectionViewSource x:Key="sourceKey"
                       Source="{Binding Path=Data}">
    <CollectionViewSource.SortDescriptions>
        <scm:SortDescription PropertyName="NameOfProp" Direction="Descending"/>
    </CollectionViewSource.SortDescriptions>
</CollectionViewSource>

The SortDescription defined above will sort the items according to the “NameOfProp” property value of each item. This is convenient, for sure, but you will most likely hit a few brick walls if you are doing anything serious. Specifically, you are going to find out that in order to see a change in sort order within the collection view, you must refresh the collection view. Not only that, but I’m betting that you will eventually come to agree with me that the sorting operation performed by these SortDescriptions is horribly slow.

On top of that, refreshing the collection view itself is horribly expensive. It’s going to block user input and result in a semi-jarring update to the view, depending on the complexity of your items. The sorting operations themselves are painful because they have to rely on the use of Reflection, which will cause a huge performance if hit if you are dealing with a large dataset of complex items.

There is a way you can overcome these limitations, however, and I will show you how within this article. This solution will boost your performance a great deal, but there’s still room for improvement (which I’ll briefly touch on later).

Read the rest of this entry »

Sooner or later, you may find yourself in the position where you have to serialize and deserialize an object that is a member of one of your classes and of the type System.Drawing.Bitmap. Having a Bitmap as a member of a class is many times preferable over having the raw data be the member, as you only have to initialize the Bitmap once per instance, instead of per use.

You can try to serialize the class as is, and just throw a [Serializable] on top of the class, but you will more than likely run into the following problem:

ObjectDisposedException: Cannot access a closed Stream

This will occur if the original stream used to create the Bitmap is disposed. If you’re like me, you like to release unmanaged resources as soon as your done with them, which means I’m going to close that stream as soon as the Bitmap instance is loaded when I’m sync’ing up with a data source.

If you override ISerializable and try to achieve the serialization by creating a MemoryStream, and then calling the picture’s save message to save it to the stream (in order to get the byte array), you will get the same error.

Luckily for you, I have another way for you to retrieve the byte contents of a Bitmap; read on for an explanation as to how.

Read the rest of this entry »

By default, WCF makes use of the DataContractSerializer in order to serialize and deserialize an instance of a type into an XML stream or document. Traditionally, the DataContractSerializer required the use of a supplied data contract in order to know which objects, and which members of the objects, to serialize.

I’m sure we all enjoy decorating types in common, shared assemblies (i.e. data model defining libraries) with WCF-specific attributes. I know I do.

Fortunately, the release of .NET 3.5 SP1 gave the DataContractSerializer the ability to support serializing types that aren’t decorated with these WCF contractual attributes. This is a good thing when dealing with types that originate from shared assemblies whose code we don’t wish to infect with incessant attribute placement.

Being new to WCF, I hit a brick wall due to my reliance on this new feature without being fully aware of possible complications that may arise based on the types involved. If any of you are running into the error I’m about to discuss, it is my hope that this post will save you some time.

After I finished defining and implementing a ServiceContract that made use of several complex types, I noticed the following XmlException being raised when calling the service from a client:

System.Xml.XmlException : ‘<’, hexadecimal value 0×3C, is an invalid attribute character….

The source of the exception was an XML name validation method found in an internal .NET framework class. Needless to say, if I continued execution, the service call would have ultimately failed. As a side note, this is one of the reasons why I think the release of .NET framework reference code was a very sweet move and something you should take advantage of. It especially comes in handy when dealing with new and strange technologies. If I did not have .NET framework stepping enabled,  I’m sure the error that I’d have observed would have been much less fine-grained, which would have resulted in even more hair-pulling.

Upon closer inspection of the error, I eventually came to the conclusion that the exception was genuine, and that the cause for the error was indeed due to attempts to use names containing illegal characters. The following is one of the many offending names that were being used during serialization:

<Id>k__BackingField

The Id portion in the name above reflects a property in one of the types I was using, as all of the offending names did. So, what is with the ‘<>’ and ‘k__BackingField’ ?

If you’ve ever disassembled .NET assemblies, you should recognize the above name as something that is compiler generated. Indeed, this is what happens when one makes use of automatic propeties: the compiler creates a private, anonymous backing field that can only be accessed through the property’s get and set accessors. The private fields are named using the ‘<>‘ syntax in order to prevent any possible conflicts with other fields defined by the developer.

Well, that’s interesting and all, but why were the compiler generated names even coming into play here? Last I heard, the DataContractSerializer handles automatic properties just fine. After much debugging, I finally came to the source of the problem: The Serializable attribute that was applied to each type.

[Serializable]
public class OffendingType : IOffendingType
{
    public int Id { get; set; }
    .
    .
    .
}

We make use of the Serializable attribute when we wish to be able to perform binary serialization on a type. It is important to remember that binary serialization does its job by the direct copying of an object’s memory image. This means that everything about the object, not just its public properties, gets copied. Because of this, the object’s private members are persisted, which includes the underlying compiler generated backing fields.

For the most part, that’s ok, but, as demonstrated by the error shown above, this will horribly screw up the serialization required for dealing with WCF clients/services. In order to resolve the issue, you need to swallow your pride and decorate the types being consumed with the appropriate WCF-specific attributes. In my case, I ended up assigning DataContract attributes to each type, as well as DataMember attributes to all the members of the type I wanted to serialize.

//All better!
[DataContract]
[Serializable]
public class OffendingType : IOffendingType
{
    [DataMember]
    public int Id { get; set; }
    .
    .
    .
}

So, the lesson learned here is: Although you should feel free to take advantage of the DataContractSerializer’s ability to serialize types that do not have the appropriate contractual attributes applied, be aware that this approach does not work when dealing with types that have the Serializable attribute applied.

The company I work for provides resource scheduling solutions, mainly in the form of web and database server software coupled with an Outlook addin client. It is a complex addin that gets deployed to thousands of users in large corporate environments, and it is something I spend a sizeable amount of my time working on.

It is entirely written in old school COM, and has quite a history. Due to various reasons, there has been a strong pull to rewrite the software using newer technologies (.NET). I have recently begun the design and implementation of the new addin, and one of the first things I stopped to take a look at was VSTO.

The motivation for making the technological move lies completely with the ability to use .NET, among other issues with the current incarnation’s design. The ability to use VSTO was not the basis for the move; however, we would have gladly used it if the benefits were high.

I found VSTO to be incredibly disappointing due to a single, yet extremely powerful, reason. This single reason actually has caused me to question Microsoft’s view on addin development in general. Read on for my analysis of VSTO’s crippling fault, and why it makes the platform almost useless (at least for any serious addin development). I will also offer (what I view as) the correct course of action to take in regards to the serious problems caused by this crippling fault.

Read the rest of this entry »

Currently, I’m working on a product I call Alluvial, which aims to be a SQL Management Studio-like program for use with the Azure cloud’s SQL Services platform. While designing the initial login screen, I decided to implement a check box the user could click on labeled “Remember my password”, which (like SQL Management Studio), would remember the username:password between sessions.

When I actually got to implementing this feature, I faced various classic problems that, due to my young years, have not encountered before. The primary problem was: in order to “remember” a set of credentials, one would have to store it somewhere for later retrieval. This is bad, because as soon as credentials get written to disk, even if they are encrypted, you are entering very dangerous waters.

Eventually, I figured out and implemented what I believe to be a secure solution. I’ve created various security libraries you can check out on my source repository; in one of them is a new CloudCredentials class, which provides the developer with secure credentials that can be persisted and used with accessing Azure Cloud Services. I achieved this through the use of the unmanaged Data Protection and Windows Credential Management API’s.

Please read on for some more details.

Read the rest of this entry »

This one took me a bit to figure out.

There were many times where I wanted to bind an element’s property to another’s, but slightly modified. For example:

<Grid x:Name=theGrid>
    <ComboBox x:Name="cbThird"
               Width="{Binding ElementName=theGrid, Path=ActualWidth * 1/3 + 200}"
               />
.
.

The above code snippet is trying to declare that the ComboBox’s width is a third of the grid’s plus an additional 200. Of course, you can’t do this as shown above, and Cider will be quick to catch your foolhardiness. It would appear that your only options would be to do this through the code behind; that would be unfortunate, as you’d have to handle resize events and all that muckery.

Luckily, you can acheive the same effect in pure XAML by making use of Transforms. Below is an example of how you would define the ComboBox’s width to be 1/3 of the grid that it is contained in plus an additional 200.

<Grid x:Name="theGrid">
    <FrameworkElement x:Name="gridTransform" Visibility="Collapsed">
       <FrameworkElement.RenderTransform>
         <TransformGroup x:Name="transformGroup">
          <TranslateTransform X="{Binding ElementName=gridConnect, Path=ActualWidth}"/>
          <ScaleTransform ScaleX="0.33"/>
          <TranslateTransform X="200"/>
         </TransformGroup>
       </FrameworkElement.RenderTransform>
    </FrameworkElement>
    <ComboBox x:Name="cbThird"
        Width="{Binding ElementName=gridTransform, Path=RenderTransform.Value.OffsetX}"
        />

Adjusting the ScaleX attribute will change the width’s multiplicand, while adjusting the X attribute (in the TranslateTransform tag) will adjust the width we’re adding to the result of the multiplication.

A new library by the name of Omniscientist.Cloud.SqlServices.Linq has been created to be used in conjunction with the Omniscientist.Cloud.SqlServices library to allow the use of LINQ expressions with SQL Data Services entities. Basically a LINQ to Azure.

The SqlServices.Linq library provides implementations of IQueryable and IQueryProvider; I found creating the custom query provider to be very interesting, as there’s probably no better way to grasp the concepts of LINQ’s internals.

A gigantic benefit that we gain when using this custom IQueryProvider I created (OmniQueryProvider) is the ability to use LINQ expressions without having to waste performance. This is in contrast to doing a general search for all of the entities and THEN filtering them out with an expression. That’s a horrible use for LINQ. The OmniQueryProvider creates a query that will only return a result set that conforms to our conditions, which allows us to use LINQ without being idiots.

Feel free to browse the source, try it out, or whatever. I’m not going to go into depth regarding how the custom query provider was created. I’d prefer, instead, to just demonstrate how one can use it. Read on for some examples.

Downloads:

Lastest source of Omniscientist.Cloud.SqlServices

Binaries of Omniscientist.Cloud.SqlServices (not guaranteed to be latest)

Read the rest of this entry »

The Omniscientist.Cloud.SQLServices library has been updated to include BLOB functionality. It has also undergone a significant structural overhaul. I still consider it to be in its infancy, but I think it has started to become useful.

A sample application has been developed in order to showcase the new functionality, by the name of ‘Cloud Photos’. It allows the user to upload and view images stored in the cloud; specifically, in a dedicated SQL Data Services container.

Download the ‘Cloud Photos’ sample application binary here. 

View the ‘Cloud Photos’ source code here.

Read on for a brief overview of BLOB’s w/ Azure SQL Data Services, and how to manipulate them with my library.

Read the rest of this entry »

On the flip side of the cloud-coin, we have the Azure .NET Services platform (hell, there’s more than two sides to Azure, but those two are the ones I feel are most noteworthy as of now).

The concept and purpose for the Azure .NET Services platform is rather easy to grasp: It allows you the opportunity to host Windows Communication Foundation-based services on the cloud. Achieving this requires the use of the multiple components that make up the Azure .NET Services platform, such as the Access Control and Services Bus services. Using these services will provide you with a secure intermediary interconnect you can use to provide endpoints for client and server. This allows the developer the ability to spend more time on the service itself, not the additional logic required in dealing with various network topologies.

Much of the Azure .NET Services platform is based on the WCF core libraries, but the use of these assemblies alone are not enough to get the services hosted and working the cloud. There are several Azure .NET Services-specific assemblies that you must become familiar with and use in order to get your service out there. In this article I’m going to go over the use of the Azure .NET Services assemblies, as well as take a general look at how the services work as a whole.

Much like my article on the SQL Data Services end of the cloud, this marks the beginning of the series through which I’ll be developing a library that will be used to get the most out of this service Microsoft is offering.

Read the rest of this entry »

To get your hands on QuickWit, click here for the QuickWit MSI.

Also, be advised that the QuickWit source is where all my other sourcecode is: in my source repository. 

There’s plenty to talk about here, so read on for an overview of the program, and a look at how some of the internals do their thing.

Prerequisites Note: This application communicates with a Team Foundation server, thus it needs access to the Team Foundation API assemblies. I’d be happy to include them as part of the install, but redistribution of those assemblies is not allowed. Therefore, you need Team Explorer 2008 SP1 installed on your system for this to work. For those interested, I am working on something that foregoes the need for these assemblies, and just hits the web services directly.

Read the rest of this entry »