When creating a new Silverlight business application using RIA services, it will automatically be configured to use Forms authentication. If you are developing an intranet application with single sign-on, you can easily switch the web.config to use Windows auth instead of forms. In my case, authentication still timed out, because the server still tried to access a database. You also have to disable the RoleManager and Profile services in the web.config to get Windows authentication running. This is a nice way to create out-of-browser intranet applications and still have single sign-on.

I just launched a new project at codeplex aiming at the integration of jQuery UI in DotNetNuke: http://jquidnn.codeplex.com/. The first releases are already available in form of DNN module packages containing the core functionality, including infrastructural code to include jQuery and jQuery UI, two web controls for the Tabs and Datepicker widgets, and the smoothness theme.

Also available are module packages for three more themes: Cupertino, UI Darkness and UI Lightness. Further skins are actually quite easy to package and will follow over time, or when someone issues a request for one ;-)

So please, start grabbing the releases and giving me feedback.

I just wasted another hour, trying to figure out, what exactly ASP.NET was trying to tell me, when giving me an "ASPNET: Make sure that the class defined in this code file matches the 'inherits' attribute, and that it extends the correct base class (e.g. Page or UserControl)." message on compiling my ascx file.

Ok, so I used a custom namespace, but I've done that hundreds of times, so that shouldn't be the problem. I also had a custom base class inheriting from UserControl. Also, nothing I haven't done before. So what was the issue now?!

I basically retyped everything concerning the namespace and class names in all files, but nothing helped. So I reverted to commenting out my code. This helped me find the issue: I used a

<% if (somethingOrOther) { %> Some code here <% } %>

construct in my ascx-file (Please don't start an argument on whether this is good practice or not. I know it's not the cleanest way to do things, but that is not the concern here :-) ), and actually forgot to put in the closing <% } %>. Ok, my fault, but shouldn't you get a better Compiler message than "ASPNET: Make sure that the class defined in this code file matches the 'inherits' attribute, and that it extends the correct base class (e.g. Page or UserControl)."?!

So, if you encouter this error (and believe me, I've had it more than once due to typos), and are 100% positive you've spelled everything correctly, check for unbalanced parentheses!

Yesterday, I had one of those WTF moments. I had a page with a form for entering two addresses. Both had the same fields, including a RadioButtonList with identical items. Since the items are resourced, I decided to optimize the performance by reusing the ListItems like so:

ListItem[] items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation.Items.AddRange(items);
this.salutation2.Items.AddRange(items);

Simple eh. Everything seems to be ok. And was I amazed, when I tested it, and I always got the SelectedItem to be the one selected in salutation2. I double-checked every location were I was storing the values, in case I forgot to change the field name after copy/pasting. But everything was correct, as far as I could tell. I even checked the values submitted by the browser, they were also correct.

Finally, it hit me: The ListItem has a Selected property, and it is used to find the RadioButtonLists SelectedItem property. And since I reused the items, the first list parses its items on postback, sets the appropriate ListItem's Selected property to true. Same thing happens with the second RadioButtonList. And since the ListItems are used in both lists, the last one wins.

So, I changed my code to look like this:

ListItem[] items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation.Items.AddRange(items);
items = new ListItem[2];
items[0] = new ListItem(this.GetString("salutation.Mister"), "Mr");
items[1] = new ListItem(this.GetString("salutation.Misses"), "Mrs");
this.salutation2.Items.AddRange(items);

Now everything works as it should. So next time, be careful when reusing your ListItems!

Yesterday, I wasted a few hours trying to upgrade my SQL Server 2005 installation to 2008. Actually, upgrading is a simple process. You can simply select, which instance to upgrade, and the installer does the rest. It worked absolutely fine for my regular instance. I got some installation errors for a component, but didn't mind that at first. Everything seemed to be working.

At least I thought so, until I noticed, WHAT component got the errors. The SQL Server Management Studio was not installed. And the older 2005 version isn't able to connect to 2008. Bummer.

So I thought, let's try to reinstall it. Same error: "The error code is 2349." When you copy the details to the clipboard, you at least find the URL http://www.microsoft.com/products/ee/transform.aspx?ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=10.0.1600.22&EvtType=0xF45F6601%25401201%25401, that gives you the information, that the SQL Server Native Client is causing the trouble.

So I tried upgrading my SQL Server Express instance, but that was also dismissed with an error. Next, I uninstalled my SQL Server 2005 express instance, uninstalled the native client, and now added the Management Studio feature to my SQL Server 2008 instance. Same error, this is really getting frustrating.

So now, my last resort is to uninstall the whole d*rn thing and try to reinstall it. At least the installation only takes about 2 hours *cough*.

UPDATE: Even the complete uninstall did not help. As the error message states, the Native Client is supposedly not installed from the sqlncli.msi package. Well, I even uninstalled and reinstalled ONLY THAT package, to no avail. I'm still getting the same bogus error, when I try to install SSMS. Any help is welcome! I'm out of ideas.

But at least I'm not all alone with my ss2008 install problems. A friend of mine had other issues, but at least he was able to resolve them: http://www.entwicklungsgedanken.de/2009/01/28/installation-problems-with-sql-server-2008/comment-page-1/#comment-252.

UPDATE 2: I have found out, that it's the Visual Studio Tools for Applications 2.0 installer, that is causing the problems. But I still have no idea why.

UPDATE 3: Rollback all rants :-) I found the issue. A file could not be replaced/updated by the installer. This was due to the fact, that my hard disk seems to be defective. The file could not be read, even less replaced. After renaming it, the installation went fine. So now, I have performed a scandisk, the errors have been cleared, and everything is in order. Guess I'll be backing up more often now, though.

