Open URLs in the error/warning description

It can be more effort than it feels necessary to navigate to a URL in a message description.

To get to it you might type it into a browser, or more likely, copy the whole message and then copy the URL and then paste it into a browser.

But, you're a busy developer. You have better things to spend your time on than unnecessarily cutting and pasting URLs that you can't easily open.

What you need is a way to open that URL in a browser without all the faff.

Congratulations, you're in luck. I've just updated my Error Helper extension to enable just this scenario.

After you install the extension, you can simply right-click on the entry in the error list and select Open URL. I'm sure you can guess what will happen then ;)

What could be simpler?

And for the avoidance of any doubt, the other options highlighted above will copy the description of the selected entry into the clipboard or search for the description in your default browser.

If you haven't already go install it now.

Don't just take my word for it, here's what others have said.

Controversial idea: Get rid of the XAML Image tag

Here's an idea I've had swimming around in the back of my brain for a while. I've not yet settled on it 100% yet, but when I do, I'll start some proposals, and discussions with the appropriate people/organizations/repositories.

This is me writing down my ideas to help better think them through and for those of you who come across this page to have a chance to share your thoughts.

Let's get rid of the <Image /> tag!

I acknowledge that this is a potentially controversial idea and it would be a BIG change to a lot of people but I think it has the possibility to advance XAML based development in two important areas: semantics and accessibility.

Semantics
I'm increasingly persuading myself on the benefits of improving the intent of written XAML. Having a generic image tag only communicates that an image should be displayed but provides no information about how that image is used within the UI. This is far from optimal. Alternative/replacement controls could do a better job of communicating intent and aiding the readability of the code.

Accessibility
The vast majority of XAML based apps that I've seen make little or no regard for accessibility support and how screen-readers work with images in apps created with XAML. While HTML and the web are far from perfect, they do a much better job of encouraging people to use "alt" tags on their images. As accessibility and inclusive design continue to grow in importance and consideration for all users of all software, I expect an increased need for XAML based UIs to be asked to do a better job in the coming years.


How would we get rid of it?
In an ideal world, I'd mark it deprecated and then rename it (to BaseIamge) and make it abstract. I'd then add tooling to indicate it shouldn't be used and a suitable replacement is used instead.
The tooling part is easy (:wink:) but the other parts would cause A LOT of compatibility issues. I'd settle for introducing alternatives and recommending they are used instead. I don't really expect to be able to change the current Image tag.

What I propose we have instead

I propose adding two new controls to replace (or be used instead of) the current one: BackgroundImage and ContentImage.

BackgroundImage
This would support an image source and be almost identical to the current Image control. The difference would be that this would never show up in accessibility tools. It's just a background, so it doesn't matter if some users of the software don't know about it. The name also communicates to future developers that this is just part of the background and shouldn't host anything important like the content.

ContentImage
This would be like the existing Image control but also add a required description property. The value assigned to this property would be made available to accessibility tools so that anyone using the app but unable to view the image wouldn't miss out on important content information.
The description could also be used as a fallback if the image couldn't be used, similar to how alt text is displayed on websites when images don't load.
Tooling could easily be added to check that this property is set and a suitable (non-empty) value is provided.

I might have missed something obvious but I think almost all uses of images in apps could be classified as background or content.

That's it. It's quite simple.

• Stop using Image.
• Use BackgroundImage for visuals that aren't important and only part of the visual aspect of the page.
• Use ContentImage for pictures that do contain important information that should be communicated to the user even if they aren't able to view the image.

As this is the internet, feel free to tell me why I'm wrong, what a silly idea this is, and the obvious things I've overlooked. ;)

Introducing: Clearly Editable - making it clear which documents can be edited in Visual Studio

The way some people* use Visual Studio means that they may use or open generated or read-only documents.

There can be lots of reasons for this:

• They might generate code with a tool.
• They may need to debug the compiler-generated code.
• They might use a version control tool that locks files by making them read-only.
• Many other, valid, reasons...

When working with such files, it can be REALLY frustrating when:

