Visual Studio 2019 XAML Designer Hang, Crash and BURP…

Recently I’ve been seeing a lot of problems with the XAML Designer in Visual Studio 2019.

It’s always been a little bit iffy, the error “Invalid Markup”, “Check the error list for more information.”, “UserControl is not supported in a Windows Presentation Foundation (WPF) project.” has been cropping up fairly regularly for quite a few months now:

Sometimes the error says “Window is not supported in a Windows Presentation Foundation (WPF) project.” – which is equally as silly in a Windows application, but the usual course of closing Visual Studio and re-opening it makes the error go away.

There is a better way…

Recently I discovered that the Visual Studio XAML Designer runs as a separate process to Visual Studio 2019 (Devenv.exe). This is likely an attempt by Microsoft to overcome the limitations of Devenv.exe still being a 32 bit application with little chance of ever being ported to 64 bit by splitting out areas of functionality into their own processes. Yes it looks like the XAML designer is still only 32 bit, but it means it gets a stab at its own 4Gb of RAM instead of having to share it with the main Visual Studio Process.

Anyway, what it means is that if you come across XAML Designer weirdness as mentioned above, opening Task Manager and killing the Microsoft Visual Studio XAML Designer (32 bit) process:

will give you the following:

Click on “Click here to reload the designer” and normal service wil be resumed.

Saves having to close and re-open Visual Studio – which if you’re like me and have 72 projects in your solution can take some time.

But wait, there’s more…

In additional to the above piffling niggle, I hit a more major problem with the XAML designer the other day when one of the WPF views (a User Control) I was working on refused to load into the designer and hung Visual Studio completely. The entire IDE would lock up, turn light grey when clicked (presumably as all the blood ran out of it) and it would have to be killed via Task Manager.

Other WPF views (user controls and Windows) all loaded fine in the XAML designer, just this particular one would crash VS when loaded.

As you can imagine, troubleshooting this was particularly painful. The usercontrol in question made use of a number of 3rd party controls which rely on XML theming from external DLLs. I found that if I commented out all of the 3rd party themes from being loaded into the application resource dictionary, the XAML designer would no longer crash. The usercontrol wouldn’t display anything as all its theming had been removed. But VS didn’t crash.

One by one I re-instated the theme DLLs until the XAML designer crashed and eventually I found one reference in the resource dictionary that caused the crash… or so I thought…

Red Herrings and other political fish…

I thought to myself, shall I raise a bug on the Microsoft Developer Community Forums? “Don’t be stupid” I replied – why face the humiliation of taking time to report a bug to Microsoft only to have an AI bot close the bug in a couple of months due to a lack of interest.

As it happens I did raise a bug, and this time Microsoft participated with it (yes they required a ton of extra info) but they did engage this time. Anyway I digress, as I actually found the resolution without their help as follows:

Remember I mentioned earlier about killing the XAML Designer process in Task manager, and how it is a cure for all know evils including warts, pox and ugly babies? I decided to try this approach on the hung usercontrol.

I loaded my solution in VS, and viewed the designer for the iffy view.

Right on cue Visual Studio hung, so I went to Task Manager and killed the XAML Designer process, and this time I got the following:

This time I clicked “Click here to enable running project code and reload the designer“, and Bingo! the failed view, the one that had been crashing Visual Studio for the past 3 days, the one that had me doubting my sanity and coding abilities, it loaded fine, and has been doing so ever since.

Problems, problems everywhere…

I might add that the problem first occurred in VS 2019 V16.9.3.

I also have a side install of V16.9.0 and V16.9.10 Preview, because every time Microsoft release an update to Visual Studio they break something, or some times many things. Having several versions on the go means that when Microsoft break Visual Studio I can just load my solution in a previous version that has different bugs that don’t affect me so much.

I had the same problem with all three versions of Visual Studio, but when I fixed the problem in one of them, it was fixed in all three.

So this suggests that whatever the corruption was in Visual Studio, it was common to all side by side installations.