I just ran across a really nice article describing how to create a self hosted WCF service using HTTPS bindings. It's a nice step-by-step instruction on how to create your own certificates, adding them to your store, configuring the Windows HTTP runtime, and configuring your WCF service. You can find the article on CodeProject at this url: http://www.codeproject.com/KB/WCF/WCFSSL.aspx. Really nice article, helped me a lot. Kudos to Chris.

Also, Steve Johnson created a nice little GUI for the httpcfg command line tool, which you can find here: http://www.stevestechspot.com/ABetterHttpcfg.aspx. It's a nice addition to the article, so you are not completely bound to the console :-)

Today, I was building a nice little page layout for SharePoint and wanted to use SharePoint DateTimeField control. Since the field I wanted to edit was DateOnly, I set the corresponding property, leaving me with this code:

<SharePointWebControls:DateTimeField runat="server" id="dtfArticleStartDate" DateOnly="true" FieldName="ArticleStartDate" />

Seems fine to me, but ASP.NET did not like it. Or rather, the control did not like it. I got an ArgumentException with the following StackTrace:

[ArgumentException: FieldName value is not specified.]
Microsoft.SharePoint.WebControls.FieldMetadata.get_Field() +150
Microsoft.SharePoint.WebControls.DateTimeField.CreateChildControls() +310
System.Web.UI.Control.EnsureChildControls() +87
Microsoft.SharePoint.WebControls.DateTimeField.set_DateOnly(Boolean value) +29
ASP.MYNEWSPAGE_ASPX__2072755151.__BuildControldtfArticleStartDate()

FieldName value is not specified?! As you can see in my code above, it is indeed specified. But the stack trace gives us more information: The exception occurs in the compiled ASPX file.

• ASP.MYNEWSPAGE_ASPX__2072755151.__BuildControldtfArticleStartDate():
  - We are building my DateTimeField control.
• DateTimeField.set_DateOnly:
  - We are setting the DateOnly property.
• FieldMetadata.get_Field:
  - Getting the field is where the exception occurs.

Note my ASPX-code again: I first set DateOnly="true" and then FieldName="ArticleStartDate". Oh my god, this can't be true... The solution is very simple: change the order of the attributes/properties:

<SharePointWebControls:DateTimeField runat="server" id="dtfArticleStartDate"FieldName="ArticleStartDate" DateOnly="true" />

