Dot Net What Not Posts

As my regular reader will know, I love anything shiny and new, and so was intrigued when I came across F#. When I was an undergraduate (some 25 years ago, ulp!), I played around with Prolog, and enjoyed the different approach to programming it offered.

However, as my time in front of the computer is at a premium, my F# learning started off with reading books and blog posts late away from the computer, usually last thing at night, and not actually doing any coding. Like most C# developers who come across F#, my initial reaction (other than “Hey, that’s shiny and new, I want to learn it!”) was “Why?” If you search around for terms like “why f#” and “c# vs f#” you’ll find that this is a very common question.

The problem is that the answers aren’t very good. Well, let’s be blunt, there are a lot of lies out there.

Whilst working a WPF window, I ended up dumping loads of small jobs onto another developer, as he was the main one working on the XAML file for the window, and if we both tried to edit the file, we ended up with conflicts. After dumping the umpteenth extra job on him, I was trying to work out if there is a way I could ease his burden a little. There had been quite a few new issues where the extent of my involvement had been to modify the database and update the model. After that, I had to pass it over to him, to avoid us stomping on each other when working on the same files. So, I got to wondering if there was any way we could split the new quote window up, so multiple people could work on it at the same time. I immediately rejected using…

What should have been a relatively easy job turned into a very complex one. How I did battle with SQL Server and (mostly) won. By the way, in case you’re wondering about the title (and the subheading below if you’ve looked further on), then you obviously haven’t read The Hunting Of The Snark by Lewis Carroll. If so, I strongly recommend you do, partly because it’s a wonderful piece of sophisticated nonsense, and mainly because it’s far more entertaining than this article! It was subtitled “An Agony In Eight Fits” with each section being described as a Fit. It seemed appropriate for what happened here… Fit The First – Background I had a request to allow the user to enter some keywords, and we would show all support tickets that used the keywords in any of a number of fields. As SQL Server provides a full-text search facility, this seemed ideal for…

I came across a situation recently in which we needed an object in the client. Due to the cost of creating this object, we didn’t want to create it when loading up the window as it might not be needed (if the user didn’t click the appropriate button), we didn’t want to store it on the window’s main object graph, but equally, we wanted to keep hold of it once it had been created. This situation is not uncommon, where you have to create a class that is expensive (in database or bandwidth terms) to create. The obvious solution to this was to have a private variable for the instance of Expensive, and a second private bool variable to indicate if the Expensive object had been created. We could check the bool before accessing the Expensive variable. Even better, we could create a property that wrapped this up. Imagine our class is wittily…

Every now and then, I have seen my CPU usage jump up to close to 100% on all cores, which can slow things down somewhat… This looks really impressive, like I’m working so hard that my machine can’t keep up with my frantic pace. Sadly, this isn’t always the truth! Looking at Task Manager, shows the culprit to be microsoft.alm.shared.remoting.remotecontainer.dll. If you are using VS2013 or later, and are not using the Community edition, you may notice some annotations above your methods and properties… This feature is known as Code Lens, and is one of those things that is really worth getting to know, as it’s a massive time-saver. Quick digression from the main theme of today’s symposium to tell you why it’s so good… By default, there are about five or six code lenses, but as I’ve changed my options to show only one, only that one is visible in the…

Having blogged recently about some great error messages, I came across another one! Microsoft much employ people to craft these, they just couldn’t be there by accident. I reckon they are put there to amuse developers, and distract them from the fact that the software is misbehaving!

Anyway, I was using the SQL Server Import and Export Wizard, and it threw up the following error message:

Error 0xc004706b: Data Flow Task 3: “Destination 14 – EntityHistory” failed validation and returned validation status “VS_ISBROKEN”

I just love that last bit!

Whilst the benefits of using an OR/M such as Entity Framework are obvious, so are some of the disadvantages. The most obvious one (to me at least, and as I’m writing this article, I can drone on about what bothers me, OK?) is the performance impact. This comes in two flavours, the first-time hit and the not-first-time-hit (OK, so not a great name, feel free to suggest something better). The first-time hit is caused when you do your first query after starting the application. Entity Framework starts up a conversation with the database, queries the structure of all of the tables, and builds the model that you will use to query the database. Other than doing a quiet query when the application loads, while distracting the user with a dancing ferret or something, I don’t think there is a lot you can do about this. The other type of performance…

And I’ve seen a few! I was just trying to back up an SQL database, and got this truly wonderful error message… Not much you can say to that is there?

A quirk I have noticed with Visual Studio (2013 and later) is that sometimes when you break in your code and hover your mouse over a variable, instead of showing you the little pop-up that allows you to examine the variable, you don’t get anything. If you try using the Immediate window to see what the variable holds, you get a really informative message like “Internal error in the expression evaluator” which doesn’t help a lot. This might be a bug in the managed debug engine that ships with Visual Studio. Try turning on Managed Compatibility Mode (which effectively turns it into pre-2013 debug engine), located under Options – Debugging: This fixed it for me. Source: http://stackoverflow.com/questions/21854426/get-internal-error-in-the-expression-evaluator-on-add-watch-function-when-tr

Stopping a build If you are working on a Grown-Up Solution, that has lots of projects, and takes days to build (OK, slight exaggeration, but you know the feeling!), you might sometimes want to cancel a build. This usually happens when you’ve just changed something, started a build and then realised you needed to do something else before trying to build. It’s very frustrating sitting there waiting for VS to finish the build, only to tell you in a smarmy voice that the build failed. “Yes, I know the build failed, that’s why I wanted to stop it you condescending computer!” It’s at this point that you feel like smacking it in the face (or monitor), but you don’t, because you are too polite. What you would really like to do is stop the build. Thankfully there are a few ways to do this, presented here in reverse order of…