Some say there is a folder in your Windows user profile that serves as a shadow cache for the XAML Designer. Some say that this folder can become corrupted. I have to say I am inclined to believe them. But armed with the power to kill the XAML Designer process whenever it gets out of control, I don’t feel the need to venture any further into undocumented territory.

Overcoming Code Paralysis…

Don’t take it sitting down…

Have you ever sat at the keyboard (or stood if you have one of those new fangled standy-up workstations) and not known where to begin on a new piece of code?

You know what you need to achieve, you know what the code has to do, you know how to code it, but the problem is where do you start?

What classes do you need? What should they be named? What folder should you put them in? What dependencies do they have? Etc… etc…

In the old days (before things like SOLID and TDD) it was straight forward. You would just place your cursor inside Main() and start coding. If Main() grew to more than a few hundred lines long you’d split some of the code out into functions, and resume typing.

Ok, that is a gross over-simplification and generally a lot more craftsmanship went into the proceedings than that. But the idea is the same, we didn’t fear knowing where to start, because it was OK to just start anywhere and crack on with it.

Through complexity comes slightly less complexity…

Now, with SOLID principles, every decision you make is governed by the fear of violating one of them. Am I breaking the Single Responsibility Principle? I really mustn’t new up a class within another class, I need to inject it as a dependency… Are my interfaces getting to big? Are my methods so well named that another coder could understand the intent of my code without requiring comments? Under TDD I need to start off with a failing test and I don’t even know what to name my first class, or what it should be responsible for…

The point is, paradigms like TDD and SOLID are awesome. They are the way to go (most of the time and depending on what you write). But they introduce an additional level of complexity (call it intellectual manageability if you like) that can very quickly induce code paralysis. You end up with so many rules governing how you should create your code that it can become difficult knowing where to start. And starting in Main() is generally not that place.

Q: So what can you do if you hit code paralysis?

A: Put your cursor on the screen and start typing.

It’s really that simple. Don’t just sit (stand) there, code something.

OK, I don’t know what my first class is even going to be called, how am I supposed to write a failing test for a class whose name I don’t yet know?

Don’t worry about it, you can get some code on the go and worry about all that later. Have a look at the following:

Assuming you’re using C# and MSTestV2, but the principles apply to any language and test suite…

Create a new file (anywhere in your project) and call it FooTests.cs

Create the FooTests test class in FooTests.cs.

Create your first test:

There you go, you have your first unit test written, and it will fail. The class Foo() does not exist so the test won’t compile, which is the same as a failing test.

So next you create the class Foo (do this in FooTests.cs – don’t worry about what the class will ultimately be named, or what file it should be in just yet). Remember, we’re just sketching at this point.

PS. In Visual Studio you just need to put the cursor on Foo and press Ctrl+. and select Create Type Foo to have the new class automatically created for you.

Your first unit test should now pass.

Time for the second test.

But what to test for, this is going to be a complex system with many moving parts…

Again, don’t get yourself bogged down with the details just yet. We need to chuck some clay on the wheel before we can make a beautiful vase.

We know our class needs to do something.

Write another test:

There you go, another failing test.

The test fails because the method DoSomething() doesn’t exist yet.

Put the cursor in DoSomething() and press Ctrl+. then select Create method ‘Foo.DoSomething’. This will add the missing method to your Foo class.

Your second test won’t pass because the auto-code completion adds code to throw a NotImplementedException. Whether this exception gets added to your code depends on your IDE settings. For now comment out the throw new NotImplementedException(); exception if one has been created and you’ve got another passing test.

Ok, we’ve got two passing tests. They don’t achieve a great deal in terms of functionality, but what they have achieved is to get us typing code.

You now have some clay on the wheel, a basic sketch on which you can build, and from here you can carry on with the red-green-re-factor approach of TDD as you continue to flesh out some structure and then move on to adding details.

As for the names Foo() and SoSomething(). Refactoring tools in modern IDEs are so good these days that you can easily rename these as you develop and re-factor the code.

When words fail you…

There are plenty of times when I find myself being bogged down with trying to think up a good name for a class or variable. When this happens it will either be because I am tired, or my code is heading in the wrong direction and the naming difficulty is a code smell that I might need to re-think part of the design.

