Andreas Zenker

HTTP 301: the zenker has Moved permanently

Thu, 28 Jun 2012 18:01:00 GMT

I have started a new blog recently on my own site. I have enjoyed blogging here and am thankful for the hosting provided by asp.net.

All my future blogs can be found here:

thezenker.com/blog

Thanks for reading

FlowDocument PageWidth, PagePadding and ColumnWidth Oh My!

Thu, 12 Jan 2012 04:18:27 GMT

The ability to create a living, breathing, document right inside a WPF UI is pretty incredible to me. Even after working with it for the last year or so, I am still impressed by the power of this largely forgotten feature of WPF.

One thing to remember about the FlowDocument model is that this is not your Mama’s WPF. The FlowDocument objects inherit from FrameworkContentElement, not FrameworkElement as the rest of the WPF control suite does. So, while the document related controls do inherit the goodness of DependencyObject and can support DependencyProperties etc., they miss the features added by UIElement and FrameworkElement which include little things like Visibility, Height and Width.

FlowDocument elements are meant to, well … flow. They fill the available page width, or the width made available by whatever parent they are constrained by such as a TableCell or Paragraph. So, while FrameworkContentElements may support layout specific properties such as Margin and Padding, if you want to get explicit about Width and Height you are either out of luck, going to embed some UIElements in your document (you cad!) or about to write some custom code to make it happen.

When you insert a FlowDocument into a WPF window you do have some ability to affect the layout of the document as a whole at the top level. So, while a Paragraph does not have a Width or Height property, the FlowDocument does its best to act like a real document and gives you PageWidth, PagePadding and ColumnWidth properties that will affect the overall layout and container size of your document.

PageWidth: this, as it indicates, is the width of the document page. The amount is set in device independent pixels (a pixel is 1/96 of an inch so 1” = 96 pixels). Keep in mind, when setting this value, that the page margin must also be considered.

PagePadding: this name, that is much more fitting in WPF then in document land, is actually the page margin. The amount of pixels (1/96 of an inch) between the edge of the paper and the content. So basically, PagePadding + PageWidth should equal, or at least not be greater than, the paper width. If you have 8.5” wide paper (816 pixels) and you have 1/2 margins (48 pixels * 2 = 96) then you only have 720 pixels to play with for PageWidth. PagePadding is of Type Thickness, so you can set a uniform value that applies to all Margins, or set each separately if desired.

ColumnWidth: This one is not related to the size of the container as much as it is how the content within the container is laid out. As the name indicates, it sets the desired width of the columns of the document. It is only desired since, by default, the layout will adjust the ColumnWidth to make best use of the available width of the page. To enforce your column width setting you need to set IsColumnWidthFlexible = False.

Another gotcha to keep in mind with column width is that the calculation of columns is based on “perceived pressure” of the container. So, just like ScrollBars in normal WPF windows, if you wrap your content in a control that assumes infinite space such as a ScrollViewer, StackPanel, or FlowDocumentScrollViewer the content inside will feel no need to form up columns since it thinks it has infinity to render itself in.

The best way to get a feel for how these properties interact and affect each other is to play around with the options and view the results in the UI. To help with that I have included a sample WPF Window that allows you to dynamically change these values and get real time feedback.

The window xaml:

        1: <Window x:Class="FlowPageLayout"

       2:     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

       3:     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

       4:     Title="FlowPageLayout"

       5:      Width="900">

       6:     <Window.Resources>

       7:         <Style TargetType="TextBox">

       8:             <Setter Property="Width" Value="50" />

       9:             <Setter Property="Margin" Value="10,0,15,0" />

        </Style>

    </Window.Resources>

    

    <DockPanel>

        <StackPanel Orientation="Horizontal"

                    DockPanel.Dock="Top">

            <TextBlock Text="Reader (Paper) Width" />

            <TextBox Text="816" Name="ReaderWidthText" LostFocus="ReaderWidthText_LostFocus"  />

            <TextBlock Text="PageWidth (Pixels)" />

            <TextBox Text="720" Name="PageWidthText" />

            <TextBlock Text="PagePadding (Pixels)" />

            <TextBox Text="48" Name="PagePaddingText" />

            <TextBlock Text="ColumnWidth (Pixels)" />

            <TextBox Text="100" Name="ColumnWidthText" />

            <TextBlock Text="IsColumnWidthFlexible" />

            <CheckBox IsChecked="True" Name="FlexibleChecked" />

        </StackPanel>

            <FlowDocumentReader Name="Reader" 

                                BorderBrush="Black" 

                                BorderThickness="1" 

                                Width="{Binding ElementName=ReaderWidthText, Path=Text, UpdateSourceTrigger=LostFocus}"

                                Margin="20">

                <FlowDocument Name="MainDocument"  

                                      PageWidth="{Binding ElementName=PageWidthText, Path=Text}" 

                                      PagePadding="{Binding ElementName=PagePaddingText, Path=Text}"

                                      ColumnWidth="{Binding ElementName=ColumnWidthText, Path=Text}"

                                      IsColumnWidthFlexible="{Binding ElementName=FlexibleChecked, Path=IsChecked}" 

                                      FontSize="10" 

                                      FontFamily="Arial" 

                                      Background="White" >

  

                    <Paragraph >

                        Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum dignissim accumsan purus, ut faucibus turpis ultricies vel. Phasellus quis orci eu massa vulputate placerat. Nunc congue varius lacus in tincidunt. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Donec ut lorem ante, sed faucibus ipsum. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec pharetra, mauris vitae mollis congue, tortor libero sollicitudin justo, id posuere arcu arcu sed lorem.

                    </Paragraph>

  

                    <Paragraph>

                        Phasellus molestie dui id lorem cursus luctus. Nulla molestie urna vulputate est sodales sed tempus leo posuere. Suspendisse pharetra, odio et eleifend pulvinar, enim felis faucibus lectus, sit amet consequat turpis magna eget nunc. Aenean eget urna quis justo vestibulum rutrum vel non ligula. Donec blandit dolor quis orci vulputate pulvinar blandit diam dignissim. Nam nec sapien magna. Phasellus faucibus urna eu quam fermentum mollis. Quisque sit amet dolor nulla, eget vehicula nulla.

                    </Paragraph>

                    <Paragraph>

                        Nam magna metus, vulputate nec condimentum non, pellentesque in ante. Etiam et enim vel massa semper luctus ac ut quam. Nulla libero nisi, molestie eu lacinia ac, tincidunt non mi. Etiam ornare mi lobortis nunc adipiscing non interdum metus pretium. Morbi felis nulla, dignissim ut blandit vestibulum, euismod ut ipsum. Mauris interdum commodo nisi, vitae pharetra lacus scelerisque eget. Aliquam vel neque nisi. Vivamus consequat scelerisque dignissim. Maecenas lobortis suscipit massa, quis feugiat tortor pulvinar vel. Proin sagittis felis sit amet nunc dignissim semper. Quisque lacinia, tellus sed placerat sagittis, velit justo consectetur est, id aliquam nunc est ac nisl. Curabitur convallis elementum ligula eu ullamcorper.

                    </Paragraph>

  

                    <Paragraph>

                        Suspendisse ac hendrerit enim. Curabitur non lacus sapien, a consequat magna. Mauris tempor, eros ac mollis dapibus, sem lacus facilisis mi, et tristique arcu felis quis ipsum. Nam lobortis, nisl at commodo feugiat, risus enim bibendum odio, quis feugiat libero neque nec quam. Nullam auctor, nibh in sodales adipiscing, tortor odio tristique diam, at molestie lorem eros eget tortor. Cras at velit et lectus malesuada faucibus id sit amet augue. Aliquam rutrum turpis velit. Nunc sit amet faucibus erat.

                    </Paragraph>

  

                    <Paragraph>

                        Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean eu elit a ipsum malesuada imperdiet vitae nec libero. Donec sagittis quam vitae leo consequat id rutrum lacus rutrum. Nullam euismod, velit sit amet porta malesuada, sem libero tempor leo, egestas dignissim diam dolor faucibus massa. Suspendisse vel urna leo, sed vulputate dui. Pellentesque rutrum auctor dolor, blandit lobortis ligula hendrerit eget. In laoreet porttitor mollis. Nam et ligula est. Proin vel nisl quam. Donec posuere, sem a venenatis commodo, lorem massa pulvinar nisi, eget porta quam tellus nec turpis. Donec fringilla tincidunt nibh ut porttitor. Ut lacinia justo nulla. Maecenas ac nisi iaculis metus hendrerit tempus ac vel ante. Aliquam nec erat enim. Aenean turpis turpis, fringilla et auctor id, ullamcorper eget velit. Duis et dui odio, eget tincidunt metus.

                    </Paragraph>

  

                    <Paragraph>

                        Fusce aliquam nisi nec felis aliquam convallis. Pellentesque laoreet molestie nibh, nec cursus sem tempor eu. Donec sit amet purus orci. Pellentesque vehicula neque nec orci pulvinar elementum. Curabitur massa tellus, imperdiet sit amet rutrum ut, posuere porttitor urna. Aliquam condimentum lobortis felis. In sed feugiat ante. Praesent at diam nibh, sit amet blandit lorem. Nam consequat tellus non arcu porta aliquet. Vivamus orci ante, elementum vitae cursus eget, pulvinar nec mi. Curabitur eu lorem justo. Ut facilisis fringilla metus id tristique.

                    </Paragraph>

  

                    <Paragraph>

                        Aliquam sed nibh odio, et cursus augue. Aliquam tempor scelerisque eros, tempor scelerisque orci eleifend quis. Nullam vehicula nunc tortor. Donec id suscipit tellus. Etiam venenatis, ipsum vel porttitor porttitor, mi dui consectetur purus, at consequat nunc elit eget elit. Cras nec nibh sit amet ligula ullamcorper imperdiet. Sed hendrerit tempus eleifend. Sed blandit aliquet pretium. Ut porttitor, lacus quis pharetra imperdiet, neque nisl mollis velit, a dapibus erat lectus posuere turpis. In cursus rutrum erat. Nam mauris nisi, posuere quis mollis non, scelerisque ac sem. Phasellus vitae orci velit, id auctor quam.

                    </Paragraph>

                </FlowDocument>

  

            </FlowDocumentReader>

    </DockPanel>

