Brant Burnett's Development Blog » .NET Framework

Simplify CSS and Javascript Compression In Visual Studio

Brant Burnett — Tue, 23 Feb 2010 18:35:26 +0000

I’ve released a new open source tool that performs design-time compression of your CSS and Javascript files in Visual Studio projects. This can be a big help, since it allows you to easily do it in your project rather than as part of your build/publish process. And, since it leaves both the compressed and uncompressed versions in place, you can still use the uncompressed version for debugging.

Read more about this new tool or download it at http://btburnett.com/netcompressor.

Create A Self-Signed SSL Certificate In .NET

Brant Burnett — Fri, 08 May 2009 13:50:43 +0000

A problem that I have commonly run into is trying to secure communications using SSL or other encryption for a intranet application. In this scenario, it is unnecessary to have a secure certificate signed by an expensive Internet authority. And often it is intended for deployment in a small-scale scenario where there might not be a Certification Authority running on a Window Server. In this case, you want to create a self-signed certificate and use the thumbprint of the certificate for phishing prevention.

Microsoft does provide a utility, makecert, which can create a self-signed certificate. However, it isn’t distributed with Windows, is command line only, and definately NOT end user friendly. I wanted a method for creating a certificate just by clicking a button, without using a shell calls and distributing a copy of makecert with my applications.

To this end, I created a VB.Net class that calls out to the CryptoAPI and creates a self signed certificate with a 2048-bit RSA key. The certificate and private key are stored in the Local Machine store. In the Local Machine store it can be accessed by system processes and services. I’ve attached an example of the class to this post, feel free to use it as you see fit.

Certificate Creator (338)

Using Enumerations For Columns With LINQ

Brant Burnett — Tue, 05 Aug 2008 13:23:00 +0000

One of the great features of LINQ that DataSets didn’t support well is the ability to use enumerations for your columns instead of integers. It can make writing and working with your code a lot easier. This is accomplished by manually setting the Type of the column to the type of the enumeration in the visual designer.

There are two important notes to remember about doing this. First, it takes extra work if you want to use an enumeration that is in a different namespace from the LINQ classes. You must not only include the full namespace, but also the global:: prefix. So “global::EnumNamespace.EnumTypeName” refers to the enumeration EnumTypeName in the EnumNamespace namespace. Secondly, if you want to update the data structure from the database, you have to remember to manually set the Type back to the enum type from integer.

This system works great most of the time, including when performing LINQ queries in your code. However, the one place it doesn’t seem to work well is in the Where clause of a LinqDataSource. If you try to select on the column values of an enumeration column here, you’ll get various exceptions. If you try to refer to the enumeration constants, you get “No property or field ‘x‘ exists in type ‘y‘. I’ve tried various namespace permutations with no success. If you try to use integers directly instead of enumeration members, you get “Argument types do not match”.

The only solution I have found to the problem is to typecast the column and compare to integers. For example, “Int32(ColumnName) == 1″. Personally, I don’t like this solution much because it can cause huge problems if your constants ever change, but it works.

Also, if you are dealing with a Flags enumeration, it gets even worse. I haven’t found any way to do bitwise operations in the Where clause, so you have to compare the column to all possible integers that contain the bits you are interested in.

If anybody knows of a better way to address this issue, please post a comment and let me know. Thanks.

Event Handlers That Do Thread-Safe Invokes

Brant Burnett — Fri, 11 Jul 2008 10:21:00 +0000

I recently ran into a scenario where I wanted to write a class to do a low-level serial interface to a barcode scanner. When the barcode is scanned I wanted it to fire an event back to the Windows form. The complication was that the SerialPort class provided by .NET 2.0 fires the DataReceived event on an independent thread. In order to fire the event back to the form it needs to be synchronized to run on the thread of the form using the Invoke method.

While this can be done using manual delegates and other methods, they don’t work very cleanly like an actual event handler does for simple development. The fix to this problem is to actually write a custom event handler. The custom event handler implements all of the back end handling that is normally hidden by VB. Here is the example code from the barcode scanner class:

Private _barcodeScannedList As List(Of EventHandler(Of BarcodeScannedEventArgs))
Public Custom Event BarcodeScanned As EventHandler(Of BarcodeScannedEventArgs)
AddHandler(ByVal value As EventHandler(Of BarcodeScannedEventArgs))
If _barcodeScannedList Is Nothing Then
_barcodeScannedList = New List(Of EventHandler(Of BarcodeScannedEventArgs))

