I was asked an unusual question yesterday about cookies, Silverlight and WCF. The scenario was that a Silverlight application was being used in a consumer-facing situation. The application itself communicates with the server using WCF. The service which is the target of the communication uses ASP.NET Authentication to authenticate the user. It’s an implementation detail (but critical to this post) that the method of storing the authentication token is a cookie called .ASPXAUTH.
In a normal (that is, working) scenario with Silverlight, the credentials are sent to the server and an .ASPXAUTH cookie is returned. The browser strips off the cookie and stores it. On any subsequent requests, Silverlight creates a request and sends it the the server through the browser’s networking API. The browser is responsible for determining which, if any, cookies should be send with the request and adding them to the outgoing header. In other words, the Silverlight application has no specific knowledge of or interaction with the .ASPXAUTH cookie.
As you would expect, this mechanism works the vast majority of the time. If it didn’t, I think it would have been a significant story long before now. But my questioner was running into a situation where the Silverlight application was unable to communicate with the server even after authentication was performed. What’s worse, this behavior was only happening on IE7. When Silverlight was run through Firefox, it worked exactly as it was supposed to.
The diagnostic step in a situation like this is to use Fiddler (or whatever your favorite TCP trace application is) to view the raw messages. And what was seen is that although the authentication response had the .ASPXAUTH cookie in it, any requests sent back to the server after authentication did not. Given when I’ve already explained about the processing of cookies with Silverlight requests, this eliminates the Silverlight application as the most likely culprit. But it also makes one scratch your head, as we can be pretty certain it’s not a widespread failure of IE7 to process cookies.
The answer likes in a strange bug in IE7. It turns out that if a domain name has a underscore in it, IE7 doesn’t persist the cookies. Let me repeat that, because it’s such a bizarre sounding problem. In IE7, if the domain name has an underscore (‘_’) in it, then any cookies returned from the domain will not be persisted. Which also means that subsequent requests will be ‘cookie-free’.
I’m guessing that most domain names don’t have an underscore, which is why this bug didn’t get widespread notice. In this particular case, the domain was one used for development, which would keep the problem from being a production issue. But I have no reason to believe that the bug would be restricted to a local problem. Deploy a ‘underscored’ domain name to the public internet and no authentication, shopping carts or other state information can be saved.
Fortunately, the solution was a simple one. If the domain name in the endpoint configuration is replaced with the raw IP address, IE7 is more than happy to save the cookie. I wouldn’t be surprise if an entry in your local hosts file would have the same effect. And the final solution would be to have your domain administrator create a DNS Alias entry…one that doesn’t have an underscore, of course.
On Wednesday past, I did a Code Contracts presentation to the Toronto Visual Basic User Group. It was a continuation of my whirlwind ‘April Presentation Tour’, in that it was my third presentation in a week and the third of five that I’m doing in April. Tee shirts for the April Presentation Tour were available for sale from vendors as you left the arena
I have posted the slides and the source code to the following links:
Slides: Here
Source Code: Here
If you have any questions, please feel free to drop me a comment or an email message.
On the scale of annoyances, this is not a huge one. But the solution is so simple, that it’s worth a quick post.
Have you ever been in the middle of debugging an application and used the hover functionality to display the current value of a variable? And expanded multiple levels to find the specific property that you’re looking for? Of course you have.
But have you ever been frustrated when the debugging view obscures a piece of code that you’re interested in? So that you have to close the debugging tooltip to see the code and then navigate through the hierarchy to get back to what you were looking for? Odds are that it has happened to you. It certainly happens to me frequently enough.
Fortunately, there is a solution. While the debugging tooltip is displayed, simply press the Ctrl key. This instantly makes the tooltip transparent. And when you release the Ctrl key, the tooltip reappears. Simple and elegant, just the way all solutions should be.
Thanks to Dave Lloyd and Brian Rasmussen for the information (same tip at different times).
Have you ever been dissatisfied with the code that is automatically generated by Visual Studio in response to various commands that you perform. For example, in VS2005, I got used to using the prop snippet to create properties. This snippet created a property declaration complete with a private backing variable. However, in VS2008, the prop snippet was modified to create a property declaration in the form of the automatic property declaration. That, to me, was annoying.
(Note to Microsoft: Please consider the existing snippets to be part of what you consider when looking at backwards compatibility. Create more snippets, sure. But please don’t change what the current snippets do…especially when the ‘better’ snippets are not actually better)
Or, consider the fact that, as more and more work is done in WPF, the need to ensure that business classes implement INotifyPropertyChanged grows. Adding or modifying a snippet to include the code to call PropertyChanged could be quite useful. It certainly has been for me.
Little known by most developers is the location for the snippets that Visual Studio provides. Or, what might be more interesting to intrepid developers, the snippets used by Visual Studio refactoring. All of these are found in %ProgramFiles%\Microsoft Visual Studio 9.0\VC#\Snippets\1033. The keyword snippets can be found in the Visual C# subdirectory, while the refactoring snippets can be found in the Refactoring subdirectory. Take a look at what’s there and you may be surprised how you can increase your productivity for mundane (and frequent) tasks.
If you use WPF on a regular basis, then I can take a good guess as the esteem in which you hold the designer. While it has it’s place, hard code WPF devs using XAML directly. It’s much each to get the result that you’re looking for quickly. The problem I’ve always had is that when you open a WPF file, even when you have disabled the design portion, there is still a significant time lag.
Thanks to Fabrice Marguerie who wrote this blog post which describes how to eliminate that annoying delay.
It’s nice to have less friction between me and my XAML. :)
So to set up this problem, an application that I'm currently working on needs to process data that is stored in an Excel spreadsheet. The creation of the spreadsheet is actually performed by a scientific instrument, so my ability to control the format of the output is limited. The instrument samples liquids and determines a quantity. That quantity is placed into the spreadsheet. If the quantity in the liquid is not successfully read, then the literal "Too low" is placed into the sheet. The application opens up the spreadsheet and loads up a DataSet using the OleDb classes (OleDbConnection and OleDbDataAdapter).
This seemed like a fine setup. At least, until some of the numeric values in the spreadsheet were not being read. Or, more accurately, the values in the spreadsheet were not making it into the DataSet. Head-scratching, to say the least.
After some examination, the problem became apparent. When the values were being successfully read, the column in the DataSet had a data type of Double. When the values were not being successfully read, the column in the DataSet had a data type of String. Now the difference between success and no-success was nothing more than the contents of the spreadsheet.
Now the obvious path to follow is how the data type of the column is determine. Some research brought me to what I believe is the correct answer. The Excel driver looks at the contents of the first 8 cells. If the majority is numeric, then the column's data type is set to Double/Integer. If the majority is alphabetic, then the column becomes a string.
Of course, this knowledge didn't really help me. As I said at the outset, my ability to control the format of the spreadsheet was limited. So I needed to be able to read the numeric data even if the column was a string. And, at present, the cells containing numbers in a column marked as a string were returned as String.Empty.
The ultimate solution is to add an IMEX=1 attribute to the connection string. This attribute causes all of the data to be treated as a string, avoiding all of the cell scanning process. And, for reasons which I'm still not certain of, it also allowed the numeric data to be read in and processed. A long and tortuous route yes, but the problem was eventually solved.
I just finished teaching a Silverlight/WPF course last week. As is true in almost every course I teach, there were questions from people who are trying to use the technology in the real world. It's what I love about teaching...that I always learn something about how people use the tools they have been given.
In this particular case, the problem was relating to walking the control hierarchy in a user control. The user control contained a DataGrid and the goal was to get from a particular cell within the DataGrid back to the user control itself. The code that was written to do so looks approximately like the following.
public UserControl GetContainingUserControl(FrameworkElement element)
{
if (element is UserControl)
return element;
else
return GetContainingUserControl(element.Parent);
}
The problem with the code is that, in the case specified, the Parent becomes null before the UserControl is found. For most developers, this is a strange and unexpected turn of affairs. For most hierarchies, it seems completely reasonable to presume that every element in a hierarchy will have a non-null parent except the root of the tree. But if you read over the description of the Parent property closely, you will see that it could be null. From MSDN,
Parent may be a null reference (Nothing in Visual Basic) in cases where an object was instantiated, but is not attached to an object that eventually connects to the Silverlight RootVisual, or the application object.
Ouch. Sure it's documented, but still. Ouch.
Fortunately, there is a solution, found in an incredibly useful class named VisualTreeHelper. This class exposes a number of methods that can be used to navigate up and down the visual hierarchy in a WPF interface component. There is, for example, a GetChild method that retrieves a particular child element. As well, of particular interest for this example, there is a GetParent method that retrieves the parent of a given element. This method will not return a null parent until the top of the visual hierarchy is reached.
In other words,VisualTreeHelper.GetParent(element) can be used in place of element.Parent in the above method with the result being more in line with expectations.
Whew.
Earlier today, a colleague had an issue with the publishing of unit test results into a TFS instance. The publication process, which is typically done manually at the click of a button, was no longer available. Specifically, the Publish button was actually disabled. There was no obvious error message indicating what, if anything, was wrong. This lack of information made identifying the problem a challenge, to put it mildly.
The solution, at least to identifying what the problem was, is to use the command line version of MSTest. If you execute the command MSTest /? in a command window, you will see that there are a number of options which can be used to execute a set of unit tests and publish them to a TFS server. For example, the following command will execute the unit tests in the TestLibrary.dll assembly and publish the results to the TFS server located at http://TfsServer:8080
MSTest /nologo /testcontainer:"TestLibrary.dll" /runconfig:"localtestrun.testrunconfig"
/resultsfile:"TestLibraryResults.trx" /test:TestLibrary /publish:http://TfsServer:8080
/publishbuild:"DemoTestBuild_20081103.1" /teamproject:"DemoProject" /platform:"Any CPU" /flavor:Debug
In this particular situation, running MSTest generate an error that indicated that the drop location for the build could not be created. An error that was, thankfully, quite easy to correct. But difficult to identify without using the command line tool.
I did a presentation this afternoon on some of the basic functions of WCF. I had put a slide deck together using a new Microsoft Office add-in called PPTPlex. You can see demos of what this add-in does in the provided link, but basically is allows for a much more dynamic experience of going through the slides in a slide deck. As compared to the typical linear flow, PPTPlex allows you to easily jump from one slide to another with a couple of clicks up and down the slide hierarchy.
I was pretty excited to be able to put this technology to work in the real world - right up to the time when I started the slide show.
Most of the time when I do presentations, I use a split screen. That is to say that what is displayed to the audience is not the same as what I see on the laptop in front of me. The new Presentation Mode in PowerPoint 2007 helps me a great deal with working that way. I was expecting that, when PPTPlex was run as a slide show, I would have expected the same appearance, that being that the slide show (such as it is) would be displayed on the secondary monitor.
I was disappointed.
Now it may be that there is a setting that I missed that would have allowed this to happen. I will admit that I was standing in front of the class when I tried this, so the time allocated for exploration was limited. But I expected it to just work and it didn't. Sigh.
Now I haven't yet got back to a place where I can do some detailed investigation, but as soon as I do I will see if I missed something. I hope so, but I doubt it. More details as they become available.
I recall my first experience with Word 2007...it took me 20 minute to figure out how to do a Save As. Who would have figured that the cute icon in the top left corner actually had functionality associated with it. :)
In a blog post from Chris Sells, I was point to a tool whose purpose is to bridge this gap. You see an on-line image of Office 2003 menu structure and by hovering an item, you are told where to find the same function in 2007. You can find the tool here. Check it out, use it and avoid the embarrassment that I went through.