Mads Kristensen

Solution Colors: Telling Visual Studio Windows Apart at a Glance

test@example.com — Thu, 10 Sep 2026 18:08:54 GMT

When several Visual Studio instances are open, identifying the right one becomes a surprisingly repetitive task. Two windows showing different checkouts of the same solution can look almost identical. Reading the title works, but a small visual cue is easier to spot.

That's the problem behind Solution Colors. Inspired by the Peacock extension for VS Code and a Visual Studio feature request, it associates a color with a solution or folder without replacing your editor theme.

Give each solution a visual identity

Right-click the solution in Solution Explorer, choose Set Solution Color, and select a color. The predefined choices use the familiar document-tab color palette, and Custom... opens a color picker when you want something different. Open Folder workspaces are supported too.

The color can appear around the window, behind the solution name in the title bar, and in taskbar thumbnails. Taskbar icon overlays are also available, with the documented limitation that taskbar items need to be ungrouped. You can choose the surfaces that help you and leave the others alone.

Under Tools > Options > Environment > Fonts and Colors > Solution Colors, you can adjust border placement and thickness or enable automatic color assignment. Automatic mode selects from the palette using a hash of the solution path; explicitly saved colors take precedence.

A small extension with two kinds of integration

The project is an in-process VSIX built with the Visual Studio SDK and the Community Toolkit. Its ToolkitPackage registers commands and listens for solution and folder open/close events. The menu lives in a VSCT command table, while the color commands share a generic BaseCommand<T> implementation.

That is the conventional part. Coloring the existing window chrome is less conventional.

The implementation searches the WPF visual tree for named shell elements such as BottomDockBorder and PART_SolutionNameTextBlock. It changes brushes and border thickness rather than introducing a new tool window. For the title label, it also uses reflection to access the foreground property and Visual Studio's ColorUtilities.CompareContrastWithBlackAndWhite to choose black or white text.

This is an important tradeoff for extension authors: finding an element in the shell's visual tree is not the same as having a dedicated, stable extensibility contract for it. Names and structure can change. The lookup code is worth isolating, and these integrations need testing against the Visual Studio versions you support.

Decoration must not get in the way

One revealing detail is hit testing. The extension disables hit testing on the non-top borders it colors so they don't intercept mouse input. But it deliberately leaves the top element alone: MainWindowTitleBar contains interactive UI, and disabling hit testing there would also block menu interaction.

That distinction is easy to overlook when the feature appears to be "just a border." Decorative changes still participate in layout and input routing.

Timing matters too. Package initialization does not guarantee that every shell element is ready. The startup path makes a bounded series of colorization attempts, with delays between them. UI changes switch to the main thread, while Git branch file reads are dispatched to a background task.

Taskbar integration uses a different mechanism: WPF's TaskbarItemInfo, noninteractive ThumbButtonInfo entries, and an overlay image. There is no need to reach into the taskbar's visual tree.

Branch colors are a state problem, not just a brush problem

The settings offer one color across branches, a separate color per branch, or a combined gradient. Assignments are stored as simple branch:color lines in a color.txt file, normally under the solution's .vs directory. An option puts the file in the root instead. The parser also accepts the older single-color format.

There is a compatibility detail worth knowing: the implementation uses the literal key master for its shared/base color. That is an internal convention, not automatic discovery of a repository's configured default branch.

A recent fix illustrates why separating decisions from rendering helps. In per-branch mode, a branch with an explicit color should remain colored even when no base color has been assigned. The code now expresses the removal decision in ShouldRemoveColorization, with focused unit tests covering the different modes and automatic-color behavior.

That is a useful pattern beyond this extension: put the state rules in a testable method, then let the UI code apply the result. You shouldn't need to launch an experimental Visual Studio instance just to verify whether a missing base setting overrides a branch-specific one.

Try it, or borrow the ideas

If you regularly juggle Visual Studio windows, install Solution Colors from the Marketplace and give your solutions a visual identity.

If you're building extensions, browse the source on GitHub. Start with SolutionColorsPackage for the lifecycle, ColorHelper for the shell integration, and the tests for the branch-color rules. A few pixels of color turn out to be a useful case study in extending the IDE without getting in the user's way.

Lore for Visual Studio: Source control without leaving the IDE

test@example.com — Fri, 28 Aug 2026 20:54:50 GMT

Lore is a new source control system from Epic Games. It is designed for fast, distributed workflows, with local repositories that work offline and optional Lore servers when you need to collaborate.

Lore for Visual Studio brings that workflow directly into the IDE. It is also a practical example of what it takes to add a new source-control provider to Visual Studio: integrate onboarding, status, changes, commits, history, branches, authentication, and native diff and merge experiences into the places developers already use.

The extension lets you onboard a solution or folder, see file status in Solution Explorer, review changes, commit, manage branches, inspect history, and synchronize with a Lore server - all without dropping to a terminal.

A source-control provider that feels native