End If
_barcodeScannedList.Add(value)

End AddHandler

RemoveHandler(ByVal value As EventHandler(Of BarcodeScannedEventArgs))
If Not _barcodeScannedList Is Nothing Then
_barcodeScannedList.Remove(value)

End If

End RemoveHandler

RaiseEvent(ByVal sender As Object, ByVal e As BarcodeScannedEventArgs)
If Not _barcodeScannedList Is Nothing Then
For Each handler As EventHandler(Of BarcodeScannedEventArgs) In _barcodeScannedList
Dim safeInvoker As ISynchronizeInvoke = TryCast(handler.Target, ISynchronizeInvoke)
If safeInvoker Is Nothing Then
handler.Invoke(sender, e)

Else
safeInvoker.Invoke(handler, New Object() {sender, e})

End If

Next

End If

End RaiseEvent

End Event

The _barcodeScannedList simply stores a list of all of the event handlers that have been registered with the class. AddHandler and RemoveHandler do the process of actually adding and removing those event handlers from the list. The real meat is in the RaiseEvent handler. Instead of simply iterating through the list and firing all of the event delegates directly like the standard handler does, this handler tests to see if the target class of the delegate implements the ISynchronizeInvoke interface. System.Windows.Forms.Control does implement this interface, meaning that all Forms implement it. If this interface is found, then the interface’s Invoke method is used instead of the delegate’s Invoke method. This will synchronize the call onto the delegate’s target’s thread.

Forcing 32-bit Execution in .NET

Brant Burnett — Tue, 03 Jun 2008 09:55:00 +0000

Sometimes when developing .NET applications it becomes necessary to force an application to run in 32-bit mode, even on a 64-bit processor. One scenario that I’ve run into is when you’re using Crystal Reports embedded in the application. I’m not sure about newer versions, but for Crystal Reports XI R2 it won’t work in 64-bit mode.

In order to get something like that to work, you must force 32-bit execution on the executable. Forcing it on a DLL assembly in your application won’t help, then it won’t be able to load that DLL either. It needs to start in 32-bit mode from the beginning. If you can make the change in the development environment before compilation, just set the flags on the assembly there and everything will be great.

However, if you need to make the change to a compiled assembly it’s a little more difficult. To do so, use the corflags command-line utility. This program is included in the Windows SDK. To do so, simply run “corflags program.exe /32BIT+”.

If the assembly is strongly-named, then you must do a little more. First, you must add a /force flag, running “corflags program.exe /32BIT+ /Force”. Then, you must rehash and resign the assembly, using “sn -Ra program.exe key.snk”. In this case, key.snk is your key file for signing the assembly.

Hope this helps!

Using Transactions With DataSets

Brant Burnett — Tue, 25 Mar 2008 08:42:00 +0000

One of the major shortcomings of the ADO.NET dataset system, in my opinion, is the lack of support for transactions. In .NET 2.0 this situation was somewhat addressed by the addition of the System.Transactions namespace. However, this namespace has two flaws when it comes to using it with a DataSet. First, if you open more than one database connection within the same TransactionScope, it will use the Distributed Transaction Coordinator (MSDTC) instead of more efficient and configuration free database transactions. Second, if you require backwards compatibility with SQL 2000, it will ALWAYS use the MSDTC even if you open just a single database connection. The first issue can be addressed by opening the connection in advance and passing it to each TableAdapter that you use. Note that you’ll need to change the Connection property on the TableAdapter from Friend (internal) to Public in the DataSet designer if the DataSet is in a DLL.

The second issue is a bit trickier to solve. In this case, you also need to open a single database connection as before, but then use an old fashioned SqlTransaction instead of the System.Transactions namespace. Then both the SqlConnection and SqlTransaction need to be set on each TableAdapter. This can be done by adding a special helper function to the partial class for the TableAdapter, as shown below.

Namespace DataSetTableAdapters

Partial Class TableAdapter

Public Sub SetConnection(ByVal cn As SqlConnection, trans As SqlTransaction)
Connection = cn
For Each cmd As SqlCommand In Me.CommandCollection
cmd.Transaction = trans
Next
Adapter.UpdateCommand.Transaction = trans
Adapter.InsertCommand.Transaction = trans
Adapter.DeleteCommand.Transaction = trans
End Sub

End Class

End Namespace