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.

• 3- A new promotional website: https://rapidxaml.dev 

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 WPF, UWP, 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?

• Install the extension - give it a try.

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

• Visit the website

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

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

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

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.

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.

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.