Visual Studio already provides the integration points a source-control provider needs to participate in the everyday development workflow. Lore for Visual Studio uses them to surface repository status in Solution Explorer, provide commands in solution and file context menus, and offer dedicated Changes and History tool windows. Rather than making developers learn a separate workflow, the extension makes Lore available alongside the IDE experiences they already know.

Start with a local repository

Open a solution or folder and select Add to Source Control in the Visual Studio status bar. Choose Lore, then create a local repository.

Local repositories are fully offline. You can commit, create branches, switch branches, and browse history while all content remains on your machine. When you are ready to collaborate, create or connect to a Lore server and push your work.

You can also clone an existing Lore repository directly from Solution Explorer. The extension checks that the server is reachable, clones the working tree, and records the remote configuration so push and pull are ready immediately.

Source-control status where you expect it

Once a solution is under Lore source control, status glyphs appear beside files in Solution Explorer. They refresh automatically as documents are saved, and the Lore Changes window provides a manual refresh command whenever you need one.

File context menus include the essentials:

Undo Changes to restore the committed version
Compare with Unmodified to view a native Visual Studio diff
Ignore and Untrack Item to add a file to .loreignore

Moves and renames performed in Solution Explorer are tracked automatically. The extension also uses Visual Studio's shared file-change service to detect changes made outside the IDE.

Review and commit changes

The Lore Changes window provides a dedicated commit experience modeled after Visual Studio's Git Changes window.

It presents changed files in a repository-root folder tree, including status badges for modified, added, deleted, renamed, and copied files.

You can select exactly which files belong in the next commit. Folder checkboxes are tri-state, the header checkbox selects everything at once, and your selection survives automatic refreshes while you write a commit message.

From the window, you can:

Commit selected files or commit and push in one operation
Amend the latest revision
Open native Visual Studio diffs for individual files
Discard a file's changes
Pull, push, and refresh from the toolbar

Browse history without touching the working tree

The Lore History tool window shows a read-only log for the repository associated with the open solution or folder.

History is paged, newest first, so even repositories with thousands of revisions remain responsive. Each revision shows its message, short hash, author, and local commit time. Select a revision to load only the files that it changed, then double-click a file to compare it with its direct parent in Visual Studio's native diff viewer.

The window stays in sync with the workspace and refreshes automatically after relevant Lore operations, such as commits, pulls, branch changes, and merges.

Branching and merging

The branch picker in the Lore Changes window lets you switch branches, create a branch from the current revision, and merge another branch into the one you are working on.

Lore is offline-first. When the needed content is already cached locally, switching and merging do not require a network round trip. If content has been evicted from the local cache, Lore fetches it from the configured server and clearly reports when the server is unavailable.

When a merge conflicts, Visual Studio's built-in three-way merge experience opens for each conflicted file. Resolve the conflicts, accept the results, and Lore completes the merge commit.

Sign in only when it matters

There is no separate sign-in command. If a server-backed operation such as cloning, pushing, or pulling requires authentication, Lore asks whether to sign in and opens the default browser. After sign-in completes, the original operation is retried.

That keeps the experience simple: work locally when you can, authenticate only when a server operation actually needs it.

Try it out

Lore for Visual Studio is available from the Visual Studio Marketplace.

The extension is open source, and contributions are welcome on GitHub. If you are building a source-control integration of your own, the project is also an example of how a provider can fit into Visual Studio's existing source-control workflow.

Building Max Line Length: Making EditorConfig Formatting Visible in Visual Studio

test@example.com — Wed, 19 Aug 2026 16:05:17 GMT

Line length is one of those conventions that teams agree on easily and enforce inconsistently. EditorConfig gives us a shared vocabulary with max_line_length, but Visual Studio does not natively draw a boundary for it or apply it during formatting.

That gap is what inspired Max Line Length. The extension makes the effective EditorConfig value visible in the editor and adds a carefully constrained reflow pipeline for formatting and Code Cleanup.

Starting with the effective EditorConfig value

The extension does not introduce a second configuration system. A repository can declare its convention as usual:

[*.{cs,vb}]
max_line_length = 120

For each text view, Max Line Length resolves the effective value for the document, including nested configuration files and matching sections. If the value is missing, invalid, or set to unset, the ruler is removed.

The interesting part is keeping the editor responsive when configuration changes. The adornment listens for refresh notifications, resolves file-based settings away from the UI thread, then switches back to the main thread before updating the view. A version counter prevents stale asynchronous results from replacing newer configuration values.

Drawing a ruler without interfering with editing

The ruler is implemented as a Visual Studio editor adornment. The extension obtains an IWpfTextView, creates an IAdornmentLayer, and owns a WPF Line element. Its horizontal position is calculated from the formatted line source, indentation, column width, and the resolved maximum length.

The adornment follows layout changes, so it tracks scrolling, zoom, font changes, and viewport updates. It is not hit-testable and does not intercept mouse or keyboard input. The extension also checks for Visual Studio's diff view role and does not display the ruler there.

