Posts in category .net - page 14

Publishing .NET applications with prerequisites

Now .NET 3.5 is shipping I took the opportunity to update one of our internal applications and elected to have it install the necessary components (in this case the .NET Framework 3.5) using the Download prerequisites from the same location as my application option.

When trying to install the application via the IIS web server the installer would fail with a download error.

A little testing later I realized the publishing mechanism had placed .msu and .msp files for prerequisites onto the server and of course IIS 6.0 does not serve unknown MIME types.

Both .msu and .msp extensions must be added into the MIME database as application/octet-stream via MMC.

And all was well again.

[)amien

Calculating CRC-64 in C# and .NET

Seeing how the CRC-32 C# class I posted some time ago continues to get lots of Google hits I thought I’d post a CRC-64 version which will no doubt be far less popular being the more limited use. Again, do not use this as a secure message signature, it’s really for backward compatibility with legacy systems.

This is the ISO-3309 version of CRC-64 algorithm. It is not compatible with the ECMA-182 algorithm.

GitHub has the latest version of Crc64

To use this or the CRC-32 class to compute the hash for a file simply:

Crc64 crc64 = new Crc64();
String hash = String.Empty;

using (FileStream fs = File.Open("c:\\myfile.txt", FileMode.Open))
  foreach (byte b in crc64.ComputeHash(fs)) hash += b.ToString("x2").ToLower();

Console.WriteLine("CRC-64 is {0}", hash);

Whilst writing this I considered if I should implement some more advanced hashing algorithms missing from .NET like RIPEMD320 only to stumble across The Legion of Bouncy Castles C# Cryptography APIs which also includes generating PKCS #12 files and a whole bunch of encryption algorithms (but nothing as weak as CRC-64 ;-)

[)amien

Dissecting a C# Application – Inside SharpDevelop

Cover of Dissecting a C# ApplicationThis great book shows you the process, thinking and code behind the open-source .NET IDE SharpDevelop that went on to branch into MonoDevelop.

It was not in print for very long but Apress bought Wrox when they closed down and made the book freely available on its site for download in PDF format.

Alas, with their most recent web redesign their free e-books section has disappeared so I am temporarily hosting it here after recommending it to somebody interested in writing their own syntax highlighting editor on the MSDN forums.

Download Dissecting a C# Application – Inside SharpDevelop (Adobe PDF) (3.8MB)

[)amien

Using GUIDs as row identifiers

Wade Wright is preaching that IDs in a database should always be GUIDs and lists four reasons. I commented there with my opinions but it hasn’t shown up – some people like to censor if you don’t agree with them completely. My points addressing each of his four ‘reasons’ were:

  1. Avoid round-trips when creating new business objects I don’t know about you but I don’t populate my IDs until I persist and not on object creation so this reason is irrelevant.
  2. Data merging is easy Yes, this is a good reason to use GUIDs if you know merging is likely to happen.
  3. Type/table ignorance Basically he says here that a foreign key reference might relate to a row in any table which breaks relational concepts big time.
  4. Some weird anecdote I don’t quite get

He does acknowledge that querying the database by hand is a bit of a pain but underestimates the Guid/uniqueidentifier performance penalty in SQL Server especially with regards to INSERTs (might be able to optimize there by having .NET generate the GUID instead of SQL Server).

He also fails to consider how a page full of GUIDs will bloat out HTML page size especially if they end up used in a number of full drop-down SELECT boxes or collapsible JavaScript tree on a single page although deflate and GZip compression should take care of that if you’ve turned it on.

There are many valid scenarios for using GUIDs as unique identifiers but one size does not fit all using them without consideration will likely lead to somewhere bad ;-)

If you are using them and space is tight such as uncompressed HTML or the GET/POST size down you can write and parse the Guid as Base64 instead of hex format which cuts a Guid of 81187ecf-c452-4550-9ed2-8a51e3c46da1 (36 bytes) to z34YgVLEUEWe0opR48RtoQ== (22-24 bytes) which soon adds up. To do that in C# and .NET simply:

string base64 = Convert.ToBase64String(guid.ToByteArray());
Guid guid = new Guid(Convert.FromBase64String(base64));

For a further squeeze you could use ASCII85 encoding with Jeff Atwood’s ASCII85 implementation in C#.

[)amien