A very interesting announcement came out overnight. Scott Guthrie announced that Microsoft is releasing some of the code of the .Net base class library for the 3.5 framework. License agreement is here with an important note highlighted here. This has only been previously possible with tools like Reflector which is view only and doesn’t allow debugger support.
I have been a fan of hashing data for a while, especially for calculating SHA1 checksum values. Until now, I have always had access to the entire set of data that needs to be hashed. Using the SHA1CryptoServiceProvider makes it so easy to build a hash value. You just throw a stream or a byte array at the ComputeHash method.
What if you don’t have all the data available? Streaming is the classic example here, especially when you are dealing with a stupid amount of data. It is not wise to hold an entire data set in memory if the amount of data is large. In addition to memory issues, buffering the entire data set while streaming in order to calculate a checksum destroys the point of streaming your data.
Using Reflector to checkout the HashAlgorithm implementation, I thought that there wasn’t a way around it as the ComputeHash methods call down to internal methods. After thinking for a while that it wasn’t possible to create hash values from chunks of data, I went back and had a look again. Turns out there are publicly available methods to support this. TransformBlock and TransformBlockFinal are the methods to call. I found the naming misleading which is why I previously overlooked them.
With these methods, you can now stream your data in chunks and build a hash value on the fly without needing the entire data set.
Yesterday I got the opportunity to start playing with WCF net.tcp services hosted in WAS on Windows Server 2008 (Beta 2). There were a couple of hiccups, but it was surprisingly painless.
Firstly, I got the service up and running over wsHttpBinding. One thing I noticed about this is that, unlike XP Pro (and I think Vista), IIS7 on WS2008 doesn’t need anonymous set against the svc file for the service endpoint when the rest of the site was running under Windows Authentication. Straight away, this service was working using a remote client over http.
Next up was trying netTcpBinding. First job was getting the required features installed. This MSDN article provides the details as:
An exception of type ‘System.Runtime.Serialization.SerializationException’ occurred in Neovolve.Framework.Workflow.DLL but was not handled in user code Additional information: Type ‘System.Workflow.ComponentModel.ActivityExecutionContext’ in Assembly ‘System.Workflow.ComponentModel, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ is not marked as serializable.
This was a bit of a curly one.
The problem was caused because one of my custom activities couldn’t be serialized. The custom activity was used in a WhileActivity. Serialization is happening behind the scenes because the WhileActivity uses serialization to create clones of the activities in its loop.
The moral of the story is to ensure that your custom activities can be serialized (or workarounds developed) so that WF persistence and WhileActivities can use them.
I recently posted about some coding standards I have been reviewing. There is another standard that has plagued me where my research doesn’t really offer any solid guidance.
It is the old argument of:
- string vs String
- bool vs Boolean
- int vs Int32
- long vs Int64
The reason I like the String/Boolean option is because the colour coding in the IDE clearly identifies the text as a type rather than a C# keyword. That being said, I still tend to use int and long, but then revert to String and Boolean. One reason that Int32/Int64 is better would be that the meaning of int/long may change with the platform (I think this is right, someone please confirm) whereas Int32 and Int64 have static meanings.
We have been looking at coding standards recently. The hottest topic so far seems to be around the prefix used (if any) of member level variables. The current choices are:
- m_ such as m_Name or m_name
- _ such as _name
- [None] such as Name or name I have my personal opinion which I shall reserve for the sake of this post. Arghhh! Can’t resist. I vote #2.
Which do you align with? Why? Are there others that should be considered?
I’ve been having some issues with WF rules files over the last few weeks. I am using code generation to build some services that use workflow’s in the business layer. The problems start when I run a code generation after editing the workflow rules and want to compare the difference. The result tends to be something like this for what is actually the same content:
This is even a tame example. I have had full color difference indicators before.
Someone at work was kind enough to figure out the correct command line switches to use in order to replace the standard TFS compare/merge tool with WinMerge. I originally blamed Pants for the info, but he then accused Eddie. Here are the goods:
In Visual Studio do the following:
- Click on Tools menu
- Click on Options menu item
- Expand Source Control tree item
- Select Visual Studio Team Foundation Server tree item
- Click on Configure User Tools… button
As I have been writing some SQL Server based software recently, I want to expose a standard way of providing searching capabilities for tables and views. The initial implementation started with a set of WHERE conditions like the following:
WHERE (FieldA = @FieldAValue OR @FieldAValue IS NULL)
(FieldB = @FieldBValue OR @FieldBValue IS NULL)
This post has some good tips for increasing the performance of the VS2005 IDE.