Color customization uses Visual Studio's format map rather than a private option. The Max Line Length ruler format is exposed through Fonts and Colors, and the adornment reads the configured foreground brush when it redraws.

One reflow service for several editor commands

Formatting support began as command-specific logic, but that quickly creates inconsistencies. The extension now centralizes the decision in DocumentReflowService. It determines whether a content type can be reflowed, selects the appropriate engine, and applies the resulting text changes.

Visual Studio's MEF composition supplies the classifier service used for comment-aware languages. For C# and Visual Basic, the extension uses language-specific reflow engines for lists and expressions. For classified-comment content types such as JavaScript, TypeScript, C++, CSS, LESS, SCSS, and SQL, it asks the editor classifier for comment spans and limits changes to those spans.

Markdown and plain text use separate engines so that structural constructs remain intact. Markdown headings, tables, lists, block quotes, code fences, inline code, HTML, front matter, and hard line breaks are protected instead of being treated as ordinary prose.

Being conservative is a feature

Reflow changes source text, so the extension intentionally avoids transformations that could alter meaning. C# and Visual Basic string and character literals are left alone. Structured XML documentation elements, examples, lists, and preformatted content are preserved while ordinary documentation prose can be wrapped.

Formatter suppression markers provide an explicit escape hatch. The extension recognizes @formatter:off and @formatter:on in the relevant comment syntax and excludes the protected region from reflow.

Selection formatting is similarly constrained. It operates on complete selected lines or complete C# and Visual Basic syntax constructs rather than making partial edits that could produce surprising results.

Adding Code Cleanup without changing existing profiles

The Code Cleanup integration is opt-in. The fixer is exported through Visual Studio's ICodeCleanUpFixerProvider and exposes a localized fix ID named Reflow lines to configured maximum length.

When enabled in a cleanup profile, the fixer obtains the document path, resolves the same ReflowOptions used by the formatting commands, and sends the buffer through DocumentReflowService. This keeps document cleanup and manual formatting consistent.

The fixer is disabled unless the user explicitly adds it to a profile. That default matters: installing an extension should not silently change existing cleanup behavior. The integration supports document cleanup and cleanup on save, while project and solution cleanup are not intercepted.

Lessons for other Visual Studio extensions

Use the editor's effective configuration instead of creating a parallel options system.
Keep UI adornments lightweight and recalculate them from the current formatted line source.
Centralize behavior shared by commands, cleanup, and future entry points.
Use classifications and syntax-aware boundaries to avoid editing executable code accidentally.
Make automated cleanup opt-in when it can change source text.
Design asynchronous refresh paths so stale results cannot overwrite newer state.

Try it or inspect the implementation

Install Max Line Length from the Visual Studio Marketplace, or download the latest CI build from the Open VSIX Gallery.

The complete source is available on GitHub. The project is a useful example of combining editor adornments, EditorConfig resolution, MEF services, content classifiers, language-aware text transformations, and Code Cleanup integration in a focused Visual Studio extension.

Building Bookmark Studio: bookmarks that belong to the codebase

test@example.com — Tue, 11 Aug 2026 01:54:47 GMT

Visual Studio bookmarks are useful for marking a line and returning to it later. The problem is that a line number alone does not say why the location matters, how it relates to other locations, or whether the rest of the team should know about it.

Bookmark Studio treats a bookmark as a small piece of project knowledge. A bookmark can have a name, note, color, folder, and one of nine direct-navigation shortcuts. It can stay private in the .vs folder, live at the workspace level in source control, or be global across solutions.

That sounds like a straightforward feature, but it touches several distinct parts of Visual Studio extensibility: editor tags and glyphs, text-buffer tracking, commands, a searchable tool window, options, solution lifecycle events, and persistent storage. The interesting part is making those pieces behave like one feature rather than a collection of extension points.

Keep the editor layer fast

The visible bookmark in the editor margin starts with a MEF-exported IViewTaggerProvider. It creates an ITagger<BookmarkGlyphTag> for primary text document views, while an IGlyphFactory turns each tag into the colored square shown in the glyph margin. If a bookmark has a shortcut from 1 through 9, the number is drawn inside the glyph.

The tag also carries the bookmark label, note, color, and shortcut number. That gives the glyph factory enough information to build a useful tooltip and context menu without reading the bookmark file. A second tagger produces OverviewMarkTag instances so the same bookmarks appear as colored markers in the editor scrollbar.

A useful rule for editor extensions is to keep GetTags cheap. Visual Studio can ask for tags often, including while scrolling and editing. Bookmark Studio does not load JSON or filter the complete bookmark collection on every request. The shared session owns the current bookmark state, and each tagger caches only the bookmarks for its document. When the session reports a change, the tagger replaces that small cache and raises TagsChanged.

That separation is broadly useful: do I/O and normalization in a service, then give the editor a read-optimized snapshot.

A persisted line number is not an editor position

A bookmark must be serializable, so its stored location includes a document path and line number. An open text buffer is more dynamic. Insert three lines above a bookmark and the persisted number is immediately stale.

