Wednesday, August 12, 2020

How to do handle Master-Detail scenarios badly


You have a list, grid, or some other collection in your software (app/website/other).
Someone clicks, taps, or otherwise selects one of the options and is presented with a new page/window/screen/display showing more information or a different view of the option chosen.

That's the basic "master-detail" functionality.
It's straightforward, but there are at least five ways to mess up this experience.
  1. Not remember the position in the list when going back to it.
  2. Resetting the scroll position of the list when returning to it.
  3. Reloading the master list when returning to it.
  4. Resorting the master list when returning to it.
  5. Removing detail from the list and then returning to the list and seeing it there still.

1. Upon going back from the detail to the original collection, the software does not remember which item was previously selected. The focus may be moved elsewhere, or the first item in the list may be selected by default. Such behavior makes it hard to browse using only the keyboard or assistive technologies.
This is exacerbated when the resetting of the list moves the scroll position.

2. You scroll down the list, so none of the items that were initially visible are shown. You select one, view it, and then go back. Imagine then if the list has reverted back to the "top." If you want to keep looking at the options available, it's necessary to scroll back past all the items you've already seen just to get to something new.
It gets worse when the list loads in "pages" of data at a time.

3. You scroll down the list. You get to what is currently the bottom of that list until the software automatically retrieves and then displays more items so you can keep browsing. After doing this a few times, you select one, view it, and then go back. If the master list goes back to the "top" of the list, to get back to where the item you just viewed is shown, the app must repeat the calls to load more "pages" of data. 
It gets even worse when the list isn't always in the same order.

4. You scroll down the list with an expectation to look at multiple items. You reach the first item of interest, select it, view it, and then go back. How frustrating is it then if the list is in a different order? Is it reasonable, practical, realistic, or even possible to remember which items have already been viewed? How can a person be expected to find and view everything of interest in a large list that is constantly changing?
Also bad is when lists aren't updated when they should be.

5. Imagine browsing a list of favorites or bookmarked items. You select and view one of the items. While viewing it you remove the bookmark or other indication that it should be in the special list. What then should you feel if the item you've just removed is still shown on that list?


What other examples can you think of how this experience is often poorly implemented?

Monday, August 03, 2020

Fixing a really common misunderstanding about nuget.exe

It turns out that a lot of people commit a copy of nuget.exe into their code repositories.
Some of them used to be mine. Not anymore.

screenshot showing the number of copies of nuget.exe found when searchiGitHubng


tldr: don't include a copy of nuget.exe in your repository. Instead, add a reference to Nuget.CommandLine and use the copy of the exe the package provides.


It's rare to think about how NuGet works. You can just add the packages to your project, they get downloaded, referenced and everything just works.

But there are some things you might do with NuGet where you can't rely on MSBuild (or similar) to take care of things for you.

You may have to call `nuget.exe` directly.
I've had to do this many times and when doing so it's raised a tricky question.
"Where is nuget.exe located?"
Across all development machines and build/CI servers, there's no single answer.
You can't rely on it being in a particular place. unless you put it there.

So, how do you put it in a specific place?
I've never found any documentation to explain this and so put it in the repository with the code/scripts/whatever that needed it.

It never felt like the right thing to do but I didn't know any better and it seemed to work ok.
As we saw above, I'm far from the only person to have done this.
The only time this became a problem was when I needed to change something that called nuget.exe and needed a feature that was added in a newer version than the one I had checked in. Not a big deal but another reminder that this isn't the best way to do things.

A couple of weeks ago I stumbled across the NuGet.CommandLine package. Again, documentation of this package wasn't something I could find but the name had me wondering. "Could this be the way to perform the command-line NuGet operations I've always wanted?"

Some investigation was needed.

I started by downloading the package and looking inside.

Nuget Package Explorer showing nuget.exe in the tools directory of the package

Bingo! That looks exactly like what I need.

Now, how to reference it?

Fortunately, this is where some documentation did come in handy.

By adding `GeneratePackagePath="true"` to the PackageReference element I could have a way to get access to the version of the executable from the package.

partial view of the project file showing the PackageReference entry with the GeneratePropectPath property set

Now to use it.

By adding this property a new build parameter is created. It has the same name as the package but with two differences. Firstly it's refixed with "Pkg" and secondly, is has non-alphanumeric characters replaced with underscores. so, in this instance, the parameter is called `PkgNuGet_CommandLine`.

With this all set, I could now reference the version of nuget.exe that was downloaded as part of the package by specifying `$(PkgNuGet_CommandLine)\tools\nuget.exe`. As an example, see this targets file, which I use to automatically pack and sign release builds of packages.