In either case, don’t worry about it.

I just name the class BarrysFishAndChipShop, carry on developing the code, and before too long a better name for the class will present itself. In the case of BarrysFishAndChipShop a better class name will spring to mind quite quickly. But the point is it doesn’t matter what you call a class during the rapid development phase.

Remember that red-green-refactor cycles will usually be under a minute and often only a few seconds. I’m not talking about checking funny class names into source control for others to work on, remember that you are just sketching ideas at this phase and often after a bit of re-factoring the names of things will become very obvious.

The whole point is to snap your self out of code paralysis, and do something. Anything. Even BarrysFishAndChipShop.OrderMushyPeas() if you have to.

Invest in your own knowledge

Expensive books are cheap

Back in the 1990s books about programming were about 1,000 pages long and cost £50 GBP each (and that’s in 1990s money where you could literally buy a second hand car for that amount, and it would actually drive). There was very little on the internet – especially as I didn’t even have access to it until 1995, and books were pretty much the only source of learning other than chatting with other developers or going to University.

Programming doesn't have to be painful...

I remember a conversation on Usenet (which was a kind of online newsgroup back in the day where like-minded people would gather together to get angry with new people) where someone asked what was a good book for learning C++. One chap answered that he tried to buy at least a book per week on the subject, and this struck home with me.

You see, up until that point I had considered books to be extremely expensive things and you had to make a careful choice as to which one you invested in. What I didn’t appreciate at the time was that when you’re in a field such as software development, the £50 you pay for a decent book can be earned in a single hour as a software contractor. This was a turning point for me, no longer would I be starving my brain of the knowledge it craved, I too would own more than one book about C++. In fact there were times when I bought more than one book in a week.

Another benefit of owning multiple books on the same subject is that you will be getting multiple viewpoints. One author might be an expert at one particular aspect of a programming topic, another author an expert in a different aspect. Yet another author might not be an expert in any of the aforementioned topics, but has 40 years’ experience and pretty much knows what not to do in a given situation etc… Gain your knowledge from as many sources as you can and you shouldn’t end up with any blind spots.

Don’t read programming books

Once I bought a book called “Teach Yourself C in 21 Days”.

After 21 days I still couldn’t program in C and I felt cheated. The book title was a scam and I had been tricked. Afterall I had read most of the chapters in the book, and seemed to understand most of them.

I have to admit it was some time in the future where I realised the problem was with me and not the book. What I had done is read the book without typing a single line of code. It’s all very easy to read a programming book and think “yes, yes, all very straight forward”, but when you sit at a keyboard without the book somehow the obviousness of it all seems very far away and you realise you actually remember very little. Something to do with void and main, or was it main and void?

In order to learn programming, you have to write code. Don’t just read programming examples, sit there and type them in. Even if it seems really obvious to you, type in the examples and run them. I still do that today (sometimes). Recently I bought a book about automated testing using Selenium and practicing what I preach I typed in the code samples from the book. This gave me a real feeling of understanding and the knowledge imparted was much more persistent than if all I did was read the examples and not physically implement them. What’s more I had to resolve issues with the programming environment and other such hurdles which helps give you that working knowledge.

It’s a similar concept to studying at school where hand writing things into an exercise book helps you commit the information to memory far more effectively that just sitting back and listening to a lecturer.

Don’t read programming books, type them into a compiler.

Don’t watch free videos

I think you probably know where I’m going with this…

There are lots of free programming tutorials on YouTube, some of them are even good. But there are a lot of low-quality tutorials out there and finding really good learning material is difficult.

There’s a good reason for that. YouTube is incredibly stingy when it comes to paying its contributors, which means that the highly talented and learned people that you would want to watch on YouTube can’t be tempted to get out of bed to make a video. I hear you cry “but there are YouTube millionaires out there!”, which is true enough. But if you look at the number of views a programming tutorial about “Unit testing with MSTest V2 and C#” gets compared with the number of views a video about eating washing detergent tablets whilst giggling through a game of MineCraft gets, you can see why people eat detergent and film themselves doing it. Let’s face it, a video of someone explaining Liskov’s Substitution Principle isn’t going to go viral, even if they do have soap coming out of the corner of their mouth.