Against all good practices, the SharePoint team actually created a direct dependency between two properties. At least the stack trace directly tells you where things go wrong, so the solution is obvious. Nonetheless, I thought, this was worth noting. It actually made me laugh, when I encountered it. Another one of those nice little pitfalls when working with SharePoint :-)

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.

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).

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.

The Microsoft Patterns and Practices team published a Service Factory Add-On recently, that enables the Service Factory to also create WCF services. Sorrily, just after the release of the Add-On, the .NET Team released .NET 3.0 RC1, which is not supported by the Add-On.

If you still wish to install it, you can install the Orca tool located in the bin/ directory of the Windows Vista SDK, open the Service Factory WCF installer package, and change the value of the LaunchCondition variable FRAMEWORK30 to the Version of RC1 (3.0.04324.17). Save it and then you can install it.

You can find more information at http://www.gotdotnet.com/codegallery/messageBoard/Thread.aspx?id=6fde9247-53a8-4879-853d-500cd2d97a83&mbid=fc07ebfb-4369-48e1-ab74-d6098ed220fe&threadid=99894479-0335-4a1b-bf91-bf771237cdfb.

Today I was wondering, how you are supposed to use the ToolStripContainer when you want to build an MDI application. I found some solutions in forums speaking about enumerating all controls and finding the MDIClient control, bringing it to the front, and resizing it to match the size of the content panel. But I thought, this is quite a workaround and can't be the way Microsoft meant for things to be done.

A quick search actually ended with the explanation of how you should do it right. There is an article in the msdn library containing a summary of the ToolStrip technology. And in one paragraph, they actually tell you, that there is also a ToolStripPanel component you can use on your form. This component is not present in the toolbox, but you can activate it.

So then you can simply drop as many ToolStripPanels onto your form, dock them accordingly, and leave the content area free for the MDIClient.

For reference: http://msdn2.microsoft.com/en-us/library/a5swc13h.aspx

Sometimes, the developers of the .NET framework seem not to have thought things through. This is also the case with the windows.forms namespace concerning the maximizing of windows. When you have a fixed size dialog, you will probably also disable resizing using the SizeGripStyle property. Furthermore, you'll want to disable the maximize button, either by setting the MaximizeBox property to false, or by hiding the titlebar controls altogether using the ControlBox property.

This is all well, but I've noticed, that disabling all of these things doesn't disable maximizing of windows completely. When you double-click the titlebar of the window, you'll still be able to maximize it, probably making the contents of the form quite ugly. If you REALLY want to disable maximizing, you'll have to handle some window messages.

This is actually not that difficult. All you have to do is override the WndProc method and search for some constants in the windows API. What you'll need here are WM_SYSCOMMAND and SC_MAXIMIZE, both found in winuser.h. Then all there's left to do is implement the method as follows:

    private const int WM_SYSCOMMAND = 0x0112;

    private const int SC_MAXIMIZE = 0xF030;


    protected override void WndProc(ref Message m)

    {

        if (m.Msg == WM_SYSCOMMAND)

        {

            if (((int)m.WParam & 0xFFF0) ==
SC_MAXIMIZE)

            {

                if (this.WindowState
!= FormWindowState.Normal)

                {

                    this.WindowState
= FormWindowState.Normal;

                }

                m.Result = new IntPtr(0);

                return;

            }

        }

        base.WndProc(ref m);

    }

That's it! You've now got a window, that WON'T MAXIMIZE.

If you want a window, that can ONLY be maximized or minimized (as in there's no WindowState.Normal), you will follow the same approach. But you'll find that in an article I wrote on codeproject.com a while ago. If you want all the details, just read them here: http://www.codeproject.com/useritems/DisableNormalWindowState.asp

When using ASP.NET membership, you should always be sure to specify the applicationName attribute on all providers. If you omit it, and deploy your database to the web server, you will find, that all your users have vanished (or at least cannot be found). So make sure your web.config looks similar to this:

<membership>

    <providers>

        <remove name="AspNetSqlMembershipProvider"
/>

        <add name="AspNetSqlMembershipProvider"
applicationName="/" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="LocalSqlServer"
/>

    </providers>

</membership>

After setting the application name, you can start adding users. If you added users before specifying it, they will probably no longer be available.