A .NET Cryptography Primer

Found A .NET Cryptography Primer on State Street Gang blog. It is a four-part article:


XAML Serialization

I am using XAML serialization instead of XML serialization more and more – IMHO it is much nicer and natural. There are few things to remember though, and XAML Serialization FTW does excellent job in enumerating those, although the list is not exhaustive.

VS2008 SP1 WPF Designer Hotfix

Microsoft released a hotfix for Visual Studio 2008 SP1 WPF Designer. Following issues have been fixed:

  • When a resource in an external resource dictionary is updated, Visual Studio 2008 crashes.
  • WPF Designer cannot load read-only attached properties, such as the VisualStateManager. VisualStateGroups property.
  • If users or codes set a data binding locally, and then the users or codes clear the data binding, WPF designer reports the following error message: ‘System.Windows.Data.Binding’ is not a valid value for property.
  • If a Win32 project is set as the startup project, WPF Designer cannot load solutions in Visual Studio 2008 or in Visual Studio 2008 Service Pack 1.
  • When you set and then delete the Source property of a WPF WebBrowser control, Visual Studio crashes.
  • When you move a control that uses the MultiTrigger class or the DataTrigger class in the Style class, WPF Designer may generate an InvalidCastException exception.

The package can be dowloaded directly from the MSDN Code Gallery. This hotfix is not needed and you must not install it if you have Silverlight Tools for Visual Studio 2008 SP1 (or plan to install it).

Buffer Management for Networked .NET Applications

Found TCP: Buffer Management and related Async Sockets and Buffer Management and Async Sockets and Buffer Management [CTD] articles on Greg Young’s blog. These articles describe the problem and show the solution:

When you call BeginReceive/BeginSend on a socket, the memory that you pass to the method will be pinned for the duration of the call. This will lead to heap fragmentation and to make matters worse it will often be in your gen0 heap if you aren’t careful. This becomes especially true in the most common socket applications (request/response) as BeginReceive is often called and waits for a long time to receive data (by long time I mean a few seconds or more).

The blog itself is interesting on its own.

.NET 4 Code Contracts

Note My opinion is not based on some kind of “attachment” to Spec#. Everything I know about Spec# and Code Contracts I know from public sources, and myself I have not used either of these technologies.