Free videos on YouTube will get you so far, but for good quality tutorial videos you’re going to need to pay for them.

Uncle Bob Martin videos (cleancoders.net) is an excellent source of paid for videos on the topic of software development craftsmanship, and the several hundred dollars they will cost you will repay themselves many times over.

Similarly, PluralSight.com is an excellent source of quality programming videos which are way higher quality than anything you’ll find for free.

Also check out bobtabor.com – Bob Tabor is an excellent instructor and all-round nice guy as well.

Do Your Homework

The software development business is like no other in terms of how much it evolves over time. Frameworks appear and go into legacy support faster than you can become an expert in them, and there is a continual forward movement towards newer and “better” programming paradigms.

That’s not to say everything gets replaced. If you learned a flavour of SQL back in the day it will still be relevant today. But have you familiarised yourself with No SQL databases, or immutable data storage? Have you embraced LINQ?

The changes in our industry are constant and persistent. Sometimes fast and furious but more often subtle and unseen. One day your pretty much up to speed with the latest developments, your programming tools are modern, up to date and razor sharp. The next day you wake up to find you’re a dinosaur. While you were asleep things moved on, and your code is now legacy and your tools are covered in a thin layer of rust. One day you’re cock of the walk, next day a feather duster…

Q) How can you avoid the fossilisation process?

A) Homework.

Yes, good old homework. Many of us spend our days using existing knowledge and tools to earn a crust. We barely have time to get the days work done let alone take time out during the day to gen up on the latest programming paradigms, or to play with new tools. So the only option that lies open to you is to make some time at home and do a bit of homework.

Now you don’t have to stay up each and every night studying computer science from leather bound books. You’d pretty soon get bored with that and stop doing it altogether. Rather try to do little and often. If you’ve heard someone talking about this magical new programming pattern, take a few minutes one evening to look it up. If someone uses a phrase you’re not familiar with (I remember hearing “Idempotent” for the first time and wondering what Egyptian Gods had to do with coding), look it up and find out what it means. If you’re being left behind because you don’t understand automated testing, go back to the beginning of this post, buy two books on the subject and read them while you’re having a bath, then as you’re drying off crack open a test project and have a play.

MDI Returns to Windows!?

For those of you that aren’t familiar with it, MDI (Multiple Document Interface) is a technology that used to be included in Microsoft programming frameworks that allowed you to create Windows that contained other Windows. A good example of this would be an application like the older versions of Adobe Photoshop CS or Adobe Reader V6.

As above you can see that in Adobe Reader 6 you can have multiple documents open at the same time, all within Adobe Reader. This is MDI. This worked well for applications such as Photoshop because it meant you could have many images open within Photoshop all at the same time.

MDI was built into WinForms, which meant that if you wrote a Windows application using WinForms, you could make it an MDI application. Microsoft never really liked MDI, and when they released WPF (Windows Presentation Foundation) in 2006, they took the opportunity to drop MDI altogether.

You might have noticed around that time that Microsoft Office (Word and Excel) stopped being able to open multiple documents, and instead each document you opened, opened in a separate instance of Word or Excel.

This behaviour is SDI (Single Document Interface) which is the opposite of MDI.

Incidentally, you can also have TDI (Tabbed Document Interface) as you would find in most modern web browsers. One tab for each web page.

Ok, so big deal. Microsoft dropped support for MDI after WinForms you might say. What’s the problem with having multiple instances of an application open? Well for a lot of applications SDI is fine. Having multiple instances of Word opened isn’t a big problem, other than you can no longer minimise all your open Word documents with a single click. The bigger deal was for applications like Photoshop.

I remember when Photoshop CC came out, and Adobe had ported it to WPF (I presume it was WPF). Photoshop was no longer MDI and it was horrible. You would open Photoshop, and then open a few images, and the images would all open in separate Windows not really related to the main Photoshop Window. The taskbar was littered with an icon for each open Window, and often times image Windows would get lost behind the main Photoshop Window. Also, when you opened an image in Photoshop, the tool buttons in Photoshop wouldn’t work unless you specifically clicked the Photoshop title bar to focus the main Window and activate it. You could minimise Photoshop and all your images stayed where they were.