</Window>

The code behind that resizes the window to stay somewhat in line with the “paper” width

       1: Public Class FlowPageLayout

       2:  

       3:     Private Sub ReaderWidthText_LostFocus(ByVal sender As System.Object, ByVal e As System.Windows.RoutedEventArgs)

       4:         If Me.Reader Is Nothing Then Exit Sub

       5:         Me.Width = Me.Reader.Width + 80

       6:     End Sub

       7:  

       8: End Class

The window allows changing the key properties in real time to test various combinations of settings. The FlowDocumentReader has a border defined, and a margin as well to help isolate the edge of the “paper” and make the document margin more visible.

Visual Studio ViEmu and “the Dark Side” all happy together

Fri, 16 Dec 2011 01:36:00 GMT

So, if you like vi as an editor and you use Visual Studio, pony up the money and get ViEmu. Best money invested in my productivity and ergonomic efforts of this past year, hands down. If you love to hate your mouse you owe it to yourself to investigate ViEmu. There is also another free emulator that is available as an extension from the extensions online gallery called VsVim. However the rest of this blog has to do with configuring ViEmu to work with your particular choice of Visual Studio color scheme.

First choose a color scheme. I recently moved back to a dark theme son-of-obsidian. I usually feel the need to change up the scheme once or twice a year to give my eyes something different to look at. Extra motivation was added in dealing with OpenXml a lot lately and, as a result,parsing and comparing tons of xml files. I found a dark theme in gVim made the xml a bit easier to digest and I wanted to same experience in Visual Studio.

Here is a screen shot of Visual Studio with both an xaml and a vb file open.

I like the overall theme, but right away I see some issues with usability as highlighted by the numbered arrows.

The line numbers are too dark. Whoever created this theme probably doesn’t have line numbers turned on so it would be easy to miss.
The flashing, black on black, cursor is almost invisible.
The default ViEmu search highlight color, yellow, stands out nicely but depending on what content is highlighted, the foreground color may not have enough contrast to be readable. The highlights in the right file fall in string literals and the Orange font comes thru well enough, but in the left file, the White foreground Method name combines with the Yellow to create a retina-searing glare.

Good news is that fixing all of these issues is fairly straightforward and also is a good exercise in learning how to configure the hybrid vim/Visual Studio environment.

Line numbers:

Fixing the line number foreground color turns out to be the easiest of the bunch, as it is just a setting in the Visual Studio Options. Go to Tools >> Options >> Fonts and Colors and look for the Line Numbers item under the Text Editor settings. Pick a custom color that makes you feel better about your line numbers.

Setting the cursor color.

This one is a bit more work. Visual Studio does not expose a setting to change this color. However, vim has options that can be set to change these colors. Vim is configured, in the real vim, using the .vimrc (or _vimrc) file in the program path. ViEmu has its own version of the file called viemurc. The biggest challenge you will face is figuring out just where this file should be created in order for ViEmu to find it when it loads up.

The ViEmu support says to simply save the file to the folder indicated by your HOMEDRIVE Or HOMEPATH environment variables. So, just where, exactly, are they? Well on my Windows 7 machine that equates to “C:\” and “Users\Andreas” respectively. However in my work environment one, or both, of these variables are set to network share paths. To find out for sure what folders are HOME for you, open up a CMD prompt and run the “set” command. This will list the current state of all environment variables.

Now that you know where, create the what. Create a file called viemurc, no extension. Once it is created you can add the following lines that will configure the cursor colors.

        1: highlight Cursor guifg=white guibg=black

       2: highlight iCursor guifg=white guibg=steelblue

       3: set guicursor=n-v-c:block-Cursor

       4: set guicursor+=i:ver100-iCursor

       5: set guicursor+=n-v-c:blinkon0

       6: set guicursor+=i:blinkwait10

Ok, so that takes care of line numbers and cursors, now for the last item:

Vim search highlights:

The interesting thing about this one is that it looks easy at first but doesn’t seem to work. The same options screen we used for the line numbers above also has some ViEmu specific options, all prefixed with ViEmu (go figure). The HL Search Adornment and HL Search Font are what we are looking for.