That was it. Simple really, but poorly documented. I was surprised how easy it was to fix and why I've never seen anyone mention this before. Maybe other people do talk about this. Maybe other people know this already. That the package has sooooo many downloads makes me suspect that many people do already know this. But the number of repositories containing this file on GitHub also makes me certain I'm not the last person to learn about this.
If you're in the position I was, I encourage you to make the switch to using the package reference instead. Not only will you save a bit of space in the repository but, more importantly, you'll be able to learn when newer versions of the exe become available when a new version of the package becomes available.

---

I originally investigated the above while streaming on Twitch.  I like to stream there while investigating or researching topics as it forces me to articulate what I'm thinking, doing, and looking for, without getting distracted. Hopefully, it serves as an interesting way for others to learn what I'm learning. Follow me on Twitch to learn when I next do things like this and we can all learn together.

Monday, July 13, 2020

You've only added two lines - why did that take two days!

It might seem a reasonable question, but it makes some terrible assumptions:
  • lines of code = effort
  • lines of code = value
  • all lines of code are equal
None of those are true.

Why did a fix that seems so simple when looking at the changes made take two days to complete?
  • Because the issue was reported with a vague description of how to recreate it. It took me several hours to get to a reliable reproduction of the item. Some developers would have immediately gone back to the person reporting the problem and required more information before investigating. I try and do as much as I can with the information provided. I know some developers don't like having to fix bugs, and so do whatever they can to get out of it. Claiming there isn't enough is a great way to look like you're trying to help but not have to do anything. I know that reporting errors can be hard, and I'm grateful for anyone who does. I want to show appreciation for error reports by trying to do as much as possible with the information provided before asking for more details.
  • Because the reported issue was related to functionality, I'm not familiar with. The feature it was to do with was something I rarely use and is not something I've ever used in great detail. This meant it took me longer than it might to understand how to use it and the nuances of how it interacts with the software with the bug.
  • Because I took the time to investigate the real cause of the issue, not just looking at the symptoms. If some code is throwing an error, you could just wrap it in a try..catch statement and suppress the error. No error, no problem. Right? Sorry, for me, making the problem invisible isn't the same as fixing it. "Swallowing" an error can easily lead to other unexpected side-effects. I don't want to have to deal with them at a point in the future.
  • Because I investigated if there were other ways of getting to the same problem, not just the reported reproduction steps. One set of reproduction steps can easily make the error appear to be in one place when it may actually be more deep-seated. Finding the exact cause of a problem, and looking at all the ways to get there can provide valuable insights. Insights such as how the code is actually used, where there might be other places with possible (other?) problems that might need addressing, or it may show inconsistencies in the code that mean an error is caused (or handled) in one code path but not another.
  • Because I took the time to verify if there were other parts of the code that might be affected in similar ways. If a mistake led to the bug, the same error could have also been made elsewhere in the code-base. Now's a great time to check. 
  • Because when I found the cause of the issue, I looked to find the simplest way of fixing it that would have minimal risk of introducing side-effects. I don't want the quickest possible fix. I want a fix that isn't likely to cause confusion or other problems in the future.
  • Because I tested the change thoroughly and verified that it addressed the problem for all the different code paths that were affected. I don't want to rely on someone else to have to test that what I've done is correct. I don't want a bug to be found in the future and for me to have to come back to this code when I've mentally moved on. Context switching is expensive and frustrating. Having a dedicated tester have to look at the "same" change again is something I want to avoid whenever possible.

I don't like having to fix bugs. Partly because they can feel like the result of a previous failure on my part. The other reason I don't like fixing bugs is that I'd prefer to be working on new things.

What's worse than having to fix a bug?
Having to fix the same bug repeatedly.
I take the time to make sure any bug is totally fixed any time it is encountered so that it doesn't need to be faced, investigated, fixed, and tested more than once.


Tuesday, June 30, 2020

Announcing: Rapid XAML Toolkit release 0.10

Yes, 0.10 means it's getting excitingly close to a full 1.0 release and the removal of the preview tag.
Wider events and that some of what I'm trying to do with the toolkit has turned out to be much, much harder than I originally expected and means it's taking longer than I hoped but progress is being made.


What's new?

There are three big new items with this release:


  • 1- Custom XAML Analysis

I compare the XAML Analysis functionality to Roslyn Analyzers (and code-fixes) for C# (or VB.NET). The big difference is that you can create your own Roslyn Analyzers to check (and fix) code in any way you wish.

There are more details in the official docs, but the way it works is:

- Create a 'Custom Rapid XAML Analyzer' project (This template is now part of the toolkit.)
- Specify the type of element the analyzer relates to.
- Add the logic for analyzing the element and indicating what actions, if any, should be displayed.

