We finally got a useful response concerning the TransactionScope Timeout problem. Someone else had a similar issue and started a new thread in the Microsoft forums: http://forums.microsoft.com/forums/ShowPost.aspx?PostID=3069149&SiteID=1. The issue has been resolved, but only as of the .NET Framework 3.5. There is a new connection string parameter named "Transaction binding". This is set to "Implicit unbind", which by default causes the described (mis-)behavior. Instead, you must set it to "explicit unbind", so that queries issued after the transaction times out are still considered to be INSIDE the transaction and not in auto-commit mode. You can read the details in the forum post.

Alas, this only solves the problem when using the SqlClient ADO.NET provider. For all other transactive repositories, the issue still exists.

Microsoft changed the rendering engine in Outlook 2007 to Word's HTML-engine, and it really sucks concerning modern design habits (css-positioning, etc.). So you have to look out for some pitfalls. I found a nice guide for designing HTML-Mails for use in Outlook 2007, which can be found at http://www.duoconsulting.com/downloads/contribute/SevenDesignTipsforOutlook2007.pdf.

Also, Microsoft offers tools to validate HTML files for the Word rendering engine. These can be found at http://www.microsoft.com/downloads/details.aspx?familyid=0b764c08-0f86-431e-8bd5-ef0e9ce26a3a.

So, good luck with your e-mail marketing ;-)

If you've ever built an ASP.NET application using a User Instance database, you may have come across the problem, that you would have liked to access the database using the Management Studio or similar programs, but just couldn't find the database, because it is in the user instance and not in the database server itself.

I'd like to issue my thanks to Mike of the Sql Server Express Weblog for publishing how it's done. I looked for hours trying to get the database attached to the regular server, but all that is not neccessary. You can directly connect to the user instance by using a named pipe. The original explanation can be found here: http://blogs.msdn.com/sqlexpress/archive/2006/11/22/connecting-to-sql-express-user-instances-in-management-studio.aspx. Below are the required steps in short.

• Connect to the server normally.
• Issue a new query:
  SELECT owning_principal_name, instance_pipe_name, heart_beat FROM sys.dm_os_child_instances
• Locate the user instance you wish to connect to and copy the instance_pipe_name column's value.
• Open a new server connection and use the copied value as the server name.

And presto, you can access everything as you would in the regular server.

Note: The pipe name is generated, when the user instance is first created. After that, it will always remain the same, so you can store it for later use. Access is only possible, when the user instance is active (see the heart_beat column). If it is not, you must first launch the application that uses it (i.e. the web site).

When working with several POP3 accounts, it can be a real pain to always have to enter every single account when you reinstall outlook or have to switch profiles or simply have multiple computers. Other mail clients have an option to export account settings, Outlook doesn't. Bummer...

I ran into the Office Resource Kit, which at least helped a bit by enabling me to create a custom .prf-file. The accounts specified in the file can be used to create a new Outlook profile. A set of instructions on how to do this can be found at http://support.microsoft.com/kb/308300. When you've created your .prf file, you can set up your accounts on any machine by simply starting it. Hurray for automation :-)

When connecting to an exchange account for the first time, it sets up all default folders. This is done using the language of the connecting client, which may result in an unexpected layout. This happened to me, leaving me with english instead of german folders.

This would not have been such a problem, but I wanted to import my structure from a previous account. No problem importing things, but they went into new folders with the german names. Now I had two contact folders, two mailboxes, two calenders, everything was there twice, and the empty ones were the defaults...

At first, I was told, the account would have to be reset completely, wiping out all data already imported. But, actually there is a much simpler way of changing the folder names to the desired language. Simple start the Outlook of your desired langauge from the command line specifying the following parameter:

outlook.exe /resetfoldernames

Presto, everything is in your language. Now importing is a lot more fun because you can actually use the imported data.

Today, I got a new Exchange account to replace my existing one. After copying everything, I only had to get my Xda neo to sync with the new account. This did not prove to be that easy, as simply changing the configured account led to interesting errors. Not only would ActiveSync always give me an error, it also produced errors in my PIM's contact list. It would show all contacts for a split second, then only show about half of the contacts. I tried to remove them all, but was only able to remove those shown. The others remained and broke the synchronization process.

So, how do you solve this, you ask. I don't know, if this is the best way, but it was the only one I found and that solved my problems without having to hard-reset my device:

1. Rename the file 'pim' to anything else and restart your PIM. This will clear all contacts, calendar entries, tasks, etc. If you don't sync all these items, you should probably make a backup first!
2. Remove the mobile device from the ActiveSync connections
3. Create a new connection to the PIM and start syncing with the new settings

I realize, this is not very comfortable, but at least it works and leaves the rest of your device intact (i.e. installed programs, customized sounds, etc.).

While I was building an ASP.NET user control, I ran across the problem, how to serialize a property as the inner text of the Control in the ASPX-Code. I found a nice attribute named PersistenceModeAttribute, that allows you to specify, how a property is supposed to be persisted. Setting it to InnerDefaultProperty or EncodedInnerDefaultProperty should do the trick, I thought.

But, as I had to find out, this is only part of what needs to be done. There are two more Attributes, that control the parsing of a control: ParseChildrenAttribute and PersistChildrenAttribute. When you use InnerDefaultProperty to persist a property, you must add [ParseChildren(true, "<YourPropertyName>")] and [PersistChildren(false)] to your control's class declaration. Otherwise things won't persist.

It took me a while to find this solution, and I found a nice explanation of things here: http://alvinzc.blogspot.com/2006/10/aspnet-basic-of-custom-server-control_25.html.

Alvin did a really nice job of explaining, what the attributes do. So if you want the details, just visit his blog.

For the time being, I have built myself a helper class, that tries to fix the "timeout-bug" when using TransactionScope. And since I'm such a nice guy, I decided to let everyone have it ;-)