Nowadays, a lot of time is spent by Microsoft people telling us how cool the new .NET 4 will be (if I would be in bad mood now I would say that they should f$#@ng go and fix .NET 3.5 SP1 as well as billion other broken things they already have before starting to work on “newer and more improved” stuff). Three most prominent features talked about are support for dynamic languages, addition of the dynamic type to C#, and something called Code Contracts. While I do not have anything to say about dynamic languages (as I do not use them, and, to be honest, do not see much value in them, but this is completely irrelevant to this post and in general – I am not interested in flaming here), and about the new dynamic type in C# (which by the way is not bad, but I am a bit afraid of the extent of its potential misuse), I do have an opinion about the Code Contracts.

Microsoft Research has technology called Spec#. It is fairly stable and developed programming system that consists of programming language, its compiler, and static program verifier, and allows design-by-contract approach (I would say much like that of Eiffel, or even more powerful) among other offered features. Spec# team says, “A unique feature of the Spec# programming system is its guarantee of maintaining invariants in object-oriented programs in the presence of callbacks, threads, and inter-object relationships”. Spec# language is similar to C# (well, it is C# with some extensions indeed, and there is even “C# compatibility mode”, so that Spec# program can be compiled by “normal” C# compiler).

So, what’s the deal? Instead of sticking to Spec#, and finalizing its development and support in tools (especially that Spec# was really warmly accepted by development community), Microsoft invented the Code Contracts. And nothing would be wrong if it would offer anything new or improved compared to Spec#. Unfortunately, quite contrary, it is really big step backwards. The biggest problem in the Code Contracts, as I see it, is that contracts are specified in the method bodies, completely missing the whole point of design by contract how it is understood by e.g. Eiffel or Spec#. For example, how in heaven are you going to specify contracts for interfaces? (you cannot have method bodies in interfaces, right?) Of course, Microsoft guys will come with some ugly trick/hack here, and will allow contract specifications in interfaces, but how ugly that solution will be?

Then, there come aesthetic factors, closely related to code readability. A quick demo…

   string GetDescription(int x)
      Contract.Requires(x > 0);
      Contract.Ensures(Contract.Result() != null);
      return SomeString;

That was Code Contracts. Yay, how beautiful! (NOT!!!!!) Compare to the same in Spec#:

   string! GetDescription(int x)
      requires x > 0;
      return SomeString;

First of all, here the contract is clear from the method declaration, and there is no need to read the method body to get it. Notice string! syntax which specifies non-nullable string (all types can have ! added to them to specify that declared objects cannot be nulls) and eliminates the need for Ensures clause, and then clean and concise requires x > 0 clause. That’s it! Nothing more is needed!!! And here is a bit more elaborated sample, which shows both requires and ensures clauses:

   void int BinarySearch (int[]! a, int value)
      requires a.Length > 0;
      ensures result < a.Length;
      ensures a[result] == value;

Cool, isn’t it? Add to it invariants:

   class Word
      private string! line; int start, length;
      public string ToString()
         return line.Substring(start, length);
      invariant 0 <= start && 0 <= length;
      invariant start + length <= line.length;

ability to specify contracts on interfaces (look at those forall and old things!):

   interface IList
      int Count { get; }
      T this[int i] { get; }
      public void Add(T x)
         ensures Count == old(Count) + 1;
         ensures forall{int i in (0:old(Count)); this[i] == old(this[i])};
         ensures this[old(Count)] == x;

and other nice and powerful features, and you have really nice development environment that simplifies your life and helps you to write verifiable and correct code. But no! That would be way too simple and way too good, and instead we will get ugly Code Contracts. AAAaaa!!! I want Spec# baaaack!!!!

Now, as I said in the beginning of this post, I do not have hands-on experience with either of these technologies. But I believe that being more or less 20 years in the software development business is giving me enough experience to make a “high-view” judgment on technologies based on minimal data and “6th sense” (or gut-feeling, or instinct, or …). And my 6th sense is telling (yelling?) me that Code Contracs as they are proposed by Microsoft are not something that I will ever become excited about (as opposed to Microsoft’s Spec#).

Webcam Control with WPF

Webcam control with WPF or how to create high framerate player with DirectShow by using InteropBitmap in WPF application by Tamir Khason shows how to do exaclty what it claims to show :) in a way alternative to what Jeremiah Morrill is proposing (now, I do not have an opinion as of which is better or worse – they both have their uses).

Side Note Unfortunately, you cannot play decent quality video in WPF application (meaning in WPF “airspace”) no matter what you do – it has to do with non-constantness of the WPF rendering frame rate (and, on XP, add here WPF tearing artefacts), and I do not see how it can be fixed in the future as this problem is rooted extremely deeply in the core of WPF rendering pipeline. Microsoft knows about this issue, but does nothing to fix it.

Visual Studio Productivity

It is impossible to use Visual C++ 2008’s IDE, as nothing really works there – no IntelliSence, no refactorings, nothing. The same sad story can be told about the Visual Studio’s XAML editor – it just sucks (by the way, you get much better experience by using Visual Studio’s XML editor to edit XAML files). So, finally I got really tired of this, and decided to do something.

I went through quite many packages, and settled down on two – Visual Assist X for Visual Studio by Whole Tomato ($249 retail) and ReSharper by Jetbrains ($349 retail, although Euro price is 315€, weird).

Visual Assist X is super-great for C++. In fact, it is “Visual C++ IDE made right” kind of tool – fixes all problems existing in VS and adding a lot of nice extra goodies that can really improve your productivity: working IntelliSense, refactorings, code outlining and browsing, searching for symbols, code coloring, etc. etc. etc. Some of the abovementioned features are available for C# and VB.NET as well.

ReSharper is doing similar things for C#, VB.NET and XAML, as well as for ASP.NET, XML, MS Build scripts and NAnt. Finally you can browse XAML files and have the ability to quickly jump to referenced resources!

So far so good. These tools can work together on one Visual Studio 2008 setup seemingly without major issues. The only bad thing I have noticed is their “competition” for IntelliSense in C# – both are showing their pop-ups and it is a bit annoying. This problem is not seen in XAML, as VAX is not supporting XAML, and in C++, as ReSharper is not supporting C++. So far I couldn’t resolve this issue, as I do not see any configuration settings that would allow me to switch off IntelliSense for C# in one tool or another. In the end of the day, it is not major issue and I should say these tools work very well together.

I do not understand, why Microsoft cannot do something similar to what these tools are doing straight out of the box? If Microsoft’s team cannot do this on its own (because they are busy developing one more piece of useless fancy marketing crappy feature), then I do not get why they cannot buy e.g. Whole Tomato? If they were ready to waste billions on Yahoo (which would give them what advantage? and please, do not tell me about advertisement business – I do not understand why Microsoft being software house should go to Internet business “just because”), then they should rather spending miniscule fraction of that cost and get real boost for all the developers that use their unfinished tools and technologies (WPF, VS2008, Blend, you name it). Just my 2 cents…

UPDATE The abovementioned issue with conflicting IntelliSense pop-ups can be partially resolved by switching off IntelliSense support in ReSharper (Options… and then Environment > IntelliSense > General page).