Bookmark Studio handles that mismatch with ITrackingPoint. While a document is open, each bookmark gets a tracking point anchored inside the line content. The editor moves that point as the buffer changes, which keeps the glyph attached to the intended code instead of the original numeric line. The tagger can still fall back to the stored line number when no tracking point exists.

There is an additional wrinkle: users can explicitly drag a glyph to another line. The tagger therefore distinguishes an editor-tracked move from an explicit bookmark move before deciding whether to preserve or rebuild the tracking point. The custom MouseProcessorBase implementation calculates the target editor line, displays a drop indicator, updates the bookmark, and refreshes the manager if it is open.

The lesson is that storage coordinates and live editor coordinates are different concepts. Persist a stable representation, but use the text model's tracking primitives while a buffer is active.

Reuse Visual Studio instead of recreating it

The Bookmark Manager is a WPF control hosted in a BaseToolWindow. Its surrounding experience comes from Visual Studio rather than custom imitations.

The package registers the window with ProvideToolWindow, docks it alongside Solution Explorer, and assigns a toolbar declared through VSCT to ToolWindowPane.ToolBar. Search uses the tool window's native search box by enabling SearchEnabled and implementing IVsSearchTask. Commands and keyboard bindings are also declared through VSCT, including direct navigation with Alt+Shift+1 through Alt+Shift+9.

This approach matters for more than appearance. Native command placement participates in Visual Studio's command routing, toolbar customization, keyboard system, and accessibility behavior. The same principle applies to the search box: using the host's search contract gives the tool window familiar behavior without building another search control.

Bookmark Studio also offers an opt-in bridge from Visual Studio's built-in bookmark gestures. VS.Commands.InterceptAsync handles commands such as toggle, next, previous, and clear-in-document. The first toggle can prompt the user, and the setting determines whether later commands stop in Bookmark Studio or continue to Visual Studio's native implementation. The extension adds its own direct gestures as well, so interception is a choice rather than a requirement.

Make sharing explicit in the storage model

Bookmarks are stored with System.Text.Json in .bookmarks.json. The file is a folder tree containing bookmark IDs, relative document paths, line numbers, labels, notes, colors, shortcut slots, and manual sort indexes.

There are three storage scopes:

Personal bookmarks live under the solution's .vs folder.
Workspace bookmarks live beside the solution or at the Git repository root and can be committed.
Global bookmarks live in %USERPROFILE%\.bookmarks.json and use absolute paths because they are machine-specific.

Workspace discovery walks upward from the solution directory and reuses the first bookmarks file it finds. This is important for repositories where the solution sits below the root. New workspace files record "documentPathRoot": "bookmarksFile", which tells the loader to resolve relative document paths from the bookmarks file itself. Existing files without that marker retain the older solution-relative behavior.

That small format marker avoids a common portability bug. A relative path is only meaningful when both writer and reader agree on its base directory. If a team-shared file may move higher in a repository, the base must travel with the format or be defined by it.

Naming can use the editor's understanding of code

When name prompting is enabled, Bookmark Studio does not have to settle for the current line as the label. A MEF service queries Visual Studio's classification system and ranks identifiers such as methods, properties, fields, and types. It supports view classifiers first, then projection buffers and tag aggregators as fallbacks.

The complete fallback order is pragmatic: selected text, classified identifier, word under the caret, file name, trimmed line text, and finally Bookmark. Duplicate labels receive a numeric suffix.

This is a good middle ground for editor tooling. The extension gets language-aware suggestions from classifications that Visual Studio already produces, without taking a dependency on a specific language compiler or syntax tree.

The extension points form one state machine

The package loads in the background for solutions, Open Folder workspaces, and the no-solution context because global bookmarks remain useful without a solution. Solution and folder events invalidate the cached path and refresh the shared session. Editor taggers, commands, and the tool window all observe or update that same session.

That shared state is the architectural center of Bookmark Studio. The editor should not own persistence, the tool window should not be the only source of truth, and commands should not need to know where JSON lives. Each surface delegates bookmark operations to services, then reacts to the resulting state change.

For extension authors, the reusable ideas are straightforward:

Keep taggers read-only and inexpensive.
Use tracking points for live buffers instead of treating line numbers as stable positions.
Prefer native tool window search, VSCT commands, and host chrome over look-alike WPF controls.
Define the base of relative paths as part of a shareable file format.
Put cross-surface state behind a service so commands, editors, and tool windows stay synchronized.

Bookmark Studio is available on the Visual Studio Marketplace. The complete source, including the editor providers, tool window, command table, storage format, and tests, is on GitHub.

Building CodeShot: turning Visual Studio editor state into a shareable PNG

test@example.com — Fri, 07 Aug 2026 19:07:37 GMT

Turning a code sample into an image sounds simple until the image needs to look like the code inside Visual Studio.

Copying text into a design tool loses editor colors and formatting. Taking a normal screen capture includes tabs, margins, toolbars, and whatever else happens to be visible. It also leaves no convenient way to emphasize an expression or cover a value before sharing the image.