So here goes, completely commented including a usage example:

using System;
using System.Threading;
using System.Transactions;

namespace Succell.Framework.Utils
{
    /// <summary>
    /// This class is used to abort transactions when the timeout occurs.
    /// </summary>
    /// <remarks>
    /// <para>This class is required, because TransactionScopes do not abort processing, when they expire. Instead
    /// all actions done after the timeout occurs are not included in the transaction, but instead carried out
    /// normally. This can lead to inconsistencies in your data, when processing large amounts.</para>
    ///
    /// <para>This class can be used nestedly, i.e. methods called in the supplied working delegate can safely
    /// create instances of this class.</para>
    /// </remarks>
    /// <example><code>
    /// try
    /// {
    ///     using (TransactionScope ts = new TransactionScope(TransactionScopeOption.Required, new TimeSpan(0, 0, 2)))
    ///     {
    ///         new TransactionHelper(ts, delegate() {
    ///                 // do transactive work here
    ///             });
    ///         ts.Complete();
    ///     }
    /// }
    /// catch (TransactionAbortedException tae)
    /// {
    ///     // handle aborted transaction
    /// }
    /// </code>
    /// </example>
    public sealed class TransactionHelper
    {
        /// <summary>
        /// A tagging object to determine, whether the thread is aborted due to a transaction timeout
        /// </summary>
        private object _abortObject;

        /// <summary>
        /// The current thread executing the transactive work
        /// </summary>
        private Thread _currentThread;

        /// <summary>
        /// Creates a new TransactionHelper that executes transactive statements and aborts the process
        /// if a timeout occurs.
        /// </summary>
        /// <param name="toExecute">The delegate to call for processing</param>
        public TransactionHelper(ThreadStart toExecute)
        {
            if (null == toExecute)
                throw new ArgumentNullException("toExecute");

            // get current transaction
            Transaction tx = Transaction.Current;

            if (null == tx)
                throw new InvalidOperationException("You must create an ambient transaction before using the TransactionHelper");

            // Don't execute, if the transaction is already aborted
            if (tx.TransactionInformation.Status != TransactionStatus.Aborted)
            {
                // keep handle to current thread for aborting
                _currentThread = Thread.CurrentThread;

                // register completion handler
                tx.TransactionCompleted += new TransactionCompletedEventHandler(Current_TransactionCompleted);

                // execute transactive code
                try
                {
                    toExecute();
                }
                catch (ThreadAbortException tae)
                {
                    // was the thread aborted by our TransactionCompleted handler?
                    if (null != _abortObject && tae.ExceptionState == _abortObject)
                    {
                        Thread.ResetAbort();
                    }
                }
                // unregister completion handler (required when using multiple TxHelpers in one transaction,
                // otherwise multiple ThreadAbortExceptions are thrown on timeout)
                tx.TransactionCompleted -= new TransactionCompletedEventHandler(Current_TransactionCompleted);
            }
        }

        /// <summary>
        /// Transaction completion event handler, that checks, whether a timeout occured
        /// and, if so, causes the registered executing thread to abort
        /// </summary>
        /// <param name="sender">The originating transaction</param>
        /// <param name="e">The event args for this event</param>
        void Current_TransactionCompleted(object sender, TransactionEventArgs e)
        {
            // Is the transaction aborted (possibly due to timeout)?
            if (e.Transaction.TransactionInformation.Status == TransactionStatus.Aborted)
            {
                // Is the executing thread registered?
                if (null != _currentThread)
                {
                    // generate a new abortion tagging object
                    _abortObject = new object();

                    // abort the executing thread
                    _currentThread.Abort(_abortObject);
                }
            }
        }
    }
}

I hope, this helps some of you. Of course, I'll be updating my blog, as soon as some notice of how TransactionScope is supposed to be used reaches me. I know, that ThreadAbortExceptions aren't something to use lightly, but currently I see no other way.

Someone has finally found a dirty, yet working solution to the TransactionScope problem. You can register an event on the transaction, that fires, when the transaction finishes, which also happens on a timeout. You can then abort the main thread, to keep further commands from executing.

And this is also the dirty part: ThreadAbortExceptions are a little dangerous and can cause unexpected behavior. But for now it works for me, and as long as Microsoft does not come up with a better solution, I'll have to use this.

You can find more details here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=876150&SiteID=1

Happy Halloween everyone!

Today I'll tell you about some problems I've been having with the TransactionScope class. Namely, I've had timeouts running out, but the application still running the nested queries until they were finished. Amazingly, the data seemed to be in the tables, although the TimeoutException was thrown.

This has now happened to me in multiple applications. But today I read an article on the System.Transactions namespace (http://msdn.microsoft.com/msdnmag/issues/06/11/DataPoints/default.aspx).    There the author states, that you should open the database connection INSIDE the TransactionScope. This becomes logical, when you know that there is also a parameter you can add to the connection string named "auto-enlist" defaulting to true, that tells ADO.NET to look for an ambient transaction when connecting. So, if you open the database connection and then open a TransactionScope, the database does not seem to care about the ambient transaction.

I haven't tried yet, if this solves my problems. But since this is quite an important matter, I wonder why Microsoft does not point this out clearly. The TransactionScope may be a really great invention, but if you don't know how to use it, it causes damage instead of making things safer.

[Update]: This did not fix the problem. Instead, I built a test-app containing both a method, which first opens the database, then the TransactionScope, and a method doing it the other way around. Both methods have the same result. And that is VERY disappointing: The changes to the database made during the Transaction's non-timeout-ed period are rolled back, all changes AFTER the transaction times out are committed. I've written a post in the MSDN-Forum concerning Transactions Programming (http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=876150&SiteID=1). Let's see what they come up with.