It means you can easily create things like this:


The code for the above is a proof-of-concept and can be seen here. Hopefully, it's easy to read.
The method queries an object representing the XAML in the document and returns a response that handles what to display and what, if anything, to do to fix it. The tool takes care of all the interaction with Visual Studio and making the changes. You can't do *everything* but hopefully, it's most, if not all you need.


  • 2- Perform XAML Analysis at build time

The Visual Studio extension does analysis at design-time. It gives feedback on the documents you have open.
This new package allows for the evaluation of ALL the .xaml files in a project when the project is built. This means you won't miss something in another file. It means you can check files that anyone works on, even if they don't have the extension installed. It even means you can incorporate analysis checks as part of a CI/DevOps process. Don't want someone to check-in invalid XAML to your repo?--now you can. ;)
Yes, this also works with custom analyzers.




What's still to come?

There are a number of little things I still want to add before calling it version 1.0.
There are also a few bugs that need fixing and some experimental ideas that might get in for the 1.0 release.


Background

If you don't know. The Rapid XAML Toolkit started out as an open-source project in a Microsoft repo on GitHub as a collection of tools to make it easier to create and work with XAML files, whether that be in WPFUWP, or Xamarin.Forms apps. Last year the decision was made that it wouldn't be released by Microsoft and the functionality wouldn't be incorporated into Visual Studio. So, I, as a major contributor, took ownership of the repo and will be releasing it myself.
I believe it contains useful functionality that will empower every XAML developer on the planet to achieve more.


What now?


If you had the preview version installed (the one called "Rapid XAML (Preview)"), you should uninstall that first.

  • Give feedback - in whatever way works for you. Here, on twitter, or on GitHub.


Monday, June 15, 2020

Never set 'Copy To Output Directory' to 'Copy always'

What if there was a simple setting that could save you hours?

Visual Studio Properties window showing the "Copy to Output Directory" setting

I thought there was something wrong with the Test Explorer.
I'd make a change in a configuration file that was used by some of my automated tests. Then I'd run all the tests again to see if that broke/fixed anything.
Only, it would take a couple of minutes - before the tests even started! Because the code was being recompiled first.
I would get frustrated.
I would lose my flow.
It was not an enjoyable or productive situation to be in.

And, I thought the culprit was the test harness. Why was it triggering a rebuild of the code? And a rescanning of the built assemblies to look for tests? When nothing in the code had changed?
All that was changed was an external file that was referenced by some of the tests.

It turns out, the problem was due to my lack of understanding of how MSBuild works and how the value of the Copy to Output Directory property is used.

---

For years I've been concerned by the number of times I've heard developers told to set the value of the Copy to Output Directory property (to a value other than "Do not copy") for files that have no need to be copied to the output directory. It seemed like a waste of effort. If the file wasn't needed in the output directory, why waste effort (admittedly--not a lot of effort) copying files around? Ultimately, this didn't seem all that important. I found more important things to focus on and stopped worrying about other people copying files unnecessarily.
Maybe I shouldn't.
Maybe I should have actually learned more about the setting. It may have helped me sooner.

---

I lived with it, taking a while to rebuild and then run my tests. Until I couldn't.
A few weeks ago, I reached my breaking point. I couldn't take it anymore. I would find out why my code was being rebuilt unnecessarily. Even if it took days, I would be better off in the long run to address this delay. If it was something I was doing, I'd fix it. If it was a genuine bug in the tools, I would find out where and raise it accordingly.

You're smart enough to know that I wouldn't have gotten this far if I didn't have a conclusion to this story. I know you've also figured out from the title of this post what the solution was. Anyway...

It took me the best part of the day reading through diagnostic build logs and testing me to the limits of my web-searching abilities but I got there in the end.
The "culprits" were files with the "Copy to Output Directory" set to "Copy always".

Ok, but why?

That's a very good question, and one I asked too.