CodeShot addresses that workflow inside Visual Studio. It takes inspiration from CodeSnap, but its implementation is shaped by the Visual Studio editor and shell.

Select code, open CodeShot, adjust the result, and copy or save the PNG without leaving Visual Studio.

Rebuilding the editor instead of photographing it

The basic workflow starts with an editor selection. CodeShot opens a tool window, creates a preview using the current syntax colors, and immediately copies the initial image. The preview can add line numbers, a title bar, backgrounds, padding, shadows, and a configurable export scale.

The important implementation detail is that the editor screenshot is not a bitmap of the editor. CodeShot reconstructs the selected text as WPF content.

It obtains the active IVsTextView through IVsTextManager, converts it to an IWpfTextView with IVsEditorAdaptersFactoryService, and reads the selected SnapshotSpan values. Common indentation can then be removed without changing the underlying document.

Syntax colors come from two MEF services:

IViewClassifierAggregatorService supplies the classification spans.
IClassificationFormatMapService maps each classification type to the colors currently used by the editor.

Rather than asking the classifier about every line, CodeShot classifies the enclosing selection once. It then walks the ordered spans and slices them into WPF Run elements for each selected line. Unclassified gaps use the editor's default foreground, while classifications can contribute their own foreground and background brushes.

This approach has two useful properties. The result follows the active Visual Studio color settings, and the capture surface can be laid out independently of the editor viewport. Long selections are not clipped just because the tool window is small.

The preview is reconstructed from editor text and classifications rather than cropped from the screen.

Rendering at an explicit scale

The completed WPF surface is rendered through a VisualBrush into a RenderTargetBitmap. Export scale is explicit instead of being derived from monitor DPI. That makes the same selection produce the same pixel dimensions on different displays.

There are practical limits around this step. CodeShot rejects dimensions above 16,384 pixels and caps the total pixel count before allocating the render target. The resulting BitmapSource is frozen before it crosses thread boundaries.

The clipboard also needs more care than a call to Clipboard.SetImage. Some paste targets discard alpha from the normal WPF bitmap format, so CodeShot places both the compatibility bitmap and an encoded PNG on the clipboard. The clipboard data is copied rather than referenced, allowing the image to remain available after Visual Studio closes.

There is an optional plain-text clipboard representation too. That keeps code searchable when an application prefers text over images. If the screenshot contains a redaction, CodeShot deliberately omits the original text so the clipboard cannot reveal what the PNG hides.

Annotations are part of the capture surface

Annotations are ordinary WPF elements layered over the preview. Rectangles, arrows, expression highlights, text notes, and opaque redactions share a controller responsible for drawing, selection, moving, resizing, and erasing.

Crop operations and annotations use the same bounded edit-history model. This keeps undo and redo predictable while preventing an editing session from retaining an unlimited number of image and geometry states.

Annotations are rendered into the exported image, with redactions also changing clipboard behavior.

Capturing a tool window is a different problem

Text reconstruction works well for editor selections, but it cannot capture Error List, Test Explorer, Solution Explorer, or a tool window containing Win32 or WebView content. Those surfaces have to be captured from the pixels currently displayed.

CodeShot adds a command to Visual Studio's docked-window context menu through VSCT. When invoked, it uses IVsMonitorSelection to find the current IVsWindowFrame and IVsWindowFrame4.GetWindowScreenRect to obtain its screen coordinates.

The command is attached to Visual Studio's native docked-window context menu.

Finding the content rectangle is only the beginning. A docked group may contain sibling tabs, rounded shell chrome, transparent corners, and content rendered outside the WPF visual tree.

CodeShot combines several mechanisms:

UI Automation locates the selected tab and its docking container.
The WPF visual tree supplies a mask for the rounded Visual Studio frame.
Graphics.CopyFromScreen captures the actual visible pixels, including Win32 and WebView content.
The mask removes sibling tabs and leaves pixels outside the rounded frame transparent.

Because UI Automation runs away from the UI thread, the target can change while its geometry is being inspected. Before copying pixels, CodeShot verifies that the selected COM frame, bounds, root window, and visibility still match the original target. Captures are serialized with a SemaphoreSlim so two commands cannot race over transient shell state.

This design has an honest constraint: pixel capture can only reproduce what is visible. The target must remain unobscured. That tradeoff is preferable to pretending every Visual Studio surface can be rendered reliably through WPF.

Menus and modal dialogs complicate threading

Menus, context menus, cascading flyouts, and modal dialogs are even more temporary. CodeShot starts a five-second countdown so the user can open the desired surface, then performs discovery and capture off the Visual Studio UI thread.

That last part matters for modal dialogs. A modal WPF or Windows Forms dialog owns the UI thread while it is open. Resuming the delayed operation on that thread would postpone capture until the dialog had already closed.