Things have improved since then, and Adobe have done a lot of work on trying to fake the MDI experience, but it’s still not as slick as it was and I imagine it took a lot of effort (wasted effort) for their coders to restore the functionality we once took for granted.

Like I said, you might not lose much sleep over the loss of MDI, it’s a fairly niche layout and it doesn’t make sense everywhere. But a lot of people lost sleep when Microsoft went one further than getting rid of MDI, when in 2012 they tried to get rid of Windows altogether…

Yes folks, Windows Metro AKA Windows 8. With the “Metro” user interface, Microsoft “evolved” the operating system so that you couldn’t have any Windows. Metro applications opened full-screen or nothing. They did allow you to have two applications side by side, but no more floating Windows on a desktop that you can position where you want. No, the concept of “Windows” itself was under threat of extinction by the very people that made it so popular.

Luckily two things happened around this time. Firstly Microsoft had the wisdom to leave the core of Windows in Windows 8, in other words you could navigate to the Desktop (even though they tried to hide it) and still run your old WinForms and WPF applications much the same way as you always did. And secondly, the users absolutely hated Windows 8 (or more specifically Metro) and refused to use it which helped with the (much appreciated) u-turn that was Windows 10.

So what has Metro got to do with MDI? Well, it’s another example of Microsoft deploying a big change on us that isn’t necessarily for the better. First they take away your MDI, then they take away your Windows. Ok but seriously, the move to Metro was really just Microsoft’s knee jerk response in terror of the iPad. They really believed that the whole world was heading into the “Post PC era” as promoted by Steve Jobs (ironically just prior to the post Steve Jobs era)”.

As it happens, Metro subsequently had its name removed and was re-born as UWP (Universal Windows Platform). And lo they repented and didst allow UWP applications to run in floating Windows. But that’s another story.

Ok, back to MDI.

We’ve been told over the years that MDI is bad, and you would see people on Stack Overflow saying things like “Well, if you need to use MDI in your application it’s a code smell” or “There are better alternatives to using MDI” or “If you implement an MDI application you will end up with ugly offspring and pimples!”. However the fact remains that MDI is the perfect UI choice for a certain type of application and it really ought to be in the Windows programmers toolbox.

Fast forward to now, and this is where things get interesting.

The other day (Feb 2020) I installed Visio 2019 on my new PC. I needed to do a flowchart for some legacy code I wanted to modify and re-factor. After opening a flowchart I noticed this:

Visio 2019

I opened another Visio document and clicked on the View -> Window -> Cascade menu button and poof!

Visio 2019 MDI User Interface...

MDI!

Visio 2019 has an MDI user interface!

I can only presume that the Microsoft Devs didn’t code Office 2019 using WinForms, which suggests that they have either hand rolled their own MDI framework for their own internal use, or there exists an MDI framework from Microsoft that might one day be available to us mere mortals?

Even if this is a piece of internal Microsoft only code (it wouldn’t be the first time like the Office menu ribbons), it is still monumental in that someone at Microsoft has sat down at a meeting and said to the others, “You know what? We need an MDI user interface for this”.

And when the music resumed, they were all playing MDI ragtime.

Hello, world!

This probably the first time I have installed WordPress and left the original “Hello, world!” placeholder post intact. Seeing as this blog is going to be about software development I couldn’t think of a more appropriate way to begin.

Anyway, welcome! Come on in an have seat. I’ll just move those books, and mind the cables by the way. Coffee? Stupid question.

If you’re wondering who I am, have a look at the About page. It’s like the first couple of pages of my user guide, the bit where it congratulates you on buying the code-o-matic five-thousand and where it promises years of dedicated service and enjoyment as long as you clean it with a lint free cloth.

Oh, and you might be wondering about the name of the site? No, not the blog part, the radboogie bit. That’s a story for another day, and harks back to my time spent programming the Commodore Amiga. Ah, jumpers for goalposts…

Easify UK Stock Control Software