It turns out that the behavior is due to the way this value is interpreted.
If you know that you always want the latest version of the file in the output directory, under some conditions, it can be quicker (and easier) to copy the file than spend time determining if the files are different.
That's good, but why does it trigger a rebuild? Why not just copy the file built previously?
Because the file built previously may have been modified (or created) by the build. The build process interprets "Copy Always" to mean "copy the file once the build has completed, so it's the most recent version." Because the build process may modify the file, it must rebuild the project to ensure that the file is the latest version. This is easier than trying to work out if the file will be changed by the build process before it is run. (If that's possible at all.)

So, to make that clear:
- "Copy always" means "make sure I always have the most up to date version."
- Because the build process may modify the file, the build process must be run to make sure you have the most up to date version of that file.

As an alternative, "Copy if newer" won't force a rebuild. The argument for why this is the case is (in my opinion) a bit vague, but it avoids those unnecessary builds, and that's what I'm interested in here.


Given how it works, why might you ever want to use "Copy Always"?

I don't know an official reason, but the only one I could come up with is if you needed a file to have a timestamp that corresponds to the build time. That's it.
I can think of no other reason to use the setting "Copy always." Please share if you have another.



Ok. So, what can you do to make sure you're not using the "Copy always" setting?

There are three options.
  1. You could step through every file and check the property. - Very slow. Very tedious, and likely you might miss something.
  2. Open the project file in a text (or XML) editor and check or make changes there as necessary. - Slightly easier but a hassle if you have lots of projects and not something you'll want to do repeatedly.
  3. Install this extension, and it will check every project for you whenever you open one. If it finds a file with the dreaded "Copy always" setting, it will let you know in the output window. It also adds a context menu entry on the project file to fix (change to "copy if newer") all files in that project.


Partial screenshot of entry in context menu


Please install this Visual Studio extension and let me know how you find it or if there are any scenarios it doesn't handle.

.


Was the above useful?
Did you learn anything?
Have you changed a project (or projects) you work on because of this?
Have you thought about how much time this can save you? How much time is spent on each unnecessary build?
How many times each day is your code rebuilt when nothing has changed? How many days will you spend (have you spent) working on that code? How many people are/will working/work on that code-base?
Could it add up to hours?
And how much is an hour worth to you? Or the company you work for?
Isn't that at least worth buying me a coffee to say thank you?
While we can't do it in person, you can do it virtually via https://www.buymeacoffee.com/mrlacey.
I'll be very grateful for whatever you can contribute.
Or, you could sponsor me to continue to create tools like the extension mentioned above by becoming a sponsor on GitHub.

Monday, June 08, 2020

The idea that making code open-source won't cost a company anything

It’s been a while since I’ve heard the idea that “making {some software} open source won’t cost {company} anything,” but I did today.

Not being able to find an existing list of reasons why this isn’t the case, here are a few quick thoughts:

  • Any change in ownership requires people to make decisions and take action. Doing so requires more time than it takes to open a repository, copy some files, and push the commit. Time takes money, and so has a cost to the company.
  • The code must first be checked for the risk of revealing any potential security holes. Detailed code reviews take time from experts, and so aren’t free.If the released code risked showing a potential vulnerability to existing users of the software, that’s something the company will need to address. It might be easier/cheaper not to release the code.
  • The code must first be reviewed for IP and licensing issues. Does the company want all the code released under an open-source license? If not all of the source code (and assets) can/should be released, what should they do about the parts that can’t?Or what if the code depends on libraries or other licensed resources from elsewhere?
  • The ongoing management of an open-source project takes time (and therefore money.) If the intention is to create an ongoing, community-driven project, it will need (at least initially) some leadership and guidance. Releasing the code under an opensource license and then leaving it for anyone to do with it as they wish, is less likely to lead to a single release that continues the legacy of the original.
  • If releasing the code for use as anyone wishes, then pre-existing branding, trademarks, names, etc. must be removed or changed. If not performing such modifications before the code is released, it may be necessary to verify that anything released based on the original source has such identifying elements removed. 




“Cost nothing” is not the same as “won’t cost much.” If you’re trying to persuade someone to do something, being specific, and understanding what matters to them and how they make decisions can help build a persuasive argument.



An additional nod to S├ębastien for pointing me to this explanation of turning Windows Live Writer into Open Live Writer as an example of the steps/processes involved that must have cost effort/time/money.

Wednesday, May 27, 2020

My first Visual Studio Code extension - Git Status Backgrounds (GitStatusBg)

tldr: get it from here and try it out.

I was part of an email discussion about changes that could be added or made to Windows to make it better for developers.
Someone said they wished that Visual Studio (VS) and Visual Studio Code (VSCode) could use different color backgrounds for different projects in a solution.

I know how to build an extension that identifies files from different projects and how to change the background color of the editor, so I reached out to them to understand exactly what they were after.

Upon reflection, they decided that what would help them the most would be if VSCode could better indicate the git status of the file they were working on. They were writing docs and each stage of the documentation was a new file that built upon what was their already. For each new stage, they'd add a new file that was based on the previous step and make the changes there. The problem was that having lots of similar files meant that it was easy to accidentally change the wrong one.
What they wanted was a way to easily identify the new (untracked) files--as they are the ones they will be writing in, and any modified files--as that means they're changing something that already exists.

That's not what I was expecting, nor was it what I was thinking about, but I was intrigued.

I've made lots of extensions for VS but none for VSCode.
For a while, I've wanted to branch out and this seemed like a good opportunity.

I hoped that what I know about building extensions for VS will help with building them for VSCode.
It didn't.

The only thing I've learned building extensions for VS that applied to VSCode was to be persistent and search broadly to find out how to do certain things.

The extension I've made is very simple but in creating it I had to learn a number of things:
  • how to build a basic extension
  • how to respond to opening and switching between documents
  • how to apply visual changes to a document
  • how to get the git status of a file (much harder to work out than I expected)
  • how to share functionality between different extensions
  • how to work with configurable settings in an extension

In places, the VSCode documentation was better than for VS, but in others, it was also quite lacking.
I think the problem with creating documentation for extensibility features is that its necessary to assume a lot about the person doing the development and the documentation needs to be fairly abstract as every extension that is built will be different.
Anyway, if you're considering building an extension for VS or VSCode I highly recommend supplementing the official docs by searching for opensource code that does something similar and learn from that. It's one of the reasons that I share all my extension code on GitHub.

So, what did I build?
This:

VSCode screenshot showing different documents with different color backgrounds
Notice the subtle background tinting of the two open documents.

It colors the background of open documents if the are untracked or have been modified. The colors are customizable but the default matches the colors used in the Explorer and Source Control panels.

Hopefully, with this installed, fewer edits will now be made to the wrong documents. Or any edits in the wrong document will now be spotted sooner.


Tuesday, May 19, 2020

Highlights from BUILD 2020 (so far)

I'm missing being in Seattle for the BUILD conference this year. :(
It's normally one of my favorite events and a highlight of my year.

However, like most events this year, it's gone virtual. Anyone can watch online and there are likely to be many more things that are announced.
This is what's caught my attention initially.
  • Project Reunion - Unifying and evolving the Windows development platform.
  • WinUI 3 preview - The future approach to building native Windows apps.
  • WinGet - The new Windows Package Manager can change how we distribute and install apps.
  • MAUI - Xamarin.Forms is evolving and getting a new name.  github.com/dotnet/maui

more to come....

Wednesday, May 13, 2020

More fun with comments

This is probably the least interesting screenshot I've ever shared
and this one is only slightly more remarkable
Yes, it's the same method from the same file.
But, did you spot the difference?

It's only small.
Look at the left margin.
There are more of the little outlining boxes with minus signs in them in the second image.

The first image is the default behavior. It shows something I hadn't noticed before.
By default, in a method, only multi-line comments starting with a triple-slash can be collapsed.

And the second screenshot?
Well, it turns out that as I wrote a Visual Studio extension that works with comments, these are the kind of things I learn.
As such the second screenshot shows a minor feature of the latest version (1.8) of that extension. It now lets Visual Studio know how to collapse (and expand)  multi-line comments within method blocks. (That's not a piece of code I ever imagined writing!)

Additionally, it also:
- fixes a bug in how it identifies which block to expand and collapse.
- fixes a bug that affects anyone who uses tabs instead of spaces.

Now go: download, install and review the extension for yourself.

Sunday, May 10, 2020

Spaces beats tabs (by a factor of a thousand!)


Yes, there are reasonable arguments for each approach. I know that the accessibility argument for tabs is very strong. But I use spaces. It seems that so many people also do that I'm surprised that this is still an issue.

How many more? (Well, if the title wasn't a give-away) a thousand times more!!!

I have a Visual Studio extension for manipulating comments. It recently passed a thousand installs.
I also recently had a bug filed against it. The bug only affected code that used tabs instead of spaces.

Based on this single, unscientific data-point, it looks like there are at least one thousand people using spaces for each one using tabs.

Yes:
- this isn't scientific.
- this is me twisting the statistics to make a point.
- others may have encountered this but not reported a problem.
- installs and actuals use aren't the same things.

Why is this worth blogging about?
- This number is MUCH bigger than I was expecting.
- This debate is usually based on arbitrary preference and not on data. (I have data because I'm doing something that involves code manipulation and parsing.)


I'm not bothered about which you use (as long as it's not a mixture of the two--now that's barbaric!)

Tuesday, April 28, 2020

Collapse Comments (v1.4) and expand them

Comments (in code) can be really helpful. But, at other times they can get in the way of the code you're working on.

It's for the times when I just want the comments to get out the way that I created the Collapse Comments extension for Visual Studio 2019. It adds a simple command to collapse all the comments in the open document that you can invoke by pressing Ctrl+M, Ctrl+C.

I've just released version 1.4 and this includes something new. It includes the ability to do exactly the opposite of what I specified above. It adds another command that will expand all comments and collapse everything else.
It's not a scenario I have to deal with a lot but came as a suggestion (thanks Morten) who frequently looks at the decompiled code (and comments) that Visual Studio can generate. The generated file lists method names with comments (which are automatically collapsed upon opening) and it's the comments that are most important here for understanding all the different overloads. For this reason, it makes sense to be able to quickly expand all the comments by pressing Ctrl+M, Ctrl+D.


There's an option to control whether to treat using (or imports) directives like comments, and it works with C#, VB.NET, and XML documents.


Get it now, for FREE, from the Visual Studio Marketplace.

Got thoughts about this? Why not leave a comment below? I promise not to hide it away ;)

Monday, April 20, 2020

How to use VSIXSignTool

Trying to be a good developer/publisher, I sign my Visual Studio extensions.


Signing VSIXs is optional but it sends a good signal. Plus I have a code-signing certificate because I had to get one to sign NuGet packages as they MUST be signed.

But knowing how to sign a VSIX isn't obvious.
When I first wanted to sign an extension I was using Visual Studio 2017 and found the Extensibility Tools for Visual Studio from Mads Kristensen. This includes a UI for signing the generated package.

This was all good until I moved to exclusively use Visual Studio 2019. Those extensibility tools aren't supported in VS2019 so I was stuck.

To unblock myself, I ported the signing functionality, from the above-referenced tools, into a separate package that works with VS2019. A few hundred other people have also used this so I guess they were in a similar situation to me.

Fast forward to a week or so ago and I came across the NuGet package Microsoft.VSSDK.Vsixsigntool

This looked very interesting but lacked instructions on how to use it.
There's a link to some release notes but they're for "Visual Studio 2015 Update 2".
The "Project Site" link goes to the general landing page for Visual Studio Extensibility. :(

After more searching than I thought should be necessary, I eventually found https://docs.microsoft.com/en-us/visualstudio/extensibility/signing-vsix-packages?view=vs-2019
This page should be helpful but only includes some vague descriptions of what to do. :(

To try and work out how to automatically sign my generated packages using this tool, I did what I often do to solve problems relating to extension development, I searched GitHub to work out how other people had done it. Eventually, I came to this solution.

I added the following to my project file.

  <PropertyGroup>
    <VsixSignTool>$(NuGetPackageRoot)Microsoft.VSSDK.Vsixsigntool\16.2.29116.78\tools\vssdk\vsixsigntool.exe</VsixSignTool>
    <VsixSignCommand>$(VsixSignTool) sign /f $(SIGN_CERTIFICATE) /p $(SIGN_PASSWORD) /sha1 $(SIGN_CERT_HASH) /fd sha256</VsixSignCommand>
  </PropertyGroup>
  <Target Name="AfterBuild" DependsOnTargets="CoreCompile" Condition="Exists('$(SIGN_CERTIFICATE)')">
    <Message Text="Signing $(TargetVsixContainer)" Condition="'$(Configuration)' == 'Release'" />
    <Exec Command="$(VsixSignCommand) $(MSBuildProjectDirectory)\$(TargetVsixContainer)" Condition="'$(Configuration)' == 'Release'" />
  </Target>

This relies on two things:

  1. The NuGet package is referenced in the project.
  2. Add environment variables for the relevant parameters.


Points of note:
  • This allows for the certificate to be in different places on different machines.
  • This means there is no need to check the certificate into the code repository.
  • The password doesn't get checked in with the source.
  • If the environment variables aren't specified the process is skipped. This is how I avoid any issue with running this on a public CI server. It only needs to be defined on the machine that builds the release version for publishing.
  • The certificate hash was found with the following command.
>certutil -p ****** -dump ./filename.pfx

I also learned that it's possible to reference environment variables in MSBuild files. However, it's necessary to restart Visual Studio for it to pick up any changes (or additions) to these.

With this all set up, every time I build a release version of my extensions they are automatically signed without me having to do anything else. This simplifies the process and avoids me needing to enter the certificate file path and password. Yay!

There are probably other solutions with online key vaults and other such things but this works for me. Maybe this will help you too.

Saturday, April 18, 2020

ConstVisualizer v1.2 released and out of preview

My Const Visualizer extension is now at version 1.2 and out of preview.

Version 1.0 was only released this week but it has allowed me to identify some use cases that I hadn't previously accounted for. This is why I originally released it with a preview tag.

Having previously seen an increasingly broad range of code-bases, I had a very strong suspicion that there might have been things I originally missed. Thanks to people who tried out the first version and gave me feedback, the less obvious cases (to me) are now covered and it should work for all use cases where the definition of the constant is in the same solution.

For anyone who needs (or wants) to see constants defined in other code-bases (such as in referenced libraries) I'll wait for them to raise an issue to request this. ;)

Tuesday, April 14, 2020

Comment Links v1.2

I've just released an update to my Comment Links extension.

Version 1.2 adds the ability to create links through new context menu options on the editor.


No more manually composing links yourself. Now you can just put the cursor where you want the link to go to and create it that way.
The formatted link is copied to the clipboard for you to paste wherever you want it.
Copied links are also listed in the Output Pane so you can also access them from there (and even navigate from there too.)

Thanks to Michael for the suggestion.

View constants where you use them in your C# code

When debugging or just trying to understand code, it can be useful to see the value of constants. Yes, you can try and remember the values but seeing them is often easier.

The above is enabled by a new extension, I've just published, called Const Visualizer.

Yes, there's a lot of similarity between this and String Resource Visualizer.


Const Visualizer is something I've been meaning to create for a while but I've done it now as a pre-cursor to adding new functionality in the String Resource Visualizer. It's forced me to learn how to integrate Roslyn code analysis into an extension and look at other ways of analyzing the contents of a solution.

Why not put all the functionality related to const values and string resources in one extension?
Two reasons. 1. Because I prefer lots of simple tools that each focus on a single task. These can then be combined and used as preferred.  and 2. Because the existing "String Resource Visualizer" name doesn't expand well to cover other functionality too.

Please install it, give it a try, and see what you think. Does it make your coding-life easier too?

Saturday, April 11, 2020

Have you heard about text fragment anchors?

There are always lots of exciting and interesting things happening in the world of web development. One I just heard about is an experimental feature in Chrome that allows you to create links to any point on a page.

If you want the technical details, see this project from the Web Incubator Community Group.

It will work like this.

You include the text you wish to link to at the end of the URL with the special new `#:~:text=` anchor indicator.


Then the first occurrence of that text is highlighted on the page.


This is still an experimental feature and only works in some browsers. You must enable it like this:
In Chrome:

Or in the new Chromium-based version of Microsoft Edge.

Once you've enabled it and restarted your browser: give it a try


FYI. This was brought to my attention because of a project I'm doing relating to inter-document linking.

Friday, April 10, 2020

Comment Links - v1.1

Version 1 only shipped yesterday but there's a new version already.

Version 1.1 includes three changes:


  • The ability to support file and path names containing spaces. (including if they're URL encoded)
  • Support for search terms that include spaces
  • Indicating when a file can't be found (in the status bar). This also includes line numbers that don't exist or search text that can't be found.


These changes are the result of issues submitted on GitHub. Please raise any other feature requests there ;)


  • There was also a bugfix relating to navigating to the line containing the search text.


Download and enjoy.

Stay safe.


Thursday, April 09, 2020

Navigate between files of different languages in Visual Studio

Visual Studio has great tooling for navigating within code when it is in the same (programming) language.
However, if your solution contains code in more than one language and you want a quick way to navigate between files you're out of luck. Until now!

Presenting: Comment Links
Yes, it's (another) new Visual Studio 2019 extension. This one lets you put links between files anywhere in your code. In theory, this could be anywhere in your code, but in comments makes the most sense. Just include the text `link:` (case-insensitive) followed by the file name.


A green button with an arrow on it will, when clicked, open the named file.

You can also have the file open on a specific line by including the line number after `#L` at the end of the file name.

// link:mapManager.js#L25

 Or you can jump to the first occurrence of a specific piece of text

// link:mapManager.js:UpdateLocalData

For compatibility with text fragment anchors you can also use `#:~:text=` after the file name to specify the text.

// link:mapManager.js#:~:text=UpdateLocalData


Version 1.0 is in preview and available from the Visual Studio Marketplace now.
Please give it a try and tell me what you think or suggest new features on GitHub.


This project was the result of a comment from one of my GitHub sponsors. If you join them I'm likely to take any suggestions you make more seriously. ;)

Thursday, April 02, 2020

Automatically collapse code comments when opening a document

I've just released a new version (1.2) of my Collapse Comments extension for Visual Studio.

Amongst the changes are two new configurable options.


Whether using (or imports in VB) directives are collapsed as well as comments is now configurable. This is the old behavior and so is enabled by default.

The other new option is the ability to automatically close comments whenever a new document is opened. This is off by default as it's a change in behavior.

Please let me know what you think of these changes, or, even better, leave a review :)


Monday, March 23, 2020

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.





Thursday, March 19, 2020

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. ;)



Monday, March 16, 2020

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

Options dialog showing the default settings.


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

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:

Wednesday, February 12, 2020

Resource Pseudo Localization - Protecting developers from themselves

I have a tool to help test the localization of strings in an app. It does this by making changes to the resource files (.resx & .resw) to help make it easy to test that all content is coming from the resource file. There are a number of different options available and more on this is covered in my book.


I've just released a new version (3.0) that adds a single new feature.

The new feature is that it creates a backup of the original file before it changes the content.

I know that it can be frustrating when tools create unnecessary extra files but I feel this is better than someone getting into a situation where they lose lots of work.

There's an option to turn this off if it's not wanted but it's on by default as that's better for avoiding unexpected negative consequences.

This isn't the result of someone having a problem. Rather, it's me trying to avoid a problem before it occurs.
Someone did ask how to get back after they'd toggled one of the options (you just need to toggle it again to undo the change) but I realized that not everything is obvious to everyone and there are all sorts of developers with various skills, knowledge, and experience.
In case anyone ever converts all their resources to something that can be automatically reversed, and they don't have another copy, and they don't have source control. At least they'll now have a backup.

If you're interested in trying out this extension, you can get it from the VS Marketplace.

Monday, February 10, 2020

Modern XAML Development - slides and overview

Slides! - because that's all some people think a talk is.



Let me add some background.

Above are a modified version of the slides used in this talk. The modifications remove things that aren't relevant, were there just as a backup for the more risky demos, and strip out the animations.

This is not the whole talk!
There is no way you could take this deck and give the same talk.
For starters, there are 10 (yes ten) demos that aren't included here.

I do not have slide notes.
Sorry, no. For what the slide doesn't make clear you're out of luck.

It's a talk, and the slides are there to support what I say. I'm not there to talk about the text on the screen. I know some people do it that way but I don't.

The basic structure of the talk is as follows:
  • Why XAML was created?
  • How it's developed and evolved.
  • XAML has multiple versions, allows you to build for multiple platforms, and has multiple ways of doing things.
  • Given all those variations, tooling hasn't always been great, but that is starting to change.
  • There is a lot to be gained when thinking about XAML as code and what you expect from the tooling for other languages.
  • Given that comparison:
    - What about creating apps that use XAML?
    - What can be done in the editor?
    - What can be done in the designer?
    - What can be done at run-time?
  • What's coming in the future?
  • Conclusion and questions
I don't have a script for the whole talk. That's why I can't share one here.
Instead, I plan by focusing on the overall structure. I then look at how different elements can fit into that structure.

The structure comes down to two parts.

  1. Provide background
  2. Walkthrough building an app and show how the tooling can help at different stages.

Within the walkthrough, I combine a number of small demos to show different features and that things work with different platforms. This means jumping between WPF, UWP, and Xamarin.Forms projects but this shows that the tools apply regardless of the platform without repeating everything three times or just claiming what's possible.
Having multiple small demos also allows me to focus on one thing in each demo. Trying to put everything in a single demo was more complicated than I could manage and involved too many things being on screen at once which was potentially distracting and confusing.
Having multiple small demos made them easy to practice. I practiced the demos many many times in preparation for giving the talk. Having small, simple demos allows me to experiment within the rehearsal to become familiar with variations. It allowed me to explore things like "what if I did this differently?", "How could this go wrong?", or "How could I make this simpler?".
Because each demo doesn't depend (much) on what's gone before it I can make changes in one demo without having to worry about possible negative consequences in subsequent demos.
Finding times to practice small demos is easier for me to do than finding the time to practice a long, complicated demo.
Not being tied to a specific, strict format allows me the flexibility to adjust the talk when given based on anything that may happen on the day, has been said in other talks earlier in the conference, or where my mind goes at the time.

Preparing this way takes ages. It's not something that can be done without a lot of time to prepare and so it's not a technique that can always be used. I do it where/when I can.


I made sure to know the content inside out and roughly how long each section takes and then adjusted what I said accordingly on the day.

I deliberately include some questions on slides at the end. This is for a number of reasons.
  • It shows I'm open to answering difficult questions.
  • It provides an easy way to answer common questions that I didn't cover earlier.
  • It provides an opportunity to cover questions that don't naturally fit into the rest of the talk.

When I gave this talk in Stokholm I finished, including the Q&A section with 3 seconds remaining.
Additional questions were taken 1-to-1 immediately after the talk.

Hopefully, this is useful if you're interested.

Also, links to tools mentioned in the talk can be found at https://www.mrlacey.com/2020/02/modern-xaml-development-notes-from.html



Tuesday, February 04, 2020

Modern XAML Development - notes from SWETUGG

Today (at the time of posting) I'm talking in Stokholm about Modern XAML Development.


Here for your simple consumption are links to all the things I talked about, demonstrated or otherwise mentioned.



Sorry, it's not the actual slides. There are only so many cat pictures I want to contribute to the web. ;)

Update.
Slides and notes can be found at https://www.mrlacey.com/2020/02/modern-xaml-development-slides-and.html