The capture code examines the foreground window and the window under the pointer. UI Automation identifies visible menu items and expanded flyouts, while Win32 window enumeration finds native #32768 menu windows. DWM extended frame bounds are preferred when available so shadows and invisible borders do not become part of the result.

Let Visual Studio own the command experience

The tool window itself uses BaseToolWindow from the Community Visual Studio Toolkit, but its toolbar, menus, context-menu command, icons, and keyboard bindings are declared through VSCT.

The tool window's persistence GUID also acts as a command scope. Combined with ProvideKeyBindingTable, this allows familiar shortcuts such as Ctrl+C, Ctrl+S, Ctrl+Z, and Ctrl+Y to operate inside CodeShot without replacing their global Visual Studio behavior.

That is a broadly useful extension pattern: when a feature belongs to Visual Studio chrome, use Visual Studio commands and command scopes instead of recreating the experience with WPF buttons and global key handlers.

Small boundaries make the extension easier to maintain

The first version concentrated substantial behavior in the tool-window control. As the capture modes grew, reusable pieces were extracted for selection normalization, PNG encoding, file naming, atomic saving, font discovery, capture sizing, and bounded history.

Those boundaries also made the non-Visual Studio portions testable with ordinary MSTest tests. Visual Studio integration remains in the package and capture layers, while geometry, naming, indentation, and state transitions can be exercised without launching an experimental instance.

The main lesson from CodeShot is that image encoding is the easy part. A Visual Studio extension like this lives at the boundaries between editor snapshots, MEF services, WPF layout, COM frames, UI Automation, Win32 windows, the clipboard, and the shell's threading rules. Treating each boundary explicitly makes the workflow feel simple even when the implementation is not.

You can install CodeShot from the Visual Studio Marketplace or inspect the complete implementation in the GitHub repository.

Schemastore.org: The journey of a quiet revolution

test@example.com — Mon, 09 Dec 2024 21:41:37 GMT

Let me take you back to a moment that might feel familiar: you’re staring at a JSON configuration file, wrestling with field names and structure, hoping you’ve gotten it right. Your IDE is offering no help, and documentation is scattered or nonexistent. Frustrating, right?

Years ago, I found myself in that exact spot one too many times. As I sat there, tweaking and testing, it hit me: there had to be a better way. Little did I know that moment of frustration would spark an idea that would evolve into what you know today as Schemastore.org.

The Problem

Back then, JSON schemas weren’t the ubiquitous helpers they are now. Sure, the technology existed, but it wasn’t easy to find schemas for the tools you were using. If you needed a schema for your project, you either had to dig through obscure documentation or—more often—roll up your sleeves and build it yourself.

It was a time sink. And worse, it was entirely avoidable.

The real problem wasn’t the complexity of schemas; it was the lack of a centralized place to find them. Developers were solving the same problems over and over, each in isolation, when a shared resource could have made all the difference.

The Turning Point

So, I decided to create that shared resource. The idea was simple: a public repository where anyone could find and contribute JSON schemas. It wouldn’t be fancy—just a straightforward way to save developers from hours of unnecessary frustration.

When I launched Schemastore.org, I didn’t have big expectations. I thought it might help a few people, but I never imagined how quickly it would resonate with the development community.

The Rise of a Community

What happened next was extraordinary. Developers from all over the world began contributing. They sent pull requests for schemas I’d never heard of fixed errors I hadn’t spotted, and offered suggestions that made the site better in ways I couldn’t have predicted.

It wasn’t just about the schemas anymore; it was about the community.

Over the years, Schemastore.org has grown into a critical resource, quietly powering tools like Visual Studio Code, GitHub Actions, IntelliJ IDEA, and many others. The stats are humbling: over 1500 contributors, 4000 pull requests, 1000 schema files, and millions of developers who’ve benefited from the work.

That results in 2 TB of schema files being served to IDEs, validators, and other system every single day to support JSON, YAML, and TOML files.

But the real story isn’t in the numbers. It’s in the ethos: a shared belief that open collaboration can solve even the most frustrating problems.

The Challenges Today

Of course, growth comes with challenges. Keeping Schemastore.org running smoothly requires time, effort, and resources. While it’s still volunteer-driven, the infrastructure and maintenance costs have grown alongside its popularity.

And here’s the thing: for-profit organizations are among the biggest beneficiaries of Schemastore.org. They use the schemas to validate configurations, streamline workflows, and, ultimately, save time and money.

The Ask

If you’re part of such an organization—whether you’re contributing schemas or relying on them—I have a request: consider sponsoring Schemastore.org.

Your support would help cover hosting, maintenance, and development costs, ensuring this resource remains free and open for the entire community. It’s a small way to give back to something that likely saves you (and your team) time and effort every day.

You can find sponsorship details on the site, or feel free to reach out to me directly.

The Resolution

Looking back, it’s amazing to see how far Schemastore.org has come. What started as a small project has grown into something much bigger – a shared resource, built by and for the community, quietly making life easier for developers everywhere.

This journey isn’t over. With your help, we can keep Schemastore.org thriving, growing, and helping developers for years to come.

