Creating binary logs from Visual Studio

 [Again, this is mostly for my own reference, so I can find the link again quickly in the future]

It's possible (and well documented) to save detailed and binary log files when compiling code with MSBuild.

But, if you are getting different results when using MSBuild and Visual Studio, it isn't as easy to create the equivalent logs from Visual Studio.

Well, my search-fu may not always find it, but there is a way to do this. Details at https://github.com/dotnet/project-system-tools#getting-higher-fidelity-logs-from-vs-vs2022-onwards 

Testing against old versions of Visual Studio

[This is mostly for my own reference, so I can find the link again quickly in the future]

If developing Visual Studio extensions, it can sometimes be useful (and necessary) to have different versions of Visual Studio installed.

Previously I achieved this by having preview and non-preview versions installed and being careful about how and when I updated them to newer versions.

However, I recently had to also test against a version older than I had installed on any of my machines.

Well, it seems the lovely people on the Visual Studio team already have this scenario covered.

It's possible to get older versions of VS that don't prompt for updates. This allows the installation of multiple versions on the same machine without having to worry about updating them.

Get them from:

https://docs.microsoft.com/en-us/visualstudio/releases/2022/release-history#fixed-version-bootstrappers

Why a bug fix should "always" include new tests

Ok, maybe not always, but please don't start by assuming you're the exception.

(Note that exceptions should come with an adequate, documented explanation.)

So, imagine the scenario: You find something wrong in the code base, so you fix it.

Simple enough and almost certainly a good thing. 

But, consider the bigger goal that we don't just want a codebase with fewer bugs in it we also want a codebase that is easy to maintain, so that future bugs or changes (there will be some) are also easy (and quick) to address.

By adding or changing code without adding tests, we risk making future changes harder/slower.

Going back to the bug you fixed. How was it discovered? I'm going to assume it wasn't because of a failing test.

It was probably found by someone using the code/app/service/whatever or looking at the code. Either way, a manual process.

And how was the change tested? Again, I'm guessing manually.

So what happens when someone has to change something near or related to that code again in the future?

They'll have to test it manually again. But, also, they need to work out (or remember) how to test it manually and work out what all the scenarios they need to test are. Then they have to do that testing in its entirety and without human error. This is unlikely to be fast, thorough, or accurate.

But, also, what if the place where the error in the code was found wasn't the only place that error had been made? Have you really, manually reviewed the entire codebase to look for such an error? How do you know that you really checked *everywhere*? Was that a good use of your time? Additionally, how will you make sure that any future changes to the code don't reintroduce the same bug? Either here or in another part of the codebase? Are you really going to add that to the list of manual checks that are made as part of every code review? I suspect not.

Suddenly, taking the effort to write some automated tests doesn't seem like such a waste of time. Doing so can often be faster than manually retesting something while working on it. Also, having something that checks your code for bad practices, inconsistencies, and anti-patterns is much faster than manually reviewing all but the smallest codebases.

But, what if you don't know how to write tests? Or you don't know how to write a good test for this specific scenario? Well, you find out. Ignorance isn't an excuse.
If working on a codebase as part of a team, ask them. Your whole team wants to work together to create better software and that includes having a codebase that is easy and better for them all to work with.

Maybe I'll write more on getting started with testing or testing difficult things in the future. Don't worry, though; there are a lot of resources about this already on the internet (& elsewhere).

<RantOver />

Why some things never get better

So, imagine you're dealing with a technical problem. 

There's no specific tooling to help with your scenario.

You can muddle through but everything feels harder than you'd like. 

There are a few simple tools or features that would make this much easier. They'd handle the need to do complicated things manually and avoid errors that are easily made when doing things manually.

But, this thing you thought was going to be easy has turned out to be harder and more time-consuming than you had planned for.

You're now frustrated and behind. 

You just need to get this done and move onto the next thing.

You can't justify the time to work on tooling as well as solving the problem immediately in front of you.

The whole thing has become so frustrating that you just want to get it fixed so you can move onto the next task and not have to think about it again.

You certainly don't want to spend more time thinking deeply about the issue. As would be needed if building a tool to help with it.

So you move on to the next thing.

Maybe, you think, you'll come back to this once the initial pain has passed and work on the tooling that will be useful for yourself in the future and for other people too.

But you're busy.

Other things have a higher priority. Plus, you can't fully remember the pain you felt previously. Maybe it wasn't that bad. Maybe someone else will have made something to help when you have to work on something similar in the future.

And so you don't create that tool.

Sometimes things only get better when you take it upon yourself to deal with extra pain so that others don't have to.

Sadly, I'm not able to handle as much of that extra pain or as frequently as I'd like. :(

</rant>