However, when you update these you will see the background change, but not the foreground. What gives? Seems that ViEmu respectfully defaults to not altering the Visual Studio configured foreground for search highlights and instead just paints an adorner behind the pattern text with the selected background color. That may work for you. If not, you need to turn this “polite” feature off in the ViEmu settings. Under the ViEmu menu in Studio, make sure the “use adornments” checkbox is unchecked and click Ok.

That’s it, now the background and foreground you set for vim searches will be honored.

So, just a few minutes to make peace between ViEmu and a dark Visual Studio Theme.

References:

ViEmu documentation that includes how to set up viemurc file options

Stack Overflow question that shows how to change cursor colors

iOS5 email may need to be redefined

Fri, 14 Oct 2011 23:07:41 GMT

Got my iOs5 update yesterday, mostly cool. However I was unable to send from my Verizon account, kept getting errors like “server does not allow relaying” when I tried to send or reply to mail. I was able to download new mail no problem.

I tried changing authentication settings to no avail. Based on a forum post from the iOs4 upgrade, I deleted the account and set it up from scratch and all was good.

Besides that the upgrade went pretty smooth, still I have to say all the “sell your soul to the iCloud” settings make me feel like I just gave my privacy away but that is another story.

Friends Don't Let Friends Use VS Merge Tool

Fri, 16 Sep 2011 20:05:00 GMT

There are many things that Visual Studio does so well out-of-the-box, and then there is merging conflicts. The built-in merge tool is about as helpful as high beams on your car on a foggy night. The screen is full of information you just can't tell what it means.

Other merge tools, such as WinMerge will make your manual merge experience much more pleasurable and cut down on bad decisions brought about by information obfuscation. Fortunately you can change the defaut merge tool in Visual Studio. The blog entry that I have been using as my guide in this lately is this good write-up

Replace diff/merge tool in Visual Studio Team System with WinMerge | paulbouwer.com

Quote from his blog:

One thing I cannot get used to is the basic diff/merge tool. Where is the detail ? The screenshot below demonstrates the basic nature of the diff tool built into Visual Studio Team System. There is no indication of the number of differences between the files being diff’ed or even the actual differences on a particular line …

Make your head hurt in a good way

Fri, 01 Oct 2010 01:10:24 GMT

I have been just as attentive to blog reading as I have to blog writing and was enjoying some extra-long fix/compile/test cycles today and was able to catch up on Eric Lippert’s blog. All I have to say is: “my head hurts … and it feels great!”.

So much of the content today is “fluffy” for lack of better word. Maybe you have been the victim of the YACPC? (Yet Another Cloud Podcast)

Have you heard? the cloud is wonderful, in the cloud small children never cry, there are no taxes and your cell phone bill makes sense. Everyone, go to the cloud, go to the cloud …. But I digress.

So, amidst all the fluffiness it is nice to have some clever, and even meaningful, content well delivered. If you haven’t been exposed yet I suggest you start with two recent posts:

The Truth About Value Types

Is Is As Or Is As Is

Custom Filter for a WPF TextBox

Thu, 03 Jun 2010 01:36:00 GMT

So, I had a need to implement a TextBox in WPF with auto filtering functionality. For example the initial requests were to limit a TextBox to numeric characters only. This was simple enough. Handle the PreviewTextInput Event and only allow numeric characters to be entered. So my first, simplistic, hack version was simply this:

   1: 'handle numeric only textboxes   2: Private Sub TextBox_PreviewTextInput(ByVal sender As Object, ByVal e As System.Windows.Input.TextCompositionEventArgs) Handles Me.PreviewTextInput   3:    If NumericValuesOnly AndAlso Not IsNumeric(e.Text) Then   4:        e.Handled = True   5:    End If   6: End Sub

Of course, the next request was for a non-numeric TextBox that allowed any character except numerical. So, I could just invert the logic I have shown above. Or, based on a good recommendation from a fellow developer, I could take a few minutes and make the filtering functionality “real” by having a Regular Expression being used for all filtering under the hood and then allow custom Regular Expressions to support those “one-off” situations that will inevitably come up.

So, I added some properties and fields to support the new functionality. A CustomTextFilterRegexPattern String to allow custom filtering. A mode flag to allow the RegEx to function as an “Allow” filter or a “Deny” filter.

   1: Private mTextFilteringRegEx As Regex   2: Private Shared sNumericRegex As New Regex("[0-9]")   3:     4: Private mCustomTextFilterRegexExpression As String   5: Public Property CustomTextFilterRegexExpression() As String   6:   Get   7:       Return mCustomTextFilterRegexExpression   8:   End Get   9:   Set(ByVal value As String)  10:       mCustomTextFilterRegexExpression = value  11:   End Set  12: End Property  13:    14: Private mIsFilterInAllowMode As Boolean  15: Public Property IsFilterInAllowMode() As Boolean  16:   Get  17:       Return mIsFilterInAllowMode  18:   End Get  19:   Set(ByVal value As Boolean)  20:       mIsFilterInAllowMode = value  21:   End Set  22: End Property

Then I added two properties to make defining built-in filters easier.

   1: Private mNumericValuesOnly As Boolean   2: Public Property NumericValuesOnly() As Boolean   3:     Get   4:         Return mNumericValuesOnly   5:     End Get   6:     Set(ByVal Value As Boolean)   7:         mNumericValuesOnly = Value   8:     End Set   9: End Property  10:    11: Private mNonNumericValuesOnly As Boolean  12: Public Property NonNumericValuesOnly() As Boolean  13:     Get  14:         Return mNonNumericValuesOnly  15:     End Get  16:     Set(ByVal value As Boolean)  17:         mNonNumericValuesOnly = value  18:     End Set  19: End Property

