Breaking into the Visual Studio .SOU File

I’ll probably need to do this again one day, so I want to record how I did it…and it might help someone…

I wanted to check whether an absolute or relative file path was saved for a particular thing in the .SOU file. But, Notepad displays garbage when you force it to open a .SOU file.

Instead I opened another copy of Visual Studio 2010 (not a copy where this solution was open, tried that, it didn’t work). I created a new solution folder, and dragged the .SOU file into it.

I could not drag it onto the document surface, because someplace along the way I picked up a file association with Notepad – so Visual Studio was just one more mechanism to do the useless.

I selected Open With from the Right Click context menu and selected the binary editor.

Find did not work for me. I can think of a few possible reasons.

So, I selected from the first readable text in the binary editor to somewhere near the last readable text and did a normal Ctl-C copy. In other words, I used the binary editor to chop off the beginning and end of the file, and to put something sufficiently useful into the clipboard buffer. Notepad cooperated in displaying the text retrieved from the clipboard buffer with a normal Ctl-V paste.

This file is still a mess, not usable for any normal exploration. However, I could confirm that the file name I was interested in was only stored in absolute, not relative form.

Microsoft, please, pretty, pretty, please, pretty, pretty, pretty, pretty, pretty please can we get readable formats for .sou and .user files?

To “as” or not to “as”

Iris Classon is asking and finding answers for “stupid” questions on her blog. First of all, they are definitely not stupid questions. There are a lot of nuances of .NET that slip out of our daily thinking. When I first started my Getting Geeky with the .NET Framework series I’d ask really hot coders basic questions – things that affect how code runs – and the results were not stellar. So, first, three cheers for Iris’s project.

Today’s question was “How should I do casting in C#? Should I use the prefix cast or the as-cast?” She’s got some good input that I suggest you read first. I also felt that the discussion left out a significant factor – debugging.

If the value resulting from the cast really should not be null, the code becomes unstable or incorrect at the point of the cast. Period. With the prefix cast, application state clearly becomes incorrect at that point because an exception occurs. With the “as” cast, the application state still becomes incorrect at that point, you just don’t know it. If the value should not be null, you’ll get a null exception, or possibly failure of a Requires clause if you’re using code contracts somewhere, sometime later in application execution.

One of the things that makes hard bugs hard is when there is a disconnect in time or space between the cause and the symptom. Time is time, space is lines of code, assembly placement, etc. Code can be written to minimize these disconnects. One of the ways to do that is to fail quickly. When application state becomes incorrect, yell about it immediately and rarely continue with the application in an invalid state. A null-reference exception at an unexpected time just makes code more difficult to debug.

Eric Lippert’s quote short-cutted the idea of what happens next. He’s quoted as saying that a prefixing cast failure requests, “then please crash the program.” That would be much better put as “then please do not continue the current operation.” Our programs need never crash in the sense of blue screen ugly death. Exception handling is a mechanism for recovering to a valid state, with the capacity to communicate failure to interested parties like the user and system logs.

So, use the “as” cast only when the resulting null does not make the application state incorrect, or you have an immediate and adjacent test that you prefer to make the application state correct or perform different exception management. For example, you might want to add a specific error message if the invalid cast indicates a particular type of problem.

I think the prefixing cast should be the “go to” cast for .NET – the one you use when you haven’t thought through the implications of the null value to the remainder of your program.

Build/DevConnections Scheduling Conflict

Since Microsoft scheduled Build on top of DevConnections, I’ve had people ask which conference they should go to. I’ll start by admitting my bias. I haven’t missed speaking at a major DevConnections show for six or seven years, and if you come to DevConnections, you can come see my talks!

But biased or not, I think the DevConnections/Build decision is a no-brainer…they are very different events. This is a quick list off the top of my head with no discussion with any marketing people at either event.

– Based on history, the Build content will have good technical content, but be planned for Microsoft’s marketing convenience

– Build will focus on future products

– Build talks and speaker list may not be public until the last minute

– Build speakers will be from Microsoft and might be constrained in what they can say

– Build sessions will probably be recorded so you can see them in the future

– Build may help you make human connections inside Microsoft to get your opinions heard

– Build will probably sell out in minutes, possibly seconds

– Build attendees might get cool hardware – maybe a new Surface

– DevConnections will include a Microsoft day, presumably with future focus, that day may be driven by the same marketing as Build

– DevConnections will feature many high level Microsoft speakers, including Scott Guthrie

– DevConnections has two days of independent content with a long track record of healthy skepticism of Microsoft stuff

– DevConnections speaker and abstract lists (day 2 and 3) are public right now

– DevConnections speakers (day 2 and 3) are independent industry experts, I’m humbled to be in such company

– DevConnections is focused on what devs need today and tomorrow, not next year

– DevConnections has an extremely wide array of topics with seven concurrent conferences – you have access to all

– DevConnections makes a lot of sense for teams that need to bring several members and have them learning different things (data, web and core, for example)

– DevConnections features pre and post conference workshops (for additional fee)

– DevConnections is larger with more opportunity to network with real devs and won’t sell out anytime soon

– DevConnections talks are not recorded – you’ve got to be there (all slide decks are available to all attendees)

– DevConnections has amazing independent speakers that are the best in their field and focus on communicating complex ideas – Kimberly Tripp, Juval Lowy, Ward Bell, Dino Esposito, Julie Lerman, and Mark Minasi represent incredible breadth, and are just the tip of the iceberg – really, go look at the speaker list (you have to look separately for each co-located conference)

– I hate Las Vegas, but the weather is better than Seattle in November

– The Bellagio is nice and if you can’t get your company to spring for it, you can get a deal at many hotels with relatively easy access

– Las Vegas is one of the easiest places to fly to from anywhere (except Fairbanks) and you can lose all your spending money before you even leave the airport

– OK, the taxi queues are definitely better in Seattle, but the venue is closer and access easier in Las Vegas

If you think I’ve missed something for either event, let me know. I’ll try to approve comments quickly.