I came across this post about the direction of ReSharper for VS2008 via a Scott Guthrie post. It is good to hear where ReSharper is going now that VS2008 has been out for a couple of weeks.

I am using VS2008 with a ReSharper beta and for the most part it is working fine. I have read about people having many problems with the beta, but I haven’t had that many issues. I think a buggy ReSharper is certainly better than no ReSharper. I tried going back to VS refactoring and it was so unproductive.

I find it unfortunate that some people are giving the ReSharper team a hard time for not getting a new version out sooner given that VS betas have been around for quite a while. Perhaps they have no idea how much work would be involved in developing and testing something like ReSharper. Maybe they also haven’t heard about work/life balance. Those kinds of negative comments don’t help developers motivation to get the work done.

I am looking forward to the next ReSharper version. Obviously sooner is better than later, but stable and reliable is better than sooner. [:)]

This was an interesting one. I just installed Orcas Team Suite Beta 2. I would have assumed that Team Suite was the complete package. Everything I needed. Nope, not quite. Team Explorer is missing.

To get Team Explorer, you have to run the setup package for Team Foundation Server in order to then install the Team Explorer client software. Does this sound right. Having to run a server installer to get access to client software???

A sure sign that I haven’t blogged recently is that Windows Live Writer has dropped off my recent programs in the start menu.

Anyway, I have seen this first set of content before (perhaps even blogged it), but it is worth including again as I have found another set of information for VS performance. Here are the goods:

http://dotnettipoftheday.org/tips/speedup_visual_studio.aspx

Using the InternalsVisibleTo attribute is great for allowing unit tests in an external assembly to directly call types and methods marked as internal. The problem for strong named assemblies is that you need to specify the public key of the unit test assembly in the attribute declaration. I found that David Kean produced a little utility app to make life easy. Thank you very much!

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=3.0.0.0, 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.

Jon Flanders posted some great entries about AEC and serialization (here and here).

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.

Any thoughts?

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:

1. m_ such as m_Name or m_name
2. _ such as _name
3. [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?