Now in the Initialized Handler I wire up to the Paste Command and also set up my internal Regex to match what options have been defined in the XAML.

   1: Private Sub Textbox_Initialized(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.Initialized   2:     Dim pasteBinding As New CommandBinding(ApplicationCommands.Paste, _   3:             New ExecutedRoutedEventHandler(AddressOf OnPasteCommandExecute))   4:     Me.CommandBindings.Add(pasteBinding)   5:     6:     'todo - add check to enforce mutually exclusive settings   7:     8:     If NumericValuesOnly Then   9:         mTextFilteringRegEx = sNumericRegex  10:         IsFilterInAllowMode = True  11:     End If  12:    13:     If NonNumericValuesOnly Then  14:         mTextFilteringRegEx = sNumericRegex  15:         IsFilterInAllowMode = False  16:     End If  17:    18:     If Not String.IsNullOrEmpty(CustomTextFilterRegexExpression) Then  19:         mTextFilteringRegEx = New Regex(CustomTextFilterRegexExpression)  20:     End If  21: End Sub

All that is left now is to handle PreviewTextInput and the Paste Command Execute Handler.

It was easy enough to deny characters in the PreviewTextInput, if the new value did not match the current filter setting then cancel the event by marking it Handled.

For the paste command, however, I needed to process an entire string. The negative filter was easy, any match of a “deny” filter would cancel the paste command. For the positive filter, how could I easily screen a string of unknown length for any characters that did not match the filter Regex. Since the filter was a character filter, would I need to loop thru the entire string and check each value? Then I realized that using the Regex to do a Replace() and set the replace string to String.Empty() would only leave a non-empty string as the result if there were invalid characters in the string.

   1: Private Sub OnPasteCommandExecute(ByVal sender As Object, ByVal e As ExecutedRoutedEventArgs)   2:     Dim toExecutePaste As Boolean = True   3:     If Not mCustomTextFilterRegexExpression Is Nothing Then   4:         Dim pasteText As String = Clipboard.GetText()   5:         If IsFilterInAllowMode Then   6:             'try a replace, if any characters survive the replace then the string is invalid   7:             If Not String.IsNullOrEmpty(mTextFilteringRegEx.Replace(pasteText, String.Empty)) Then   8:                 toExecutePaste = False   9:             End If  10:         Else  11:             'any match on the deny mode filter equals a cancel of the paste  12:             If mTextFilteringRegEx.IsMatch(pasteText) Then  13:                 toExecutePaste = False  14:             End If  15:         End If  16:    17:     End If  18:    19:     If toExecutePaste Then Me.Paste()      20:     e.Handled = True  21: End Sub  22:    23: Private Sub Textbox_PreviewTextInput(ByVal sender As Object, ByVal e As System.Windows.Input.TextCompositionEventArgs) Handles Me.PreviewTextInput  24:    'If filtering is applied and we fail the regex then cancel event  25:    If Not mTextFilteringRegEx Is Nothing Then  26:        If mTextFilteringRegEx.IsMatch(e.Text) = Not IsFilterInAllowMode Then  27:            e.Handled = True  28:        End If  29:    End If  30: End Sub

So now I can implement a TextBox with custom filtering like this:

   1: <myFramework:CustomTextBox  UIProperty="{Binding Path=IntegerValueUIProperty}"   2:                                     CustomTextFilterRegexExpression="[4,5,6,x,y]"   3:                                     IsFilterInAllowMode="True"   4:                                              />

Better than Contains()

Thu, 03 Dec 2009 01:13:00 GMT

Sometimes you wish you could do better than the method you need to use. Case in point: Contains(). It is a fine method and is meant for more than strings. If you need custom logic to decide if two objects are equal or “the same” for the sake of sorting or searching you write your own comparer and pass that in. So, I don’t have anything against the Contains() method for any reason, I only find it a bit too generic when all I have is a list of strings and want to see if I have a match that doesn’t care about case.

I figured LINQ might be a good fit. So I whipped up a simple* LINQ expression. I was able to do a select using a String.Compare() call, then I could pass in the ignoreCase parameter to get my desired results.

     Private Sub CheckIfAllowed(ByVal myTargetPath As String)
        Dim allowedPageList As New List(Of String)
        allowedPageList.Add("Logoff.aspx")
        allowedPageList.Add("AccessDenied.aspx")
        allowedPageList.Add("Login.aspx")

        Dim found = From p In allowedPageList Where String.Compare(myTargetPath, p, ignoreCase:=True) = 0
        If found.Count > 0 Then
            MessageBox.Show("Found")
        Else
            MessageBox.Show("Not Found")
        End If
    End Sub

So, that was pretty cool. The next logical step seemed to be to create an extension for the List(Of String) class.

     ''' <summary>
        ''' Searches the List(Of String) using case-insensitive LINQ query
        ''' </summary>
        ''' <param name="list"></param>
        ''' <param name="value">the string to search for</param>
        ''' <returns>true if item is found. default: false</returns>
        ''' <remarks></remarks>
        <Extension()> _
        Public Function ContainsIgnoreCase(ByVal list As List(Of String), ByVal value As String) As Boolean
            Dim found = From p In list Where String.Compare(value, p, ignoreCase:=True) = 0
            Return found.count > 0
        End Function

So I can have this “new function” available on all List(Of String) instances.

  If allowedPageList.ContainsIgnoreCase(myTargetPath) Then
         MessageBox.Show("Found")
  Else
         MessageBox.Show("Not Found")
  End If

After I created my extension I thought: “I probably just duplicated something that was already part of a special collection type” so I looked thru the collection types and, under the Specialized namespace I found the class StringCollection. This exposes a Contains() method as well. However, even though it is a string specific collection the documentation indicates:

“This method determines equality by calling Object.Equals. String comparisons are case-sensitive.”

*I still can’t write one without Googling for samples. Learning more about the syntax is always on my to do list.

Taming the SharePoint Wiki

Wed, 14 Oct 2009 02:23:42 GMT

Our current project team decided to post development documents, guidelines, specs etc in a SharePoint site dedicated to project. We also decided we would try a Wiki to post coding standards and best practices, samples, tips on using certain WPF controls etc.

So, SharePoint Wiki is really convenient to set up. Add a new site, choose the Wiki template and you are off an running. That is until you decide you are going to try to add some serious amount of content. The built in editor is good for only simple pages and the image upload feature is … well … less than perfect shall we say. After attempting to upload my first image 3 times with no success, I started looking for other options. In my search I found a question on StackOverflow that led to a great work-around for me. Not sure if this has been posted elsewhere but I felt it was worth a shout-out.

In answer to a question about potential reasons to not use SP Wikis, jfaughnan posted an answer that included his approach to getting around the lousy editor experience in the Wiki:

“There is a convoluted workaround that I use. It takes advantage of the superb SharePoint support and image editing integrated with Windows Live Writer.

Create a SP blog that will hold the images that will be referenced in the wiki.
Use Windows Live Writer to post to the wiki-image-blog. Drop your image into WLW, resize it as needed, etc. If you like, use WLW to write your image associated wiki text first draft as well.
After you post to the Wiki, copy and paste image and text into the Wiki editor rich text field.

This takes surprisingly little time, far less than any other option I've read of. I admit, it is convoluted.”

The author calls it “convoluted”, actually I found it to be a sheer stroke of genius. 15 minutes later I had my “staging blog” set up as a new site, had LiveWriter configured to post to the blog and was up and running with a nice editor, formatting for code samples and cut-and-paste and resize for pictures. LiveWriter handles uploading the images to the blog site. Once your new Wiki content is posted, open the post to edit in the blog site, copy the raw contents and paste them, images and all, into a new Wiki page. Tweak a few links and you are good to go.

Is My Blog Worth Stealing?

Sat, 19 Sep 2009 04:06:14 GMT

Apparently to some, it is.

I was helping a co-worker with the same issue that I blogged about in my last post on how to improve SharePoint list item delete calls. When I Googled (Binged if that makes you feel better) on the subject trying to find a clear answer to her question I found another blogger who had written on the same subject. Cool! Maybe he has the missing piece. I opened the link to find … my own post. There it was, in its entirety. With no clear attribution as to its original source. There was a link on the page back to my site, but why would anyone click it since the entire post was there for their reading pleasure.

So, tonight I did some more searches and found at least two other copies of the same post, one with absolutely no link back at all to my blog. More searches turned up other copies of my posts. So, am I upset? Heck yeah! What can I do about it? Probably nothing. I did a WhoIs search on one of the domains and practically had to download a new font to display the name of the registered domain owner. I won’t mention the sites here as I am loathe to do anything to raise their SEO rankings.

My approach then will be (for now): to not care. I will make a small gesture of adding a copyright notice to the bottom of each posting, even though legally this is not necessary, and, perhaps, adding a “Posted By: Andreas Zenker” tag as well. I’m not really thinking that this will actually stop these sites from scraping my content into their little pay-per-click campaign but maybe there stupid little servers will have to waste a few cycles parsing out some text before they copy my blog over. I’m sure the increased power consumption will cripple them. Take that! ;-)

Update: 9/19/2009

Actually the one site is in English, just hosted elsewhere. Funny thing is I see a new track-back from that site this morning. Once again my post is copied in full, the only reason there is a link to me at all is that I embedded a link to my blog in this post. Maybe that is the secret! I will make the copyright tag a link back to me. Also, they didn't waste any cycles on removing the copyright tag, it got copied as well.

Posted on ASP.NET Weblogs © Copyright 2009 - Andreas Zenker

SharePoint List Item: Delete vs.. DeleteItemById

Tue, 08 Sep 2009 00:12:00 GMT

If you had to choose one of these methods to call to delete an item in a large list which would you choose? Here are your options in code

1: myListItem.Delete()

2: mylist.Items.DeleteItemById(deleteItemId)

Option 2 sounds good here doesn’t it? You have the id, the key to the item in the list, so giving the SPLIstItemCollection this valuable piece of information should make it a simple matter to kill off said SPListItem, no? Well – no. It would be great if, behind the scenes, this was translated to a SQL query like “delete mylist where iitemId = id”. That, however, is not the case. This is the SharePoint object model where men are men and lists are searched in memory. Thanks to Reflector we can see that the DeleteById() method call follows this thread:

Public Sub DeleteItemById(ByVal id As Integer) 
    Me.GetItemById(id).Delete 
End Sub        

Which calls …

Public Function GetItemById(ByVal id As Integer) As SPListItem 
    Dim itemIndexById As Integer = Me.GetItemIndexById(id) 
    If (itemIndexById < 0) Then 
        Throw New ArgumentException 
    End If 
    Me.EnsureListItemIsValid(itemIndexById) 
    If (Me.m_iColection Is Nothing) Then 
        Return New SPListItem(Me, itemIndexById) 
    End If 
    Return Me.m_iColection.ItemFactory(itemIndexById) 
End Function

First line of GetItemById() needs to resolve the index of the item. Only one way to do that (emphasis in red) …

Friend Function GetItemIndexById(ByVal id As Integer) As Integer 
    Me.EnsureListItemsData 
    Me.EnsureFieldMap 
    Dim num As Integer = 0 
    Dim columnNumber As Integer = Me.m_mapFields.GetColumnNumber("ID") 
    Do While (num < Me.m_iRowCount) 
        If (Convert.ToInt32(Me.m_arrItemsData(columnNumber, num), CultureInfo.InvariantCulture) <> id) Then 
            num += 1 
            Continue Do 
        End If 
        Return num 
    Loop 
    Return -1 
End Function

So, Item.Delete() must be the way to go? Well … yes … if you already have the item reference, because then the work is already done. However, if you need to get the item first using GetItemById() then guess where you would end up again? That’s right, GetItemIndexById() and we are back to where we started. It really comes down to a “pay me now or pay me later” situation when choosing between these two methods.

So, how to make it better? Replace either the Get or the Delete with a CAML query which pushes the heavy lifting back to the database (what a strange and mysterious concept, maybe it will catch on one day). Here is a method that constructs a CAML query to delete an item. The method accepts in the itemFileRef, which is what the CAML query needs to pass in to indentify the item in the Document Library to delete. Note: the query syntax is different based on list type, what works for a normal list will not necessarily work on a document library and vice-versa.

Edit 9/18/2009: the owsfileref value that is needed for this query to work can be obtained from the SPListItem object. If the SpListItem is an item in a document library you can call: myItem.Item("FileRef"), which will return the needed value.

Public Sub DeleteReport(ByVal itemFileRef As String) 

        Dim site As SPSite = Nothing 
        Dim web As SPWeb = Nothing 
        Dim list As SPDocumentLibrary = Nothing 

        Try 
            site = New SPSite(SPContext.Current.Site.Url) 
            web = site.RootWeb 

            list = web.GetList(MySettings.RelativeListURL(web) & MyListConfig.ListName) 

            Dim sbDelete As New System.Text.StringBuilder 
            sbDelete.Append("<?xml version=""1.0"" encoding=""UTF-8""?><Batch>") 
            Dim delCount As Integer = 0 

            sbDelete.Append("<Method>") 
            sbDelete.Append("<SetList Scope='Request'>" & list.ID.ToString & "</SetList>") 
            sbDelete.Append("<SetVar Name='Cmd'>DELETE</SetVar>") 
            sbDelete.Append("<SetVar Name='ID'>1</SetVar>") 
            sbDelete.Append("<SetVar Name='owsfileref'>" & itemFileRef & "</SetVar>") 
            sbDelete.Append("</Method>") 
            sbDelete.Append("</Batch>") 

            Try 
                web.AllowUnsafeUpdates = True 
                web.ProcessBatchData(sbDelete.ToString()) 
            Catch ex As Exception 
                Throw New Exception("Error deleting items from list: " & ex.GetBaseException.ToString) 
            Finally 
                web.AllowUnsafeUpdates = False 
            End Try 



        Catch ex As Exception 
            Throw New Exception("Error deleting items from list: {0}", ex) 
        Finally 
            If Not web Is Nothing Then 
                web.Dispose() 
            End If 
            If Not site Is Nothing Then 
                site.Dispose() 
            End If 

        End Try 

    End Sub

This Fiddler trace shows the non-trivial performance boost you can get from re-factoring a delete from using the object model to using a CAML query as shown above.

Now, if your lists are small you will not see this kind of improvement, and if you have no expectation that your lists will ever get large then you may be safe using the object model provided delete options. However, if that is not the case check out CAML before you go to production.

New entry to blog roll – John Robbins

Thu, 16 Jul 2009 09:34:00 GMT

This most recent post by John Robbins is what motivated me to add his blog to my blog roll. However, it has been a must read for a while now. This post is actually more “fluffy” than most for him, I just loved the insight into things macros can do that I hadn’t considered like setting breakpoints with custom conditions. Also liked the code he used to validate that the current window in the IDE was in fact a code file before moving forward with the macro. I pulled that method out and added it to my common module of macros.

The Achilles Thread

Sat, 11 Jul 2009 02:58:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Sunday, November 18, 2007

"[when debugging] If you see hoof prints think horses, not zebras".

Hunt and Thomas, in The Pragmatic Programmer

Developing in the brave new world of managed memory and garbage collection we, in most cases, don't have to worry about the details of memory allocation and clean-up. However, when our application starts having memory issues, we can easily have a tendency to fall into one of two camps:

Assuming all memory issues are memory leaks (i.e. objects not being disposed of properly)
Assuming that garbage collection is not working as stated.

Both of these assumptions are flawed in one common way: they narrow our focus to a limited set of possibilities and that affects the way we approach the problem. Sparing you the cutesy saying about what happens when we ass-u-me, it is fair to say that assumptions cripple any debugging effort. Once we assume we lose control over the "scientific" process of debugging a problem. In this case we had a utility application consuming egregious amounts of data, 1 to 1.5 gb of memory just to process a queue. I immediately assumed a traditional memory leak, as we were dealing with MSMQ, MessageEnumerators, Messages, SqlConnections, SqlCommands etc, I figured something was not getting disposed of or was still gcroot-ed somewhere in the code.

Problem scenario: In a console application we are iterating thru 85,000 messages in a "dead-letter" queue to see if we can salvage the data that never made it to its destination, the database. As we iterate thru the queue we pass off each message to a handler designed for that particular type of message using a factory. The handler de-serializes the message body back into the original object, generates a SQL insert based on the message contents and inserts a row in the database. As each handler returns a result, messages are removed from or left on the MessageQueue. Rinse, repeat.

If we remove the call to the datalayer component that is writing the new rows in the DB, the memory issue goes away. So clearly we have some SqlProvider objects not getting disposed of, right? Wrong. In surgically adding back in the datalayer functionality one method at a time it becomes clear that just opening a connection to the database once is all it takes to create the issue. Comment out the line that creates the connection, no memory issue, add it back in the death spiral returns.

To see if I could reproduce that scenario with fresh code, I reproduce the functionality from the ground up in a Windows Form application to make debugging more friendly. I set up a few different scenarios and, just to make the experience more lively, I add some counters to the forms so I can see how many messages have been processed etc. I take all the same steps as described above and..... no memory issue. I start reviewing the code method by method to see what I am doing differently. I find nothing, everything is exactly the same.....except.....in the windows form I am publishing messages to the GUI using a quick and dirty "DoEvents" call in the loop, who wants to stare at a frozen form? Then it hits me, I remove the DoEvents and the memory issue is back. Now that I have, not an assumption, but the real problem description it doesn't take long to find the answer as the links below will point you to.

Maoni Article on Finalizers

Microsoft Whitepaper

Google Groups Thread

The short answer proved to be this: In console apps the Main() form is launched by default on a Single Threaded Apartment Thread (STA). The same is true of a Windows form app and it's GUI thread. The STA model keeps that thread safe from multi-threading issues, especially when using COM objects that are acting like they are all alone in the world. So, when a COM component is created, used and released on an STA thread, it needs to be finalized. The finalizer thread has to wait until it is "invited to the party" in order to finalize that object. If the STA thread is in a long running loop, and is not publishing messages (ala DoEvents, Thread.Join() etc) then the finalizer is blocked until the loop is done and the STA thread takes a breath. This explains how one database connection could kill this app. The connection was ready to be finalized, the finalizer queues up to process that but is blocked waiting for the STA thread to take a breath. Meanwhile the STA thread is cranking thru a huge Queue and leaving an Exxon Valdez size slick of managed objects who are waiting on guess who, the finalizer thread.

The suggested solution: add an MTAThread() attribute to the entry point of your application (Sub Main() ) to prompt the runtime to load your main thread in Multi Thread Apartment (MTA) mode, now the finalizer can sneak in and do its clean up even though the main loop is not making any effort to share.

So, it wasn't quite horses, but not full-bred zebras either. Either way it was a fun ride.

Forest for the trees – Don’t forget the compiler

Sat, 11 Jul 2009 02:54:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Wednesday, June 6, 2007

Back in school my teacher was not much on the formal aspects of the course he was teaching.He was instead, as I describe him, the kind of guy you could imagine living in his room with his PC, hacking away, his mom pushing crackers under the door and begging "You really should go out and get some friends dear." Perhaps because of that we spent less time in the text book and more time digging into just what the IDE, along with COM and MTS at the time, were doing underneath the hood to be "helpful". He often said that memorizing the text book would help you pass but that knowing what was really happening based on your code would give you a better ability to figure things out when debugging "weirdness". For some reason I thought of him just today. :-)

The "weirdness" in this case was that my IDE was doing strange stuff in debug mode, or so I thought at the time. I was trying to see why my property based on a config setting was never getting populated with the correct value. So I did the natural thing, I set a break point on the property get and fired it up. The basic code of the getter was this

Get
     Dim prop As Boolean = False
     Dim configVal As String = System.Configuration.ConfigurationSettings.AppSettings.Item("MyConfigKey")
If Not configval Is Nothing Then
          prop = CBool(configVal)
     End If
     Return prop
End Get

Nothing fancy, but when debugging I found that the If statement never seemed to evaluate to true, and the if block never executed. The debugger would always jump to End If no matter what I set the value of configVal to in the command window. Somebody wiser than me once said something along the lines of "always look for the stupidest solution first", however with this "weirdness" I immediately launched into the "weirdness countermeasures". These included restarting the IDE, rebuilding the solution, bleaching the temp files in case I was somehow stuck with an old version of the file from a previous life, rebooting, rinse repeat. All of the maneuvers that have served well in the past when bizarre things happen in the IDE. No dice, still same issue every time.

Now it's time for last resort "I have no idea, but I'll try this" measures. In the past I have had lines of code that would not compile with no apparent error and only way to resolve the issue was to retype the line, visually identical to the "bad" line, and all-of-a-sudden the IDE was happy again and we moved on. Whatever! So I figured I would give that a try. As I was re-typing the code I found a bug, seemed stupid and meaningless at first, but it then hit me that it had been the issue all along. In my getter the actual code looked like this

Get
     Dim prop As Boolean = False
     Dim configVal As String = System.Configuration.ConfigurationSettings.AppSettings.Item("MyConfigKey")
     If Not configval Is Nothing Then
          prop = CBool(prop)
     End If
     Return prop
End Get

I was setting the prop variable to the result of CBool(prop) as boolean of itself, which would always mean no change to the variable. Then the lights in my dark and scary brain started to go on! The compiler was helping me! I compiled the code again and looked at the disassembly, first with the bug

If Not configval Is Nothing Then
00000036 test ebx,ebx
00000038 je 0000003A
End If

and then without

If Not configval Is Nothing Then
00000036 test esi,esi
00000038 je 0000004E
prop = CBool(configVal)
0000003a mov ecx,esi
0000003c call FFB91FD0
00000041 movzx edi,al
00000044 mov eax,edi
00000046 and eax,0FFh
0000004b mov dword ptr [ebp-8],eax
End If

The compile decided that the stupid line of code was irrelevant and simply removed it. So in debugging, since we are actually stepping through the debug symbols, not the code, there was no line of code to hit in that If block. So the supposed "weirdness" just turned out to be a bad cut and paste. Doh! If the compiler had left it in I would have seen the line execute with no change to the value of prop and found the bug right away. Instead I get all commando.

Anyway, I just had to share my brain cramp. When things seem "weird" don't forget:

a) the "always look for the stupidest solution first" rule still applies

b) don't forget what might be trying to "help" you under the hood.

© Copyright 2009 - Andreas Zenker

What is a clustered index anyway?

Sat, 11 Jul 2009 02:51:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Saturday, February 17, 2007

Wanted to drop a quick post for two reasons: 1) To prove I have not died, been abducted by aliens, or been confined to a room with soft, cushy walls and a nerf PC for my own "protection". 2) To give a plug for someone I had an opportunity to work with this past week.

Our shop was in need of some SQL Server performance tuning. Not having the expertise in house we called in an outside consultant. Not having had the best experiences with outside "experts" in the past, I was skeptical. However, Ray Rankins and his Gotham Consulting seem to be the real deal. Not living in the SQL world day in and day out, I tend to leave the "deeper thoughts" to the DBA's and worry about the procs doing what I need when I need it. However, when it does come down to a proc that is dogging our application down, it would be nice to really understand why one syntax or set of indexes works so much better than another. Usually the approach to tuning a long running proc from a developer standpoint is "Well, that sucks, let's try something else" and "Wow, that sucks a lot less, let's do that!" Speaking with Ray this past week I found a man who knows, and seems to care, about what is happening under the hood in SQL Server as much as I do about the inner workings of the CLR. The longer I work in this field the more I realize that this kind of person is hard to find. In one ten minute conversation I now have a really good idea what a Clustered vs. a Non-Clustered index is, why it matters, what situations you would want to use either of them etc. Ray has written "the book" [note: updated link to latest edition of book when recovering blog post -- AZ] on SQL Server and is just making the final edits on the SQL 2005 edition. I think I will add it to my ever growing stack of books to read one rainy day.

slidingExpiration = NotReally timeout = NotWhatIThinkItIs

Sat, 11 Jul 2009 02:43:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Wednesday, October 25, 2006

As a new approach to some meaningful blogging, as I work on debugging some new bug/issue, the info I collect and my deductions I record right in my LiveWriter window so that I can save any links, code snippets etc. This way, with little effort, at the end of the day I can do some quick editing and post something "useful" (you may choose to retain your own definition of that word). A fringe benefit is that I can find this info again the next time I need it.

So here was the situation:

An ASP.NET application that leverages FormsAuthentication. The timeout is set in the web.config to 20 minutes in the authentication tag something like this:

Users were reporting intermittent timeouts that were significantly less than the 20 minutes. In testing we were unable to duplicate this scenario.

The other important detail, that we have omitted until now, is that we are "rolling our own" authentication ticket in order to have more control over what that ticket contains etc. So in code the default ticket timeout value (set as a constant) was 20 minutes.

So, now onto the mistaken assumptions. I had assumed that the web.config setting would come into effect the first time the ticket was updated. Being that it is a sliding expiration I had thought that the ticket would be updated to the web.config timeout the next time a page was requested. Since the user is redirected from the login page as a matter of course it was assumed (doh!) that the hard-coded timeout value would not last longer than a second or two. So, the first thing I did was set the web.config timeout to be 1 minute so that I could test without waiting 20 minutes. Waited a minute .... posted back ... no dice, still logged in. No matter what I set that value to I could not get kicked out if I tried. Only when I changed to constant to 1 in the code and recompiled was I able to get kicked out as expected. Ok, bad assumption, no big deal, we'll just change the code to read the config value when it sets the original ticket and then all will be in sync, right? Not so easy.

First of all, the values in that section of the config are protected, even from the guy writing the application. The normal system.configuration approach does not expose these values and the FormsAuthentication classes do not expose what you would think is a fairly useful property. So how do you make sure you are in sync with the config file? Doing some googling we find that Scott Hanselman ran into the same thing years ago, no surprise. Scott details his thought process in solving the same issue.

Scott addresses the pain of accessing the config setting from code so that the first creation of the ticket can match the desired setting from the web config. He considers the approach of creating an additional, accessible, config setting that would require being set in two places or creating an invalid situation. (i.e. one setting says expire in 20 minutes, one says 10 etc). He considers reflection, but deems it too ugly. Finally he settles on dynamically "discovering" the web.config, loading into a DOM and xpathing his way to the setting and storing in cache so he only has to do it once. Basically there is no clean work-around so you have to settle for a lesser of the evils approach.

So, armed with that information we start testing with our new found knowledge. We had written a test page to dump out the contents of the ticket to a text box so that we could see what expiration was actually being set. We set the original ticket being written by the code to a nice small value of 4 minutes and started to post the page back. Here comes the strangeness. As we post the page back the expiration time of the ticket does not change. We keep posting the page back every 15 seconds or so and eventually it decided it was time to update the ticket with a new expiration time. Now were really confused, this was, after all, a sliding expiration wasn't it? Every time the page posts back it was supposed to update the time to give another n minutes before it would be timed out. So back to digging, this time we pull up the MSDN documentation on the tag and the element. MSDN documentation on element attributes.

The msdn docs indicate that a sliding expiration does not really slide as you might imagine, and certainly may expire when you do not expect it to. Here is a priceless, if not a bit contradictory bit of MS wisdom: "If the SlidingExpiration attribute is true, the timeout attribute is a sliding value, expiring at the specified number of minutes after the time the last request was received. To prevent compromised performance, and to avoid multiple browser warnings for users that have cookie warnings turned on, the cookie is updated when more than half the specified time has elapsed. This might result in a loss of precision..", I guess! A "loss of precision"? Is that what we call a sliding expiration that doesn't slide and results in an effective timeout of only half what you think you set it to? So, because some people are afraid of the big bad cookie monster we are going to totally hose the well understood concept of a sliding expiration, with no "override this stupid default behavior" attribute in sight? That is insane. Now it's time to pull out Reflector and look for a clever workaround.

Inside the FormsAuthentication class we find the method that does just as described, renews the ticket only if the time left till expiration is greater than the time since the current ticket was issued.

Public Shared Function RenewTicketIfOld(ByVal tOld As FormsAuthenticationTicket) As FormsAuthenticationTicket
      If (tOld Is Nothing) Then
            Return Nothing
      End If
      Dim time1 As DateTime = DateTime.Now
      Dim span1 As TimeSpan = DirectCast((time1 - tOld.IssueDate), TimeSpan)
      Dim span2 As TimeSpan = DirectCast((tOld.Expiration - time1), TimeSpan)
      If (span2 > span1) Then
            Return tOld
      End If
      Return New FormsAuthenticationTicket(tOld.Version, tOld.Name, time1, _
                      (time1 + (tOld.Expiration - tOld.IssueDate)), _
                      tOld.IsPersistent, tOld.UserData, tOld.CookiePath)
End Function

Unfortunately the method is completely self contained and is not using any other settings to determine its results. It bases the decision on whether or not to update the ticket completely on the lifespan of the current ticket and the current time. If more then half the time has elapsed then you get a new one, period. So no work-around presents itself.

Something else we learn from this code is that, if you are manually setting the original ticket, the setting in the web.config, if different, never comes into play, since the renew method is basing its renew length on the originally set length of the ticket not your silly little timeout setting. This setting just gets more useless as we go on!

Now, if you use the out-of-the-box authorization that is provided in the framework and set your ticket using the FormsAuthentication.SetAuthCookie(username,isPersistent,cookiePath) method, the config setting will hold true when the ticket is created for you, however the non-sliding expiration issue still holds true.

So, enough pain for one day, how are we going to "fix" this so that the user has the result they expect, a 20 minute timeout? First we have to sync up our code creation of the first ticket with the web.config value. I wasn't fond of Scott's xml loading solution, although it would work. Since we found that, in our case, the web.config setting was moot anyway We opt for adding a new value to the web.config to explicitly set the value the code would use, afterward the framework would continue to re-apply this value as it refreshed the cookie. This does not provide any actual conflict, but it may provide some confusion as the app is deployed and maintained. The nice thing, for once, is that the timeout attribute on the element is optional and defaults to 30 minutes. Since it is never going to be applied, what do we care? So we remove the attribute and thus remove the apparent conflict in settings.

Now, what can we do about the non-sliding expiration? Well, it's been a long enough day, so we opt for the easy: "Just double it stupid" approach. This could, if we were relying completely on the forms authentication for timeouts, allow users, in some cases, to get anywhere from 20 to 40 minutes timeout, which would be considered a problem as well. However, since we are also requiring a fresh login when the session times out, we are covered. We set the config timeout to twice what the session timeout is and we are good. The shortest the ticket will live is 20 minutes between clicks, and if it lives longer than that the session will tank and all is well.

Now you may have a more elegant solution, so feel free to share...

That which we call a Namespace, by any other name would just smell.

Sat, 11 Jul 2009 02:34:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Tuesday, June 27, 2006

There is nothing sweet about spending hours, days, evenings and weekends chasing "ghosts" in your code. In this context "ghosts" mean compile or runtime errors that are not constant, only dreadfully persistent. Perhaps you also have been faced with the intermittent errors that look something along the lines of this:

Could not load type Foospace.FooWebService.FooWS.FooInfo from assembly mscorlib, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

Could not load type 'FooSpace.Global'.

Now, huge caveat here, these types of error could be caused by a plethora of things, even perhaps a plethora of pinatas, but most would provide constant errors on every build or execution. I have found a surprising dearth of information on this scenario, its cause and resolution. So the situation I am about to describe may not match yours, but if it does I hope it helps.

Note first of all that the type I am failing to load is a type defined in a Web Service that my project is calling into. We can imagine that the FooWebService returns a type of FooInfo from a method called GetFoo. (What would we doo without foo?) This is a standalone service and as such does not share any references with our main application so that is enough info about that. Our main application, to start will just have one project: FooApp, it has a Web Reference defined pointing to FooWS and uses that to get and display FooInfo properties on the page when it loads. So far so good.

Now we start to build our application into a solution that we expect to get quite large so we start using Namespaces to categorize our projects. So now we go to our project properties and change the Root Namespace from the default FooApp to FooSpace. When we do this now our project won't run because our global.asax and our webform.aspx files have statements like this: Inherits="FooApp.WebForm1" that need to be changed to read Inherits="FooSpace.WebForm1". At this point something should be telling us that namespaces are more than just a way to organize our code and get pretty little intellisense dropdowns when we are defining our objects. Anyway, we shake off the annoyance and move on, once again our project loads and we are good. We also do the same for the FooWebService Project, as the first segment of the namespace is often a company or overall product name, this makes sense.

Now we add the ever essential FooLibrary project to our solution. To keep in form we change its root namespace to match our new structure, "Foospace". Notice the typo? the "S" is not the same case as our FooApp Root Namespace. Now Visual Basic is case insensitive, so it shouldn't care, right? Wrong, way wrong. In fact, it seems, the compiler can't tell the two apart so sometimes when it is looking for a resource to load it will use the correct namespace, other times it will not. To prove it to yourself, add a reference in your FooApp web project to the new FooLibrary. You don't even need to call anything, or add any import statements. You should start having issues right away. I was going to try to document all the different variations you might see based on your setup but here are a few.

If your Web Reference is static you may get compile errors right away. Lucky you!
If your Web Reference is Dynamic you may get past the compile but will likely fail on loading the global.asax for no apparent reason.
If your reference to the badly namespaced project lives in another project, say a business object layer that calls upon the FooLibrary, the code could compile and even run. Until one day you start to get weird "Could not load type" messages.

So the basic point of this post is: A Namespace is case sensitive! Whatever .NET language you call home. Our shop ran into this well over a year ago. Just recently it came back into our solution by way of some new project namespacing that had been done and its "avatar" was completely different. On the first go-round we mostly had the issues loading global.asax, still intermittently build by build. On the latest flare up we had the error calling a Web Service well down in the application, once again random build to build. Because the evidence was so different we chased some ghosts before we, once again, identify the culprit. To be fair, I did find one blog that did mention this issue quite some time ago, so I will link to it here. Scroll down the page and look for the header: "VB & C# Casing Issues with VS.NET "

It is Truly the Simple Pleasures In Life

Sat, 11 Jul 2009 02:29:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Monday, April 24, 2006

The recent project list on the start page of the Visual Studio IDE seems like such a cool thing at first glance. However, very quickly it degrades into the "How many times do I have to be reminded that I called my test project 'Son of Foo'" list. We end up with junk in there that is just plain annoying. Recently our shop made a move to Subversion for source control, finally giving Visual Source Safe the merciful lethal injection that it so deserved. In the process I cleaned up and moved my local working copy of code to a new folder. So now I not only was reminded of every time I created a test project named "WebApplication1" in the past month, but I also was faced with duplicate entries of "My Solution" in the list, one real one just a mirage. Needless to say I clicked on the mirage enough times to be motivated to google on how to clean up the recent project list. In doing so I found this very light-weight, and useful, util here. Thanks to Josh Beach (whoever you are) and the guys at CodeProject for this useful little number. It truly made my day.

Doing it With Style

Sat, 11 Jul 2009 02:25:00 GMT

Recovered from DotNetJunkies blog -- Originally Posted: Tuesday December 27, 2005

Most of my personal (read: "for fun") programming time lately has been involved with web design. Being much more comfortable hiding behind a nice solid business object, this is largely uncharted territory for me and, as such, provides the comfortable, nearly vertical, learning curve that we know and love. I decided up front that I was going to "do it right" and not fall back on the old <table> method of laying out the page contents. I had read, and heard, about the advantages of CSS based page layout, but had not had any direct exposure. In my research of what is available on the web I have collected a short list of valuable CSS resources that I wanted to share. So here goes...

The site that will make you a believer:	CSS Zen Garden
Practical layout tips and tutorials:	A List Apart glish.com

I would say that, hands down, the AListApart site has been the most valuable so far, especially this article on how to use negative margin values along with column defining background images to define your 2 or 3 column layout all in CSS and have it degrade nicely. Sweet!

The blog is dead – long live the blog!

Sat, 11 Jul 2009 02:16:00 GMT

One of the reasons I blog, despite all the fame and fortune it brings me ;-) , is the fact that I can record, for my own benefit, solutions I have found to problems. One day I will need to find a particular factoid again and Google will bring me back full circle to where I left it. At least that is the general plan.

Today I was having an issue with namespaces. I was seeing namespaces differing only by case, e.g. myNamespace vs. MyNameSpace, and it was bringing back bad memories. I remembered that I had blogged about a similar problem once before and wanted to find that article to see if my problem might be similar. However, when I went to look for my old blog at DotNetJunkies.com, it was gone. Not just down, not just no longer supported, it was gone. When I first started this blog I considered migrating my old blogs to the new site but that seemed kind of harsh and, I thought naively, unnecessary. “I can just link to the old blog and life is good” I thought. Well … that was, in retrospect, pretty stupid.

All, however, was not lost. I remembered that there are sites dedicated to storing cached versions of web sites for posterity. One such site that I owe my thanks to is The Wayback Machine. Thankfully they don’t discriminate based on perceived value! I was able to find my old blog stored safely away in the archive and recover my lost content.

So, thanks to the archives, I will be posting my old content here in the following posts. Re-posting feels a bit weird, kind of like making a “best of” album when I still don’t have a hit single but hey … it’s my blog.