Thank you for being part of this story, whether as a user, a contributor, or someone who simply appreciates the effort.

Here’s to solving problems – one schema at a time.

Receive a notification when the dishwasher finishes

test@example.com — Wed, 18 Mar 2020 20:25:05 GMT

At our house, we use home automation for a lot of different things. One of them is the ability to get a quick overview of the state of our appliances such as the washer, dryer and dishwasher. That way we don’t accidentally forget to turn over the laundry or empty the dishwasher.

A red tile on our dashboard means something is ready for us to take action on – in this case that would be emptying the dishwasher after it finishes. See earlier blog post on how I built the dashboard below.

There are lots of tutorials on how to hook a “dumb” washer and dryer up to any home automation system, but I haven’t found any for the dishwasher that doesn’t involve figuring out how to hook up a power meter to it.

So, after a bit of trial and error I was able to do a highly accurate reporting mechanism using only a $20 multipurpose sensor that I had lying around.

The sensor

You need one or more sensors capable of sensing tilt, acceleration and temperature. I used the $20 Samsung Multipurpose sensor which integrates seamlessly into my SmartThings home automation system.

Attach the sensor along the side of the dishwasher at a place where it doesn’t get in the way. My wife didn’t notice the sensor until I asked her to look several days later.

The key is that the sensor needs to be located such that it can measure the raise in temperature from inside the dishwasher as it runs through its heated drying cycle. For your dishwasher, it might be higher up or even underneath.

Then go into the configuration of the sensor and specify it to be used on a garage door.

All that does is to use the tilt sensor to determine if it’s open or closed instead of the magnet. That way, you must open the dishwasher door all the way down to horizontal level before it registers as open. That’s what we want.

The automation logic

I’ve created a virtual switch called Dishwasher that I use to store the state of the dishwasher cycles which is what I use for the dashboard. It’s turned on when the dishwasher finishes and turned back off once it’s emptied.

It uses the fact that a bit of vibration occurs early on in the cycle, and temperature rapidly dropping after it finishes. The name of the multipurpose sensor is Dishwasher Sensor. Here’s the logic:

Notice how it uses the variable isRunning to keep track on when the dishwasher is running.

That’s it. Pretty simple, but it may require a bit of trial and error on where to place the sensor on the dishwasher door.

Hiding electronics behind fake books

test@example.com — Sat, 01 Feb 2020 23:42:17 GMT

After showing some pictures of our smart home dashboard, questions started coming in about the cables going in behind the books. Where is the modem and what else is going on? Spoiler alert, the books are fake.

Here you see a couple of cables going in behind the books on the top shelve.

Removing the books reveal a tangled mess of cords, power bricks, a modem, and a home automation hub.

The fake books are hollow and can hold quite the amount of stuff, as you can see below. Looking at the books from above shows just how simple they’re built.

This is easy to make yourself if you can find some decorative books you like. You can also buy it (Covobox on Amazon) and customize the size (width) and the colors of the books. For reference, we got the 14 inch one and that is probably the smallest I would recommend.

We’ve had this for a couple of years, and it holds up great.

The dashboard for our smart home

test@example.com — Thu, 30 Jan 2020 18:18:23 GMT

I’ve had some questions lately about how we keep track of all the home automation devices spread across the house. So, I thought I’d share how our dashboard is set up. The dashboard is the web-based SharpTools that runs in Fully Kiosk Browser on an Amazon Fire Tablet HD 10 which is magnetically attached to the wall.

Since it hangs so close to shelving, the charging cable is nicely hidden, so we didn't need to install additional electrical outlets behind the tablet.

Though the tiles looked blue above due to lighting and old phone camera, all tiles are actually gray, and red is used for the ones that need our attention when certain events occur - like when the washer is done and we need to move the clothes to the dryer. This helps keep the visual noise to a minimum and the red is really easy to see from across the room.

The bottom row is half way below the fold and we utilize this for both navigation to other dashboard (the left 3 bottom tiles) and some infrequent commands. The calendar is well suited for being cut off since it easily scrolls to reveal future calendar entries without scrolling the whole screen.

The first sub-dashboard is for the lights around the house. We use orange as a neutral color instead of green/red or similar. That's because it is neither good nor bad if a light is on or off. So orange in this case just means that something is active or on.

The second sub-dashboard tell us the status of more security related information. It tells us what external doors and windows are open, if the door is locked, the cameras armed and who's home.

It also has a link to a sub-sub-dashboard for showing battery status of our various devices. This uses the Battery Tile and will change color as the battery levels get below 30% and again below 10%. None of my devices are low on battery - thanks to this dashboard.

The third sub-dashboard is temperature and weather information from around the house.

That’s it. I tried to keep it simple, but still containing all the information I need. What do you think?

Home automation sensors

test@example.com — Tue, 16 Apr 2019 15:22:59 GMT