• you start typing in a document but nothing happens (because it's read-only.) or
• you make some changes in a generated document (because you don't realize it's generated) and those changes are lost when the file is regenerated.

Visual Studio already has some ways to try and help avoid the above scenarios but they're not always enough.

When a read-only file is open this icon is shown in the tab.

But it's small and easy to miss.

Generated documents typically have a comment in the header of the document to point out that it's been generated and should not be edited directly.

//---------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//---------------------------------------------------------

But, comments aren't always read, or even visible. It can also be easy to forget that a document is generated when switching between documents or if it's been open for a long time.


I present an alternative solution.

It changes the background color of the editor to make it harder to forget or miss if a file is read-only or generated.

The image below shows three open documents.

• The document on the left is a generated file and has the background set to a pale green color.
• The middle document is a read-only file and has the background set to a pale red color.
• The document on the right is neither generated or read-only, just like most files you work with and so there are no modifications to the configured theme colors.

The intention here is that different background colors are harder to miss.

The colors are configurable.

Change them to what you prefer and what works with your other theme/color settings.

You can set the color by specifying a color name or an RGB HEX code.
Opacity is set by providing a percentage so that is can work with named colors and because calculating RGBA (or ARGB) isn't the simplest thing in the world for everyone.
You can also disable the highlighting of either type of file. Or, disable all functionality without having to uninstall the extension and restart Visual Studio.

Go to Tools > Options > Clearly Editable

Give it a try by installing it from the Visual Studio Marketplace.
If you like it, please leave a review.
If you encounter any problems or have suggestions, please open an issue on GitHub.



* If this isn't you, that's fine. I have other extensions that might be useful to you.

VB.NET is done, not dead

What's the future for VB.NET?

• Visual Basic (VB.NET) will continue to be supported by Microsoft. (It's not dead.)
• The language will no longer have new features added to it. (It's done.)

---

This post on Visual Basic support planned for .NET 5.0 has caused some to complain that Microsoft is abandoning or killing Visual Basic. Discussions on plans for alternatives or open-source continuations or extensions to the language have picked up.

In amongst all the hype, hyperbole, and over-reactions, it's important to take a step back and think about the big picture.

There are plans from Microsoft to continue to support Visual Basic going forward.

• If you use Visual Basic to build software based on the .NET Framework that will continue to work and be supported.
• If you use (or want to use) Visual Basic to build software based on .NET Core (& .NET 5 going forward) that will work and be supported. And, as per that blog post, more application types will be supported than are currently.

There are plans to stop evolving the language and adding new features.

• Adding new features makes it hard for people new to a language to learn it as there is more to learn. Visual Basic has always focused on making it easy to get started.
• Every language doesn't need every feature. 
• It's ok to use more than one language. No, you can't use them in the same project, but you can use them in different projects in the same solution.
• This may mean that there is future functionality added to .NET Core that isn't as easy to use in Visual Basic. I'm sure workarounds and alternatives will be found though. A similar impact has also been had on C# where there are C#8.0 features that can't be used in software based on .NET Framework. At least VB developers will be spared the "what features of the language can I use in this code-base?" question.
• Trust that Microsoft isn't making this decision to be difficult or pick on people who like using Visual Basic. Assume this is a business decision based on lots of data and discussion with the understanding of the consequences of doing this, as well as the benefits that can be gained by focusing efforts elsewhere.

If all you know is Visual Basic and you worry your skills are becoming less relevant, don't panic.
Learning new programming languages can be easier than you might imagine and typically brings insights into how you may want to use the language(s) you already use.

Also know that you know more than just a programming language.

• You know how to put software together.
• You know what good and bad coding practices look like.
• You know how to work with other developers and other people in a business to deliver a software product.
• You know how to solve problems when code doesn't do what you want.
• You know how to ask and look for help.
• You know what people using your software do and don't want.
• You know much more than just a programming language.

Of course, things may change. But this is the world of technology. New things are created, adoption and usage changes, and older things are used less. Software is a world of constant change. If that's something you can't cope with it might not be for you.


And remember:

This t-shirt is a reminder that developers who aren't using the latest, shiny, new technology are important too. #MVPBuzz ;) pic.twitter.com/n2Asge0KGS

— Matt Lacey (@mrlacey) March 16, 2020