Motion, contact, and light sensors are the most commonly used sensors for home automations in my house. With these sensors, you can make a wide variety of automations. But there are so many different manufacturers, protocols, and price points that it can be hard to choose which devices to buy and use.

When setting up automations, check out these set of best practices to avoid common mistakes. It boils down to having automations that do the same thing as you (and your guests) would do before the automation existed. For instance, turn on the light when entering the bedroom, but not if it’s filled with sunlight.

Sensor speed

Before we dive in, I want to make a note about sensor speed. For lighting automations, speed is usually the most important factor to consider. When entering a dark room, most people instinctively reach for the light switch. It’s in their muscle memory.

When a lighting automation is slow, that muscle memory triggers, and they reach for the switch. Just before pressing the switch, the automation turned on the light, so they end up turning the light switch off.

When the lighting automation is super-fast, that muscle memory never triggered in the first place and the automation feels magical.

When using Samsung SmartThings hub, make sure to run all your lighting automations in the Smart Lighting SmartApp. For all involved devices (usually switches/bulbs + sensors) make sure they use local device handlers. Then the automation will execute locally without accessing the internet. The speed difference from local to internet execution is significant.

I’m not affiliated with any manufacturer or reseller. I’ve tried enough sensors to give me an idea about which ones work better than others for my needs. You might have a different experience or know of sensors that I haven’t tried. In that case, please share that in the comments below.

Motion sensors

The most important factors to consider when buying a motion sensor are speed, battery life, and design.

Zigbee vs. Z-Wave

Of all the sensors I’ve tried, the Zigbee ones are the fastest. I don't know why that is, but others have experienced the same thing. So, for automations where speed is important such as turning lights on when entering a room, I would go with a Zigbee device every single time. The difference in speed is very noticeable.

For automations where speed isn’t as important, such as for detecting when motion has stopped, then battery life and design matters more.

Placements

Motion sensors look a little bit like small spy cams, so I try to make them as invisible as I can to not freak out my guests. Especially the ones placed in the bathrooms. Good places to but them are corners just below the ceiling.

For super-fast detection when someone enters a room, place the motion sensor on the ceiling close to the wall directly above the door pointing downwards.

Which one to get

If I could have only a single type of motion sensor, I would choose the Samsung SmartThings Motion Sensor. It magnetically attaches to its base and the battery life is superb.

Contact sensors

Also known as door/window sensors. This type of sensor consists of 2 pieces – a magnet and a sensor. When the magnet moves away from the sensor, it’s in its “open” state and when they are together it’s “closed”. Again speed, battery life, and design are the most important features to consider.

Zigbee vs. Z-Wave

Just like with the motion sensor, speed can be the deciding factor. If opening a door should trigger the lights to come on, then Zigbee is the way to go. For everything else, battery life and design are more important. For me, that means I use Zigbee devices for doors and Z-Wave devices with larger batteries for windows.

Placements

For doors, place them on the side of the door that is away from the main areas in the house. For instance, put them inside the closet where nobody can see them when closed. Put them on the bedroom side of the door instead of the hallway side.

For windows, place them where they are hardest to see. You can’t really hide them.

Color

Some manufacturers make different colored sensors. Try to match the color of the sensor with that of where you put them. This makes them more invisible.

Which one to get

For doors, I use the Visonic MCT-340 E which is super-fast and relatively small compared to most other contact sensors. For windows or other places where speed isn’t an issue and battery life matters more, the NEO Z-Wave sensor is great. My shower door has a brown metal frame, so for that I use the slightly bigger Z-Wave Rare Earth Magnet sensor which comes in brown.

Light sensors

With a light or illuminance sensor, we can adjust our automation based on the amount of light present in the room. That way we can avoid turning on the lights when the room is already filled with sunlight. Or we can adjust the dimming level of a light switch to the amount of light presently in the room.

Zigbee vs. Z-Wave

For me, it usually comes down to speed. In this case, it probably doesn’t matter since light measurement isn’t done in real-time but usually captured every 1-5 minutes depending on the sensor. So, battery life and design are more important to consider than speed.

Usually, light sensors don’t come as standalone sensors, but as part of multi-sensors that also does motion and temperature sensing. At the time of writing, I have yet to find a light sensor that also has a super-fast motion sensor.

Placements

You could place a light sensor in each room, but that would most likely be overkill. Unless you already have a multi-sensor in the rooms with light sensing capabilities. Instead, what I’ve done is to place one sensor on each side of the house. So, no matter what room I automate, I know the amount of light coming to the windows on that side of the house.

Place them in the window close to the glass so curtains don’t get in between them and the window itself.

Which one to get

I use the Dome Z-Wave Motion/Light sensor because it is relatively cheap and gives consistent light level readings. It’s important to notice that I don’t use the motion sensor in this device at all. It’s too slow and it doesn’t allow me to place it in the best position for light sensing.

When using SmartThings Hub, use the Z-Wave Temp/Light Sensor device handler for this sensor. It allows it to run locally.

I hope you found this helpful. Remember to check out more home automation ideas and the best practices.