You want to get the right piece of knowledge into the AI coding agent at the right time. If done incorrectly, you could bring in too many tokens of data for every message, for the rest of the session. Or the agent doesn't see it until it has already gone down the wrong path. Both kinds of mistakes lead to the same results: worse outcomes, higher costs, and more iterations of corrections.

In this article, we'll go through the four layers of instructions, what triggers each of them to load, and how to pick the right layer for the right kind of knowledge. The layers exist in Codex, Claude Code, Cursor, Gemini CLI, GitHub Copilot, and most similar tools, even if the file names differ between them.

Understanding the Different Layers

It helps to stop thinking of context as one big bucket, and instead think of it as separate delivery mechanisms:

Every mechanism you'll recognize from these tools falls into one of these buckets. Once you can place a piece of knowledge in the right bucket, deciding where it belongs stops being guesswork.

Always-Loaded Instructions

This is the layer most people already know: AGENTS.md, the open format used by Codex, GitHub Copilot, and many other tools, CLAUDE.md in Claude Code, and GEMINI.md in Gemini CLI. These files are read automatically at the start of every session, before the agent does anything else.

If your repository already has an AGENTS.md, the CLAUDE.md file can simply contain the text @AGENTS.md to automatically import it, so you don't have to maintain two copies.

The automatic loading is exactly what makes this layer expensive. A ten-line instruction file costs you ten lines, once. A three-hundred-line instruction file costs you three hundred lines on every single message of the session, even when the current task needs none of it. There is no opt-out and no "only when relevant" for this layer.

This is why keeping this layer short matters so much. Put the things here that the agent genuinely can't figure out on its own: the exact test command, the package manager, the files it must never touch, and the safety rules that apply every time. Almost everything else can live in one of the cheaper layers below.

This is also a good layer to keep instructions on where the agent can look for more information when needed, for on-demand reads or progressive disclosure. For example, stating the path where documentation files are located, where to read previous ADRs, code style guidelines or similar, so the agent doesn't have to scan multiple directories for it and waste context.

On-Demand Reads

README.md, type definitions, existing tests, the component you tell the agent to "follow the pattern of". None of this loads automatically. The agent has to decide to read the file, spend a tool call doing it, and the content then stays in the context for the rest of the session (or until it gets compacted away).

When used well, this is a good deal. You don't pay for anything that isn't relevant to the current task, and the files can carry far more detail than you would ever want in an always-loaded file. The trade-off is that the agent has to make the right call about what to read.

Point the agent to the right file, and you get one cheap, targeted read. Leave it vague, and the agent might read five files to find the one that mattered, or miss it completely.

It's worth noting that some tools can scope instructions to a part of the repository, like .claude/rules/-files with paths: in their frontmatter, Copilot's .instructions.md files with applyTo globs, or nested AGENTS.md files deeper down in the folder structure. These sit right between always-loaded and on-demand: they don't load for every session, but they load automatically as soon as the agent touches a matching file. This is a useful middle ground for conventions that only matter in one part of a codebase, for example, in a monorepo.

Progressive Disclosure

This is the layer that's easiest to underestimate, and the one that makes the other layers scale.

Skills and plugins are the clearest example. The agent doesn't load the full instructions of every skill up front, since that would defeat the whole point. What it always loads is a short index: a name and a one-line description for each available skill. The full content is only pulled into the context when a skill is actually invoked. The agent knows that the capability exists, without having paid for reading all of it, until it's actually needed.

Anthropic's post about Agent Skills calls this principle progressive disclosure, and it's a good name for the whole layer.

MCP tools show why this layer matters, because they traditionally haven't used it. When you connect an MCP server, the client typically loads every tool's name, description, and full parameter schema up front, straight into the always-loaded layer. This is why adding too many MCP servers is a well-known problem: Anthropic measured a typical five MCP-server setup at around 55,000 tokens of tool definitions, before the agent has even done any work.

The fix is moving the definitions into this layer. With deferred tool definitions, supported by both Anthropic's and OpenAI's platforms, only an index of names stays loaded, and a full schema only arrives when that specific tool is searched for or used. Claude Code and Codex both made this the default in mid-2026, but with fallbacks to up-front loading for older models and providers, so it's still worth checking how your tool of choice handles it.

You can build the same pattern yourself, with nothing more than Markdown files. Keep a short index in an always-loaded file, like AGENTS.md, where each line describes a subject and points to the file holding the details. The pointer instructions mentioned in the always-loaded layer are exactly this: the index costs one line per subject on every message, while a linked file only enters the context when a task actually needs it. These file pointers can be used recursively through folders and files.

Claude Code's auto memory is a built-in example of the pattern. The agent writes down its own learnings in topic files and maintains a MEMORY.md file as a concise index of what's stored where. The index is loaded at the start of every session, while the topic files are only read on demand, when something in the index matches the task at hand.

Anything that is occasionally useful, expensive to load, and possible to identify with a short label is a candidate for this layer. This is the argument for moving long, situational workflows out of AGENTS.md and into skills: a one-line pointer costs almost nothing, and the full content only loads when it's actually relevant.

Live Lookups

The last layer isn't really context in the usual sense. It's a request-response cycle in the middle of a task: nothing is preloaded, a lookup goes out when it's needed, and only the answer comes back. Anthropic's article about context engineering calls this strategy just-in-time context: the agent holds lightweight references, like file paths and URLs, and fetches the actual data at runtime.

The most common form isn't MCP servers or web fetches, it's plain CLI commands. git log and git diff answer history questions without a single file being read into the context. The gh CLI turns pull requests, issues, and CI runs into one-line lookups. A jq filter returns the one field the agent asked about, instead of the whole JSON file. The shape of the command decides the shape, and the size, of the answer, which is what makes the terminal such a strong context tool for agents.

The same mechanism covers MCP calls to a database, documentation lookups, and web fetches. The context is not filled up until the moment of use, and the answer is current, even when the underlying data has changed since yesterday. Asking a documentation tool for the signature of one specific function costs a fraction of pasting in an entire API reference. The catch is that live lookups only work well when they're specific. A vague query returns a vague and bloated answer, and you're back to the same problem as pasting in a whole file.

A Concrete Example

Let's take one concrete instruction, straight from the AGENTS.md of this website: "run pnpm run format after code changes". Where it belongs depends completely on how often it's needed:

• If it applies to every change in the repository, it belongs in AGENTS.md/CLAUDE.md. It's short, it's universal, and the always-loaded cost is worth it.
• If it only applies to one part of the repository, with its own formatting rules, it belongs in a path-scoped rule or a nested instruction file, not in the root file.
• If it's one step of a larger, occasional workflow, like a release checklist, it belongs in a skill that only loads when that workflow runs.
• If the right command depends on what was changed, it's not really a standing instruction at all. It's something the agent should look up in package.json on demand, instead of something you hardcode anywhere.

The same fact, four possible homes, and four very different costs depending on which one you pick.

Picking the Right Layer

There is no right or wrong when it comes to picking a layer, but asking three questions will settle most cases:

• How often is it needed? Knowledge that's needed on every message belongs in the always-loaded layer, if you can keep it short. Knowledge that's needed occasionally belongs in a layer that only loads when it's relevant.
• Is it durable, or about the current task? Durable conventions belong in files. Current-task specifics belong in the prompt, or in a scratch file the agent reads once.
• Would a lookup be cheaper than a preload? If the agent can find the answer itself with one targeted read or one query, that's usually cheaper than a standing instruction, and it stays correct when the underlying thing changes.

These questions won't give a universally right answer, but they're a good check of your instincts before you add one more paragraph to a file that will reload on every message for the rest of the project's life.

More Than a Cost Problem

It's tempting to treat all of this purely as cost optimization, but the quality effect is at least as important.

A short, focused always-loaded layer keeps the agent's attention on the few rules that apply every time, which makes it follow them more reliably. This effect is real enough that Claude Code's documentation recommends keeping instruction files under 200 lines, since longer files reduce how reliably the instructions get followed.

The other layers contribute in the same direction. Well-placed pointers and indexes let the agent start from the right assumptions and go straight to the relevant files, so its effort goes into the actual task. The first attempt is more often the right one, and the follow-up corrections become fewer. Overloading or starving the layers produces the reverse, in both quality and cost.

Getting the layering right improves quality and cost at the same time, because both depend on the same thing: the right information arriving at the right time, in the right shape.

Summary

Instructions to an AI coding agent don't travel through one single pipe. They arrive as always-loaded files, on-demand reads, progressively disclosed indexes, and live lookups, where each layer has a different trigger and a different cost.

The skill worth building is not writing a longer AGENTS.md. It's recognizing which layer a piece of knowledge actually belongs in, and trusting the other layers to do their job. Keep the root file short, move the occasional workflows into skills, and let the agent look up the rest.

This is the ASP.NET Core companion to my original post on NullableGuidConstraint for ASP.NET MVC & WebApi.

The original article implements one constraint for both traditional ASP.NET MVC and Web API. ASP.NET Core unified those programming models and includes a built-in guid route constraint, so the custom compatibility constraint is no longer needed in modern applications.

Optional nullable GUID parameters

Combine the built-in guid constraint with the optional-route marker:

[HttpGet("customers/{id:guid?}")]
public IActionResult Get(Guid? id)
{
    return id is null
        ? Ok("Return all customers")
        : Ok($"Return customer {id}");
}

This route matches both:

/customers
/customers/0f8fad5b-d9cb-469f-a165-70867728950e

It does not match a non-GUID value such as:

/customers/not-a-guid

Required GUID parameters

Remove ? when the route requires a GUID:

[HttpGet("customers/{id:guid}")]
public IActionResult Get(Guid id)
{
    return Ok($"Return customer {id}");
}

Minimal APIs

The same constraint syntax works with minimal API route handlers:

app.MapGet("/customers/{id:guid?}", (Guid? id) =>
{
    return id is null
        ? Results.Ok("Return all customers")
        : Results.Ok($"Return customer {id}");
});

Constraint versus validation

Route constraints help endpoint selection. They are not a replacement for validating business rules.

Use {id:guid} when a non-GUID path should not select the endpoint. Validate rules such as whether the GUID exists, is allowed, or must not be Guid.Empty inside the endpoint or application layer.

For traditional ASP.NET MVC and Web API, including the shared custom NullableGuidConstraint, see the original article.

This is the modern ASP.NET Core update of my original ASP.NET Request Paths Reference.

That older reference remains useful for applications built on traditional ASP.NET and System.Web. A separate article is needed because ASP.NET Core replaced those request APIs, separates URL components differently, and commonly runs behind reverse proxies or under a configured base path.

Consider this request:

https://www.example.com/MyApplication/MyFolder/MyPage?key=value

In this example, /MyApplication is the application's configured base path. ASP.NET Core exposes that prefix as Request.PathBase, and exposes the remaining path inside the application as Request.Path.

PathBase is not automatically the first URL segment. It is a configured or forwarded path prefix for the application. It is often empty when the app runs at the domain root, such as https://www.example.com/. It can also contain one or more segments, such as /MyApplication or /apps/customers, when the app runs under that URL prefix.

Request path properties

In a controller, Razor Page, middleware, or endpoint, use properties from HttpRequest:

PathBase contains the path prefix that has been separated from the request path. Path contains the remaining request path used by routing inside the application.

For example, if the incoming URL path is /MyApplication/MyFolder/MyPage:

The split can come from middleware such as UsePathBase, hosting under a sub-application, or forwarded proxy configuration such as X-Forwarded-Prefix.

var request = HttpContext.Request;

var pathWithinApplication = request.Path;
var fullPath = request.PathBase + request.Path + request.QueryString;

For the example request:

pathWithinApplication = /MyFolder/MyPage
fullPath              = /MyApplication/MyFolder/MyPage?key=value

Build the absolute request URL

ASP.NET Core deliberately keeps URL components separate. To create the absolute display URL, use GetDisplayUrl() from Microsoft.AspNetCore.Http.Extensions:

using Microsoft.AspNetCore.Http.Extensions;

var absoluteUrl = Request.GetDisplayUrl();
// https://www.example.com/MyApplication/MyFolder/MyPage?key=value

When the application runs behind a reverse proxy, configure forwarded headers so Scheme, Host, and the generated absolute URL reflect the original client request.

Generate application links

Do not manually concatenate paths when generating links to endpoints. Use ASP.NET Core link generation with Url.Action:

var path = Url.Action("Details", "Customers", new { id = 42 });
var absolute = Url.Action(
    "Details",
    "Customers",
    new { id = 42 },
    protocol: Request.Scheme);

For endpoint routing outside a controller, inject LinkGenerator.

Which property should you use?

• Use Request.Path to inspect the route path inside the application.
• Use Request.PathBase + Request.Path when the mounted base path matters.
• Use Request.Query to read parsed query-string values.
• Use GetDisplayUrl() when you need the complete incoming URL for diagnostics or display.
• Use Url, LinkGenerator, or endpoint names when generating application links.

For traditional ASP.NET APIs such as Request.RawUrl, Request.ApplicationPath, and Request.Url, see the original ASP.NET Request Paths Reference.

It worked, but maintaining it had become unnecessarily complicated for what the website needed to be. For example, setting up the frontend pipeline for a small tweak, sometimes several years and major npm package versions later, was an unbelievable waste of time.

Most of the website consists of content: blog posts, conference talks, articles, podcast appearances, and information about me. It did not need a database-backed application with over-complicated architecture and exaggerated technical solutions. I wanted a modern website that was easier to change, faster to experiment with, and better suited for working on together with AI coding agents.

Why Next.js

It's quite clear that React has sort of won the frontend race. I used to think the React model was too simple and stupid, but after using it for a while, I realized that this was actually the strength of the framework. It ensured a data flow which was easy to follow and troubleshoot.

Also, I wanted a website which was rendered on the server, for SEO and predictability, but still allowed the full frontend expressiveness of TypeScript/JavaScript. React has, by far, the largest ecosystem for components and functionality out there. AI coding agents are extremely competent in React and very good at Next.js. Personally, I'm also quite comfortable in Next.js, all the way from Next.js 13 and forward. All that put together made the decision easy for me.

AI-Powered Migration

The migration was done in mid-2026, so it was of course done in collaboration with AI-powered tools, such as AI coding agents.

Deleting the source code for the previous ASP.NET solution in the repository deleted more than 9 000 lines of code across 118 files. That included various code, templates, scripts, libraries, configuration, and more, accumulated during more than a decade.

Deleting the application was the easy part. The important part was preserving the content. I had some foresight here, and all my blog posts were already in Markdown-formatted files.

Migrating to Next.js

I then used Vercel's v0 tool to create the first Next.js version of the website. It provided a useful visual starting point with an App Router application, pages, components, Tailwind CSS, and shadcn/ui. It produced an impressive result quickly, but it was still just a starting point.

The initial version contained more than one hundred new files, including dozens of UI components the website did not use. Some parts looked finished while the underlying structure still needed work. The application could render pages, but it was not yet the website I had envisioned.

Choosing an AI Coding Agent

From this point, I needed a strong AI coding agent to work with, to build the technical solution I wanted, in the way and with the structure I wanted. The main agents I used were Claude Code CLI, Codex CLI, and Codex App.

The harnesses and the AI models are changing constantly, with us being in the midst of a fierce race to the top between the frontier models. Despite benchmarks, published features, and measured differences, people easily base their preferences on feelings and how well a coding agent vibes with them (pun intended). I know that I did.

My experience with Claude vs. Codex was roughly this: Codex reads between the lines of my prompts extremely well and gets very close to what I intended to ask for. I've also found a good flow working with it. Claude produces great results, but burns tokens fast, sometimes does work I did not request, and bombards me with approval prompts for every little change.

At the time of writing this article, I found specifically that the Codex App had the UX that worked best for me personally. So, that was my primary tool, while complementing it with Claude Code for second opinions or when I ran out of token usage.

Token Optimization

I intentionally used the lowest tier subscriptions for both Codex and Claude, to see how far it could take me. This meant that I really needed to mind my token burn. This drove me to adopt some key patterns, to get the most output and best results for the least amount of tokens. I shortly considered installing the Caveman-skill to really minimize token usage but chose not to, as I wanted a realistic experience and to optimize in more conventional ways.

Another early task was updating the shadcn/ui setup and removing all components not used. That change alone removed thousands of lines from the repository. A key to saving tokens here was to tell the agent to use the shadcn CLI instead of reading and writing large source files directly from GitHub (which I once had to stop an agent from doing, mid-token apocalypse).

Better AI Agent Instructions

First, I ensured the project had a solid AGENTS.md to give the AI coding agent basic information about the project. The key here was to avoid including information which easily starts to drift with changes to the website.

Another important instruction was to tell the agent to read the latest Next.js documentation, included in the installed npm package, before making relevant changes. Instructions on formatting, linting, and building were also included.

I also added specialized agent skills for areas such as Next.js best practices, React best practices, shadcn/ui, and SEO. To ensure access across both Codex and Claude, I used Vercel's skills.sh.

AI Agent Iterative Development

The work was not a single conversion prompt followed by a finished website. It was an iterative development process where I remained responsible for the direction, while Codex handled most of the implementation.

First, I took the opportunity, while the codebase was still relatively small, to do larger sweeping operations with agents and set codebase-wide baselines. I installed Vercel's own skills for Next.js best practices and asked the agent to improve everything according to the best practices. It improved the codebase to better match Next.js conventions, reorganized code, improved SEO, implemented server actions, and simplified where possible.

The key workflow I used to ensure the best outcome and surprising effectiveness in token usage was the following points:

• Point out the exact entry point file for the change.
  • If changing the functionality or look of a page on the site, I pointed to the specific page.tsx file.
  • If the change was pure functionality, I pointed to the relevant file or files.
• I described the expected outcome of the functionality I wanted added.
  • If I knew of specific functional or technical limitations, I explicitly mentioned these.
• Default to medium effort on models. Use low or medium effort for very straight forward tweaks.
• For tweaks to implementations which could be improved, I pointed to the exact file and named function and variable names to focus on.
• Keep conversation threads short. Only stay in the same thread of changes as long as most of the context is relevant.

Explicitly pointing out where to look seemed to keep token usage down significantly. I very rarely hit the limits on the lowest tier subscriptions to Codex and Claude. That makes sense, since the AI probably doesn't have to scan as much of the file, or multiple files, to figure out where to start and where to make the changes.

It's important to note that this was highly efficient at the time of posting this blog. The harnesses and/or models might change/improve significantly over time.

Stabilize and Improve Content

The blog was one of the most important parts of the migration. Some posts have existed for more than fifteen years, and their URLs still receive traffic. Preserving those posts and their URLs mattered more than reproducing every detail of the old application.

The first Next.js version loaded the Markdown files using custom code. With Codex, I later introduced Velite to provide a clearer content model and build process.

After deliberating with both Codex and Claude, we decided to use Velite to structure the existing blog post content in Markdown format. This means each blog post now has validated frontmatter containing fields such as its title, publication date, summary, tags, image, series, and draft status. Velite processes the Markdown and produces structured data for Next.js.

This made several later improvements easier:

• Posts can be grouped into a series
• Tags can be sorted and filtered consistently
• Blog search can operate on structured content
• Draft posts are supported outside production
• RSS feeds and sitemaps can use the same content source
• Syntax highlighting can be applied during content processing

Codex helped implement these features incrementally. Blog search, for example, was added as a focused feature rather than as part of the original migration. The same was true for series navigation, improved code highlighting, responsive images, and fallback images.

Each change was small enough to understand and review, but together they preserved the previous blog experience and, in many ways, improved on it.

Moving Beyond a Direct Replacement

At first, the goal was to replace the old ASP.NET website. Once the new foundation was stable, the work became more interesting: I could start improving what the website actually communicated.

The old site had grown around sections created at different times. During the migration, I reconsidered whether those sections still represented me and my work. The start page was redesigned several times and my portfolio content was restructured quite a lot. Articles I've written and podcast appearances are now shown on the website. Conference talks and speaking information became more prominent.

Some of these changes began as broad requests such as improving the start page. Others were extremely specific, such as adjusting the behavior of a navigation button or changing the layout of a single conference talk.

Using Codex as a Reviewer

Codex was also useful when I did not have a specific implementation in mind.

I could ask it to review the website for unnecessary complexity, Next.js issues, SEO opportunities, or performance problems. It would inspect the current repository, identify concrete improvements, and implement the ones that made sense.

The important part was still reviewing the result. Codex can inspect a large amount of code quickly, but it does not own the product decisions. Some technically valid suggestions did not match the website I wanted. Others needed another iteration after I saw them in the browser.

The best results came from treating Codex as an engineering collaborator rather than as an automatic code generator.

Summary

This migration couldn't have been done without using modern AI coding agents. At least not within any reasonable time.

The AI agents played an important role, but not by performing one automatic conversion. Their role was closer to that of engineering collaborators: inspecting the existing work, implementing focused improvements, cleaning up generated code, following project-specific instructions, and helping me improve the process continuously.

The website moved from a server-side ASP.NET application with more than a decade of accumulated architecture to a content-focused Next.js application built around Markdown and reusable React components.

.NET, C#, and ASP.NET are still my main tools of choice when building high-performant, robust, testable, and long-lived solutions for serious organizations. ASP.NET for building APIs is still unmatched and C# is by far my favorite language. That said, Next.js and React are my favorites for server-side and client-side hybrid solutions for stable, dynamic, and expressive websites and web applications.

The migration gave me a modern website. More importantly, it solidified a collaboration process with AI coding agents which lets me make improvements, add features, or just do small tweaks extremely quickly and get them out to production within minutes. We really live in amazing times, and hopefully it'll only get better.

This blog post is about version 2 of my .NET Tool dotnet-cleanup. You can read the post about version 1 here: dotnet-cleanup: Clean Up Solution, Project & Folder.

The v2 of the tool has been rebuilt around directory-tree cleanup and glob patterns. Compared with the original solution-and-project-oriented version, the current version can be used on any directory with sub-directories including .NET projects, web-applications, or any combination of these. It can also be used on other types of directories by specifying which folders and files, with glob patterns, to clean up.

The tool command name remains dotnet-cleanup, with a hyphen.

Like with the previous version, one big USP (unique selling point) for this tool is that it removes the cleanup folders extremely fast, by first moving them to a temporary folder, before actually deleting them off disk.

Install the tool

Install dotnet-cleanup as a global .NET tool:

dotnet tool install --global dotnet-cleanup

Update an existing installation:

dotnet tool update --global dotnet-cleanup

Include and exclude directories

Add include patterns with --path or -p and exclude patterns with --exclude or -x:

dotnet-cleanup \
  -p "**/bin" \
  -p "**/obj" \
  -p "**/node_modules" \
  -x "**/samples/**"

This glob-based model is the biggest change from the original tool. It can clean generated directories across mixed .NET and web repositories without first resolving a solution or project file.

By default, the tool includes the following paths:

**/bin
**/obj
**/node_modules

Cleanup preview

The tool will first give you a list of matching files and directories, which will be deleted. You'll then have to actively confirm.

dotnet-cleanup

If you want to be totally sure that no files will actually be cleaned, add the --noop option:

dotnet-cleanup --noop

--noop lists matching directories without moving or deleting them. Use it before every new automated cleanup configuration.

CI/CD scenario: Auto confirm

To skip the confirmation prompt, for example when used inside a CI/CD solution, add --yes to automatically confirm the deletions:

dotnet-cleanup --yes

Customization

Matched directories are moved to a temporary directory before deletion by default. There are options provided for controlling that process, if needed:

dotnet-cleanup --no-move
dotnet-cleanup --no-delete
dotnet-cleanup --temp-path "D:\cleanup-temp"

Use --no-delete when you want the moved directories to remain available for inspection. Use --no-move only when direct deletion is acceptable.

Review the current options

The README and command-line help are the source of truth for current behavior:

dotnet-cleanup --help

Cleanup is destructive. Commit or stash work, run --noop, and review include and exclude patterns before confirming.

See the DotnetCleanup repository for the current README and source.

The original article documents the earlier solution-and-project-oriented implementation.

This is the background to why I built dotnet-ping, which is easily installed as a .NET Global Tool and makes pinging URLs via the terminal really easy.

Installation

Download the latest version of .NET. Then install the dotnet-ping .NET Tool, using the terminal:

dotnet tool install -g dotnet-ping

Once installed, you can verify the tool is available by running dotnet tool list -g.

Basic scenarios

To ping a single URL just supply the URL as the command argument:

dotnet ping https://example.com/section/page

If you want to ping multiple URLs, you can supply multiple command arguments.

dotnet ping example.com/page other.com/other-page

If a URL is missing the protocol (e.g., http:// or https://), the tool will automatically assume https://.

You can use the -s option to set the sleep time between requests and the -t option to set the timeout limit for a response from the pinged URL.

If you want to ping multiple pages on the same website, you can supply a base-URL, using the -b option:

dotnet ping -b example.com /home /about /contact-us /products

Pings expect, by default, a 200 response as HTTP status. This can be modified with the -e option. The full list of documentation can be found by calling the tool with the -h option or looking at the README on GitHub or on NuGet.org.

Advanced scenarios

For more advanced scenarios, where you want to have a better overview and more complex configuration for multiple URLs, the tool supports configuration via a .json file. If there is a ping.json file in the directory that the tool is executed from, and no URL is passed as a command argument, this file will be used.

The basic structure of the file allows an array of URLs (urls) and their configuration, as well as an array of configuration group (groups), which are applied to one or multiple URLs.

{
    // Single URLs, with Single configurations
    "urls": [
        {
            "url": "test.com", // Required
            "method": "GET", // Default: GET
            "timeout": 15000, // Default: 5000ms
            "sleep": 100, // Default: 500ms
            "expect": [ 200, 201, 403 ] // Default: 200
        },
        {
            "url": "http://test2.com",
            "method": "DELETE",
            "timeout": 10000,
            "sleep": 200,
            "expect": [ 201, 202, 204 ]
        }
    ],
    // Groups of configurations, with single or multiple URLs
    "groups": [
        {
            "timeout": 20000,
            "sleep": 250,
            "expect": [ 301, 302 ],
            "urls": [ "test3.com/redirect", "test4.com/redirect" ]
        },
        {
            "timeout": 5000,
            "sleep": 550,
            "baseUrl": "https://test5.com/",
            "expect": [ 200, 201 ],
            "urls": [ "/", "/about", "/contact", "products" ]
        }
    ]
}

Usage Documentation

See the usage documentation of the tool by running dotnet ping -h:

USAGE:
    dotnet-ping [urls] [OPTIONS]

EXAMPLES:
    dotnet-ping https://example.com
    dotnet-ping https://example.com other.com -s 1000
    dotnet-ping https://example.com other.com -s 1000 -s 2000 -t 5000
    dotnet-ping /about /contact -b https://example.com
    dotnet-ping -c ping.json

ARGUMENTS:
    [urls]    The URLs to ping. If not specified, the URLs are read from the JSON config file

OPTIONS:
    -h, --help        Prints help information
    -b, --base-url    Sets the base-URL to use for requests
    -c, --config      The path to the JSON config file
    -d, --debug       Use debug console messaging
    -e, --expect      Sets the expected status code of requests. Default: 200
    -X, --request     Sets the request method. Default: GET
    -m, --minimal     Use minimal console messaging
    -s, --sleep       Sets the sleep wait time between requests in milliseconds. Default: 500ms
    -t, --timeout     Sets the timeout for requests in milliseconds. Default: 5000ms. If two values are provided, a
                      random number between the two numbers will be generated for each request

Outro

Take it for a spin and feel free to give feedback on the tool. If you find bugs or have suggestions, feel free to open an issue on GitHub or submit a pull request.

You can find the source-code on GitHub and the package on Nuget.

More than once, I've heard experienced software developers say that there are only two reasons to log: either you log Information or you log an Error. The implication here is that either you want to record something that happened or you want to be able to react to something that went wrong.

In this article, we'll take a closer look at logging and explore the fact that log levels are more than just black or red rows in your main logging system. When used correctly, they let you filter certain types of data to be logged to different destinations, have different retention times, and can be searched more easily in different structures of the data.

Why Logging?

While developing software, hopefully you write unit tests to validate isolated functionality in your code, add some integration tests, and maybe do some manual testing on top of that. But when your code is running in production, you need a way to get information about what code is being executed inside your software and have that accessible from the outside.

The most common way to do this is to add logging to your code. Usually, this code will then write to a destination, which can be a local file, a database, or a centrally controlled more advanced log solution. You can then access this information to get technical insights into what's going on in the running code.

Log entries, depending on configuration, usually contain a time stamp, a severity level, a message entered in the code, sometimes which class/file is doing the logging, sometimes a stack trace from an error in the code, and other metadata about the execution context. When done right, this can help developers follow the flow of logic through the software.

Many use logging to log key events in the system, like orders completed, users registered, reviews written, and so on. With correctly structured data, you can pipe this data into different analysis tools to get more business insights. For example, usually, you turn to your logs when something goes wrong in the software. If logging is set up correctly, you'll be able to figure out where the problem comes from and from which line of code.

If there's not enough information in your logs, you might want to ensure that a lower level of logging is written to your logs, so you can get more details about what's going on in your software. You can usually achieve this by using different log levels.

Understanding The Different Log Levels

Log levels convey the intention of the specific content of what's being logged. This can help you filter different levels of log data into different destinations, enabling you to focus on the log level relevant to the current issue you're facing. Logging to different destinations also allows you to have different retention levels for different logged content.

These are the most common log levels for logging libraries:

• Critical*
• Error
• Warn
• Info
• Debug
• Trace

* Sometimes under other names, such as Fatal or Fault.

Different languages and platforms, and their most popular logging libraries, actually support different log levels, even if the core functionality is there across them all.

Many logging libraries allow you to also handle an All scenario, where all the levels are written to the configured destinations. The None scenario, then, turns off all the logging. Some libraries also support a Custom scenario, where you can specify exactly which log levels to include.

Picking the Right Log Level

There is no right or wrong when it comes to picking a level of logging, but it's important to set the same expectations throughout a project and maybe throughout an entire organization.

Here are a few best-practice suggestions as a starting point that any team should be able to build upon:

• Critical: Used when your application is in an unrecoverable state. It crashes during startup configuration, or a framework-level component is not working as expected.
  Example: Your app cannot start up correctly or your DI setup fails.
• Error: Used for errors that stop the flow of the execution. Usually used for unknown and unexpected errors in a central catch-all scenario for an application.
  Example: Routing in your web app fails, or code in an MVC controller throws an exception.
• Warn: Used for errors that don't stop the flow of execution. Usually, these errors are somewhat expected, since the logging code is added manually to these points in the code.
  Example: Calling an external service, which you know can fail and you can silently recover from.
• Info: Used to log events in the normal flow of the code. Can be used for only system key events, to keep the volume of log data down.
  Example: User clicked a call-to-action button or new user registered.
• Debug: Used for scenarios where the information in higher levels is not enough to debug a problem. Should record the flow through the system.
  Example: Method X was called in class/object Y, to track different flows.
• Trace: Used to get as much detail as possible, tracking the flow of data through the system. Can contain sensitive data. Should probably never be activated in production.
  Example: Method X was called with parameter values Y and Z.

Usually, Critical, Error, and sometimes Warn levels contain a full stack trace for full analysis of the technical context of the problem.

You will probably want different configurations for your logging between your local development environment, your testing environment, and your production environment. It's worth noting that, with most logging libraries, configuring for one level includes the levels above it. For example, if you configure for the Info level, it'll include all levels above it, too, in the logging. So you'll also get Info, Warn (where available), Error, and Critical.

Some libraries allow you to set an upper limit as well, but this is for very specific scenarios, since you would rarely want to see Error logs but not Critical logs, for example.

However, all solutions have different needs, and these needs can change depending on what problem occurs when. Let's glance through some examples of various setups.

Local Development Environment

In a development environment on your local machine, you probably want to start off with the Debug level of logging. You can lower it to Trace if more detailed issues need diagnosed, or increase it to Info if it gets too noisy.

You'll probably always want to write to local files on your file system for quick access, and avoid writing to any central logging destination, unless you're explicitly testing the integration itself. This is because it can generate a lot of data over time, even with a small team, which usually increases cost quite a lot.

Testing Environment

In a testing environment, which is not on your local machine, you probably want to set the logging level to Info and then temporarily turn the level down to Debug and Trace as needed for the moment. If you're not interested in the normal flow of the app and only want to catch errors, you can actually set the logging level to Error.

As it's a test environment, you should only have test data logging here, so lower logging levels should not be logging sensitive production data. You don't have to worry about that aspect here, even if you should always be vigilant of it.

Since this is not a local machine, you probably don't have (and maybe shouldn't have) easy access to the machine's local disk. This is a good opportunity to use a central logging solution (there are plenty of those on the market at the moment at various pricing levels).

Production Environment

In a production environment, you could start out by configuring your logging to write Info and higher to a centralized logging service, such as a SaaS solution in the cloud. You should consider writing the Error level and higher to local disk files, in case the SaaS has any technical issues. Remember to manage the retention of these local logs to avoid being incompliant with data privacy rules and to keep costs down.

For the very complicated and hard-to-solve bugs, you need to be able to activate Debug and Trace level logging. To comply with data privacy rules without too much hassle, consider writing only these two low levels to local files, which can easily be deleted, and set a very short retention time for them. Always consider using a staging environment first, when using the Trace level and only use the production environment as the last way out.

You can also consider forwarding just the Info entries to an analysis tool of choice, to analyze key business events being triggered in your system. Some logging libraries support sending additional data in their entries, which can make this scenario more powerful.

If needed, you can also configure Error and Critical to log to another external system, maybe another SaaS, that sends out alerts for these log entries. Many existing SaaSes for logging have this functionality built-in, so there's usually not a need for this configuration, but it's good to know it's an option.

This would then mean that you're double-logging between two systems, but since you hopefully won't have a large volume of this kind of log entry, you don't have to worry too much about cost and you're only using the right tool for the right job.

The Caveats of Logging

Logging a lot of data might be the only way to solve some of the craziest bugs created out there, but there are some downsides of logging too much.

Depending on the solution you choose for logging data, too much data could make it very hard to easily search through your logs. If the logging is split into different files for different days (or hours), it's hard to analyze a trend over time.

Normally, no matter what solution you have in place for logging, the more data you log, the higher the cost will be. Even if you're logging to the local disk of the server, space can get used up quickly over time.

There is also a major security risk of leaking sensitive data if you store too much data, with too detailed information, for too long. With all the new privacy rules out there, you also risk being noncompliant for things like GDPR, if you store personal information too long, even in local files.

Conclusion

Logging is something you should include in your workflow right from the beginning when writing your software. Setting it up, and with the right strategy, will enable you to produce well-running software, monitor it in a robust way, and quickly access details about any problems that occur. Just keep the potential pitfalls in mind, such as cost, searchability, and security.

Having a solid strategy for which log level to use for what scenario is crucial for a long-term path growth path for your software. This will allow you to extend your logging in the future, making use of more refined and mature logging tools, as your software grows and the need inevitably shows itself.

C# is a language loved by its users for being versatile, productive, and keeping up with the current problems programmers need to solve. For example, maintainers have added functional programming concepts to the primarily imperative C# language, adding the powerful query-functionality in LINQ, and smoother handling of asynchronous programming with the async / await-syntax.

The unification of all versions of .NET into .NET 5 has given C# and .NET future-safety, no matter which platform you use to develop or which platform you develop for: desktop, web, cloud, mobile, or other.

Whether you're getting into C# with the launch of .NET 5 or if you're a long-time C# developer, there are a lot of great blogs out there. Based on writing quality, consistency, longevity, technical depth, and usefulness, I've put together this comprehensive list of the 20 best C# blogs publishing today.

.NET Blog

Maybe a bit obvious, but the .NET blog from Microsoft should probably your first place to check for new updates on C# and .NET. They consistently publish updates about everything related to C# and .NET but also dives deep into different subjects, such as functionality deep within .NET or the details about the performance improvements being made there.

• Writing Quality: 5
• Consistency: 5
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 5

Scott Hanselman's Blog

Sometimes, I'm unsure if you're allowed to use .NET if you're not reading Scott Hanselman's blog. There might be something in EULA about that. 😉

Jokes aside, Hanselman has been blogging about C# and .NET from the very start and has inspired many people with the content on his blog, his conference-talks, his podcast, his YouTube-channel, and more. He mixes high-level articles with some technical deep-dives, and his posts seem to be driven by his passion for learning and solving problems.

Hanselman has become quite a household name in the .NET-world and is often featured in Microsoft's keynotes. This is well deserved, given his unparalleled professional approach to quality content, interesting topics, and entertaining delivery.

• Writing Quality: 5
• Consistency: 5
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 5

Ardalis: Steve Smith's Blog

Steve Smith (aka Ardalis) is a strong proponent of producing content instead of consuming it, which is quite obviously something he lives by when you look at his output. If you are a person wanting to build your own brand, Steve is a role-model. He continually puts out qualitative information on his blog, on Twitter, on Twitch, his newsletter, his Pluralsight-courses, and he now also is building his own developer coaching-community.

Lately, Steve has been focusing on a lot of content around Domain-Driven Design (DDD) and the SOLID-principles. Much of this can be found on his blog and on some great Pluralsight-courses.

• Writing Quality: 5
• Consistency: 5
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 4

Alvin Ashcraft's Morning Dew

Want to see basically every new article the community puts out every single day? Well, then Alvin Ashcraft's Morning Dew has you covered when it comes to the subjects of C#, .NET, and the Microsoft-ecosystem.

Alvin Ashcraft is a longtime Microsoft MVP. From what you can tell from comments on his website, Morning Dew is the result of Alvin reading through over 1,600 feeds daily. Any interesting articles found are categorized and published on the blog.

• Writing Quality: N/A
• Consistency: 5
• Longevity: 5
• Technical Depth: N/A
• Broad Usefulness: 5

Troy Hunt

One of the most influential voices on the topic of security within the Microsoft-ecosystem is Troy Hunt. He is the creator of the service Have I Been Pwned (HIBP), which helps users identify if and how they've been affected by data breaches and other malicious activity on the internet.

Since Troy has Microsoft MVP for developer-security for a longer time, this is a subject that is often covered on his blog.

• Writing Quality: 5
• Consistency: 5
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 3

Tim Heuer

Tim Heuer has worked at Microsoft since 2005, currently with a focus on .NET, Visual Studio, and Azure. This gives him a lot of insight, which you can tell by the in-depth content and a great variety of technologies covered on his blog.

• Writing Quality: 5
• Consistency: 4
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 4

The Data Farm: Julie Lerman's World of Data

Julie Lerman is the absolute authority on Entity Framework, including EF Core. No matter if you're looking for a detailed, low-level problem within EF, or if you're looking for a solid guide to walk you through various aspects of Entity Framework, there is a real chance that you'll find material around it produced by Julie Lerman.

• Writing Quality: 5
• Consistency: 4
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 4

You've Been Haacked

Phil Haack was an integral part of helping Microsoft make many of its development-software open-source, along with Scott Hanselman, Scott Guthrie, and Rob Connery. Since then, Phil has moved on from Microsoft but still consistently blogs about technologies in the Microsoft-ecosystem.

With his experience inside Microsoft during their exciting transformation, there is usually something interesting for developers to learn in his posts.

• Writing Quality: 5
• Consistency: 4
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 4

ploeh: Mark Seemann

If you feel completely bulletproof in your coding-skills, go check out Mark Seemann's blog and get a glimpse of the endless things you could be doing better.

Writing good software is an art, so you can have endless opinions on other peoples' opinions, but there is almost always something new to learn from Mark's deep-diving and well-thought-through posts. Each article walks you through a complicated concept and helps you understand it and become a better developer who writes better, more maintainable code.

• Writing Quality: 5
• Consistency: 5
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 3

Daniel Cazzulino's Blog

Daniel Cazzulino (aka 'kzu') is the creator of the most popular mocking framework for C# and .NET, called Moq, which is used for testing the source-code behind .NET.

Kzu writes about all different kinds of technologies related to the Microsoft-ecosystem and mixes high-level guides with technical deep dives into non-mainstream topics.

• Writing Quality: 5
• Consistency: 4
• Longevity: 4
• Technical Depth: 5
• Broad Usefulness: 4

Visual Studio Blog

The blog for the Visual Studio Engineering Team, of course, covers everything related to Visual Studio, but it also includes adjacent technologies, which can contribute to great inspiration. They cover topics like Unity, Visual Studio for Mac, GitHub-integrations, debugging with memory-dumping, and much more.

For anyone interested in productivity in your Visual Studio-editor, it's worth noting that Mads Kristensen writes posts on the subject on the Visual Studio Blog.

• Writing Quality: 5
• Consistency: 5
• Longevity: 4
• Technical Depth: 4
• Broad Usefulness: 4

Maarten Balliauw

Maarten has a focus on web and cloud-apps, but he was also the founder of MyGet and is a frequent speaker at conferences. He brings a unique mix of experiences and knowledge to his blog, which covers many different technologies within the Microsoft-ecosystem.

• Writing Quality: 5
• Consistency: 4
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 4

Jon Skeet

If you have ever searched for a C# question, there's a 99% chance that you have, at least once, landed on an answer on Stack Overflow by Jon Skeet.

He's been the number one contributor to Stack Overflow for many years and usually with a focus on .NET and C#. It is said that he's read the whole C# specification (maybe more than once), and he regularly blogs about some of the deepest subjects around C#.

• Writing Quality: 5
• Consistency: 4
• Longevity: 4
• Technical Depth: 5
• Broad Usefulness: 3

Jimmy Bogard

Jimmy is the man behind some of the most productivity-boosting frameworks for C# and .NET developers: AutoMapper and MediatR. These frameworks help you write isolated and more easily maintainable code and his blog-posts revolve around these frameworks, but also these topics in general.

• Writing Quality: 4
• Consistency: 4
• Longevity: 4
• Technical Depth: 5
• Broad Usefulness: 4

Rick Strahl's Web Log

If you've worked with C# and .NET since its early days, especially with a focus on ASP.NET and the web, you will most probably have run into more than one of Rick Strahl's blog-posts.

In the course of working hands-on solving problems for clients, Rick has documented many solutions to real-world problems on his blog. The topics often coincide with what other people are looking to answer, so you can often find one of Rick's articles linked in answers on Stack Overflow.

• Writing Quality: 4
• Consistency: 4
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 5

.NET Tools Blog - JetBrains

JetBrain's blog for .NET covers very useful topics, whether you use their tools or not. They have specific posts about the popular tools ReSharper and Rider, but also great articles about a broad range of topics related to C# and .NET.

• Writing Quality: 5
• Consistency: 5
• Longevity: N/A
• Technical Depth: 4
• Broad Usefulness: 4

Shawn Wildermuth

Shawn has been a prolific creator of content around C#, .NET, and the Microsoft-ecosystem since the earliest days of .NET. Focusing mainly on the web-aspect of .NET, and recently, with a lot of Vue.js content, he now describes himself as an author, teacher, and filmmaker.

• Writing Quality: 4
• Consistency: 4
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 3

Fabulous Adventures in Coding - Eric Lippert's Blog

Eric Lippert used to work on the C# language design team, which is clear based on his superhuman rate of answering questions on Stack Overflow. On his blog, he deep-dives into language-design with a focus on "making developers' lives better and having fun doing it".

• Writing Quality: 5
• Consistency: 3
• Longevity: 5
• Technical Depth: 5
• Broad Usefulness: 2

StrathWeb - Filip W.

When searching for various intricate technical issues related to the Microsoft-ecosystem, it is not uncommon to end up on an in-depth article written by Filip. Recently, the topic of quantum computing has been a big focus, to add to the long archive of articles focused on C# and .NET.

• Writing Quality: 4
• Consistency: 4
• Longevity: 4
• Technical Depth: 5
• Broad Usefulness: 3

Don't Code Tired - Jason Roberts

Jason Roberts is a former Microsoft MVP who blogs on different topics around the Microsoft-ecosystem. Lately, he's been focused on testing with posts about approval tests, feature-flags, and optimizing various testing frameworks.

• Writing Quality: 4
• Consistency: 4
• Longevity: 5
• Technical Depth: 4
• Broad Usefulness: 2

Final Words

While researching this post, I went through every single account I subscribe to on Twitter to pick out the best blogs from the best people I've been following for many years - often over a decade. I was surprised to recognize so many names I had associated with quality content and learned so much from, but what surprised me even more was how many of these people had stopped blogging or switched focus away from C# and .NET.

Scott Guthrie is probably a perfect example. He used to be one of the top bloggers within our field before he was promoted to the fancy title of Executive Vice President at Microsoft, where the blog no longer seemed to be a priority. So subscribe to these blogs while you can. You never know when things will change.

This series is written from the perspective of getting to know Rust from knowing C#. There are already many good getting-started-guides out there for Rust, but this series tries to leverage your existing .NET/C#-knowledge to fast-track you into understanding Rust, by relating the concepts to what you already know.

Disclaimer: This series is being written while I'm learning Rust, so I'm by no means an expert and maybe this might be reflected in some of the example code. If you find any blatant errors, feel free to add some feedback in the comments.

Setup

In the post about Rust fundamentals, we could read about how Rust provides a complete toolchain for development, which is made available by installing Rustup, the recommended way of installing Rust.

Create a new project in a command-line by running: cargo new example_project

The file src/main.rs is your application's entry point, which will be run when you execute cargo run. So this is a good file to start with, to follow along in your code-editor. This file will only contain a function called main, with a simple Hello World, when generated by Cargo:

fn main() {
    println!("Hello, world!");
}

Code Basics

Let's start looking at some basic example-code, to go through some basic concepts in Rust. Since Rust is a C-style language, you will probably recognize much of the syntax you see in this code-snippet, as a C#-developer.

You can always find the full code for this series in the from-csharp-to-rust-project on GitHub.

Variables

Variables in Rust are created by using the let-keyword, in a very similar way to the use of the var-keyword in C#.

let title = "Ghost Buster";
let year: u16 = 1984;

Types are inferred in Rust, as you can see with the title-variable. You can also specify the type, as we do with the year-variable, where we want to use a smaller number-type than what is inferred by default.

One important difference between Rust and C# is that variables are immutable by default in Rust. If you want a variable to be mutable, you have to add mut to the variable declaration:

let mut rating_avg = 7.8;

// Someone rated the movie
rating_avg = 7.9;

Variables can be created as constants in Rust, by using the const-keyword, just like in C#. These variables have to have their types specified:

const GOOD_MOVIE_LIMIT: f32 = 7.5;

Naming Conventions

As you may have noticed, Rust naming conventions use Snake case (example_variable_name) for its variables. Unlike C# which usually uses Camel case (exampleVariableName) or Pascal case (ExampleVariableName) for most of its variables, fields, and properties.

The Rust-compiler will even warn you about using the wrong conventions for different namings.

At the moment of writing, Rust-developers also seems to prefer shorter names for variables and functions, than we usually see in C# and .NET.

Strings

In C#, we only have one string-type for all types of strings. In Rust, there are two different string-types you learn about at first. The primitive str-type, which is immutable and fixed length, as well as the String-type, which can be modified and grow in size.

let mut value = String::default();
for x in 65..68 {
    value.push(x as u8 as char);
}
// value: "ABC"

On Stack Overflow, a question called What are the differences between Rust's String and str? the most popular answer, by far, summarizes:

Use String if you need owned string data (like passing strings to other threads, or building them at runtime), and use str if you only need a view of a string.

Conversion between the two types is quite straight forward:

let title = "Ghostbusters";
// From str to String
let title_string = String::from(title);
// From String to str
let title_str = title_string.as_str();

In practical use, you can see Rust's String-type as the equivalent of StringBuilder in C#, while Rust's str is the equivalent of ReadOnlySpan<char>.

Collections

In Rust, the two most common types used to create collections are array and Vec (vector).

The array-type is a fixed-size collection and is compared to an array of a type in C# and .NET, like string[], int[], char[], and so on. The Vec-type can change in size and can be compared to List<T> in C# and .NET.

Both types can be mutated if the variable has the mut-keyword. They can also easily be converted between each other.

let mut arr = [1, 2, 3];
arr[0] = 0;

let mut vec = vec![1, 2];
vec.push(3);
vec[0] = 0;

let arr_from_vec = &vec[0.. 2];
let vec_from_arr = arr.to_vec();

Rust also has the HashMap-type, which is the equivalent of Dictionary<TKey, TValue> in C# and .NET.

let mut map = HashMap::new();
map.insert("key", 123);

Generics

Rust has support for generics, just like C# does, but with a little bit more smart functionality built into the compiler. In C#, you don't always have to specify the exact generics used in some contexts, since it can be inferred. Rust has some additional functionality for this.

For both Vec and HashMap, you don't have to specify the type explicitly when creating the object. It will be inferred by the first items added and enforced to the following added items.

Logic Flow

The if-statements in Rust are very similar to the ones in C#, except you don't need parenthesis around the condition, but it's possible to use it if you want to.

let mut info = String::from(title);

if rating_avg >= GOOD_MOVIE_LIMIT {
    info += " - You're in for a good movie";
} else if rating_avg < GOOD_MOVIE_LIMIT && year <= 1995 {
    info += "- Could be a classic...";
} else {
    info += "... Do you want to look for another movie?";
}

The if-statement is in itself an expression, from which you can catch the result. This means that you can use an if-statement to assign a variable. You can catch the value resulting from the if, the if else, or the else.

This can be used to create a shorthand if. This is a good replacement for the ternary conditional operator (In C#: var a = true ? b : c), since it's not supported in Rust.

let classic = year <= 1995 && !title.ends_with(" II");
let text = if classic { "Potential classic" } else { "We'll see..." };

Pattern Matching

Rust also has very appreciated pattern-matching-functionality. This is something that C# has implemented and seems to keep on improving it with every version.

Pattern-matching in Rust can do a lot more than just replace simple if-statements. It can also, among other things, be used to assign the result to variables. More sophisticated usages will be shown as this series goes on.

let info = match rating_avg {
    x if x > GOOD_MOVIE_LIMIT =>
        format!("{} - You're in for a good movie", x),
    x if x < GOOD_MOVIE_LIMIT && year <= 1995 =>
        format!("{} - Could be a classic...", x),
    _ => String::from("... Do you want to look for another movie?"),
};

Standard Output

To write to the standard output, in the equivalent way of Console.WriteLine in C# and .NET, you use the function println! in Rust.

let hello = "Hello";
let world = "World";
println!("{} {}!", hello, world);

In .NET, we specify the indexes inside the placeholder-curly brackes like this: Console.WriteLine("{1} {0}!", world, hello). These explicit indexes can also be used in Rust like this println!("{1} {0}!", world, hello).

If you don't specify the index In Rust and just use the empty placeholder {}, as in the above example, the index will be inferred.

Just like in C# and .NET, you can add formatting to a parameter by adding a colon-character (:) after it and a specific flag. For debugging, it's very useful to use the debug-formatting, which shows the whole content of the object in the console.

let obj = complex_obj();
println!("Debug: {:?}", obj);
println!("Debug pretty: {:#?}", obj);

Command-Line Arguments

Standard input is not as straight forward as Standard output and not a one-liner like in C# and .NET with Console.ReadLine. So we will get more into that in future articles.

Getting access to the command-line arguments passed to the application is a lot easier. This can be used to quickly build a CLI-type application.

// Execute: cargo run "The Shawshank Redemption"

let args: Vec<String> = env::args().collect();
let first_arg =
    if args.len() > 1 { args[1].clone() } else { String::default() };
// first_arg: "The Shawshank Redemption"

Functions

Functions in Rust work just like in C#, except you declare it using the fn-keyword. You can specify a return-type, but if you don't the function will just act like a void in C#.

fn is_sequel(title: &str) -> bool {
    if title.is_empty() {
        return false;
    }
    let sequel_title = title.ends_with("II");

    sequel_title
}

Notice the lack of a trailing semicolon (;) behind the sequel_title-variable at the end of the method. This makes the statement into an "expression" and Rust will implicitly accept this as a return statement, as long as it's the final expression of the method. This is why a return is needed in the body of the early returning if-statement.

This is a feature that might look weird when you're coming from another C-style language, but that you will see all over the place in Rust-code.

Functions are then called with their names and parameters, just like in C#:

fn main() {
    let sequel = is_sequel("Ghostbusters");
}

Macros

In this article, you've seen the use of the println!-function, with the unusually looking exclamation-point (!) at the end. This annotation makes this a macro. This is a too advanced of a topic to go into in this part about basic code, so I'll just point to official Rust Programming Language Book's section on macros, which summarizes:

Macros are a way of writing code that writes other code, which is known as metaprogramming.

Null-Values

The notorious Billion dollar mistake of allowing null-values into programming languages seems to be a problem tackled only recently. C# got Nullable reference types with C# 8.0 in late 2019 and F# doesn't have nulls built-in at all (even if there are ways to get around it).

Rust does not support null values. Instead, it uses patterns to wrap around types, to help indicate if there was a value or not. The most commonly used such type is the Option-type. It will return either a Some, carrying the value, or a None, indicating there was no object.

fn main() {
    let quotient = divide(123, divisor);
    match quotient {
        Some(x) if x > 10 => println!("Big division result: {}", x),
        Some(x) => println!("Division result: {}", x),
        None => println!("Division failed")
    }
}

fn divide(dividend: i32, divisor: i32) -> Option<i32> {
    if divisor == 0 {
        return None;
    }
    Some(dividend / divisor)
}

Object-Orientation

Object-orientation in Rust is a point in the code-basics where things get a bit strange for the regular C#-developer. In C#, we are used to having a class that owns its fields, properties, and methods. The class is then a template for creating an instance of an object.

Rust uses what they call a struct instead of classes, which is just a "dumb" data-structure, which contains fields, but they do not (directly) contain properties or methods. Instead, Rust provides the possibility to add functions to a struct through the impl-keyword.

pub struct Movie {
    pub title: String,
    release_year: u16,
}

impl Movie {
    // Constructor - Associated method
    pub fn new(title: &str, release_year: u16) -> Self {
        Self { title: String::from(title), release_year }
    }
    // Method
    pub fn display_title(&self) -> String {
        format!("{} ({})", self.title, self.release_year)
    }
    // Method with mutability
    pub fn update_release_year(&mut self, year: u16) {
        self.release_year = year;
    }
}

fn main() {
    let movie = Movie::new("Ghostbusters", 1984);
    println!("Movie: {}", movie.display_title());
}

First, we define the struct and its fields, where we add the pub-keyword to the struct itself and its field title. All public fields are mutable in Rust if used with the mut-keyword by other code. If you want to protect a field, use methods, like the update_release_year-function in this example.

In the impl-block, we have the new-function, which acts as a constructor. It's an associated method to the type, which is the equivalent of a static method in C#. It returns a new instance of the implementing type, which in this case is a Movie.

The function display_title is a method on the instance of the object and through the self-keyword in the first parameter, it can access fields and methods on the object, even non-public ones. It's the equivalent to the this-keyword in C#.

Inheritance

Rust doesn't have inheritance. At least not in the way a C#-developer is used to it. This seems to be a very conscious decision by the Rust-team.

Instead of inheritance, Rust provides the very powerful concept of traits, which allows you to extend any type, no matter if you've created the type or not. As a C#-developer it acts like of mixture of interfaces and extension-methods. We will look closer at traits in upcoming articles in the series.

Ownership & Borrowing

You've seen the use of the ampersand (&) character in some places of the example-code. These indicate that the use of an object is done by reference. This is something you normally very rarely need to deal with in C# and .NET.

This relates to the unique concept in Rust of References and Borrowing. This is the foundational concept which enables the language's memory-safety, performance, and "fearless concurrency".

This is also one of the hardest parts of Rust to master. It's usually the number one complaint about the language from newcomers and a very frequent topic on Stack Overflow and other Q&A-forums.

Primitives Comparison Table

Rust has a set of primitives that overlap quite well with the ones we're used to in C# and .NET. They are listed for reference:

Learn More

If you want to learn more about Rust, unrelated to its equivalent functionality in C# and .NET, you can check out the Learn Rust-section of the official website, which points to multiple resources, including the Rust Programming Language-book and the Rust by Example-book.

I also found the guide Writing Easy Rust very helpful, because it helps to explain the more complicated Rust-concepts in easier terms.

Summary

This article tried to lead you into the Rust-language by relating concepts to the ones you already know in C# and .NET.

Rust is very similar syntactically to other C-style languages, including C#. There are some concepts in Rust that are relatively different from what you're used to, but this can be a great way to be inspired to solve things in new ways. I've actually heard multiple people say that they've rediscovered their love for programming by learning Rust.

Since this series focuses on Rust from the perspective of a C#-developer, we will try to relate the Rust-concepts to the equivalent concepts in C# and .NET.

Modern Toolchain

Rust comes with a complete toolchain of everything you need to compile and run your Rust-code. All the way from the compiler, to package-management, testing, code-formatting, linting, documentation-generation, and more.

The Rust Compiler

The compiler for Rust can be executed by using the command rustc. This is usually not done by Rust-developers, but instead, it's done through the Cargo-tool.

.NET equivalent: MSBuild / The C#-compiler (csc.exe)

Cargo: Build System & Package Manager

Cargo is used by Rust-developers to manage, build, test, and document their projects. This is done by using various cargo-commands.

.NET equivalent: .NET CLI and NuGet

Cargo-Commands

Cargo can be used to create a new project by running, for example, cargo new example_project.

.NET equivalent: dotnet new

As mentioned above, Cargo builds the project and this is done by running the command cargo build.

.NET equivalent: dotnet build

Cargo is the Rust-equivalent of .NET's NuGet, so it's also used to resolve and download libraries, which it does automatically when you run the cargo build-command.

Now that your code has been built, you can run the code, given that it's a binary. This is done by using cargo run.

.NET equivalent: dotnet run

To just check that the code is valid and if that it can build, but not actually do a full build, there is a more lightweight command in Rust, which is cargo check.

Rustup: Rust Toolchain Installer

To easily get access to the complete toolchain, we use rustup, the Rust toolchain installer, which installs rustc, cargo, the rustup-CLI, and other Rust-tools.

.NET equivalent: .NET Core SDK

With Rustup, you can change which version of Rust is used, install different platforms for cross-compiling, and installing various other components.

Rust on Windows

For Rust and Rustup to work on Windows, you need to install Visual Studio, or the C++ Build Tools and the Windows 10 SDK separately. Details on this can be found on Rustup's GitHub-page.

Package Manifest

When you run cargo new, your new project will get a Cargo.toml-file, which is the manifest that contains the meta-data about your project.

An example-version of the file, with the added dependency to the regex-package, looks like this:

[package]
name = "example_project"
version = "0.1.0"
authors = ["Seb Nilsson"]
edition = "2018"

[dependencies]
regex = "1.3.9"

.NET equivalent: The .csproj-file (or the formerly used packages.config-file).

Node.js equivalent: The package.json-file.

Crates

In Rust, the term crate is used for a package. It can be either an executable binary or a library.

.NET equivalent: NuGet-packages

Crates.io

To find useful packages/crates to include in your Rust-projects, the registry-site Crates.io is used.

.NET equivalent: NuGet.org

Formatting Rust-code

Cargo contains a command which can automatically format all the Rust-code in your project. It's called rustfmt and can be executed by running cargo fmt.

Customizing the rules applied when formatting is done by adding a rustfmt.toml-file to the project, which rustfmt then will follow.

.NET equivalent: There is no built-in way to do this in the .NET CLI, but there is .NET Global Tool from the .NET-team called dotnet-format, which allows you to run dotnet format on your project.

Testing

Running the tests in a project is also done through Cargo, by running cargo test.

.NET equivalent: dotnet test

Testing is built into Rust, so you do not need to add any external testing-package.

VS Code Setup

First, make sure you've installed Rustup. You can verify that you have it installed by running the command rustup --version, which should show you a version-number.

To get started developing in Rust, with features such as syntax highlighting, auto-complete, code-formatting, refactoring, debugging, and much more, you can install Visual Studio Code, with the Rust-extension and the CodeLLDB-extension.

Consider evaluating the extension rust-analyzer as an alternative to the Rust-extension. It's not as well documented, but it seems to have more features, including the showing of type inference.

Next, create a new Rust-project by running cargo new. Now, all you have to do now is press F5 in VS Code and it will automatically create a launch.json for you, which allows you to debug your Rust-code.

Summary

By just installing rustup, we get access to the complete Rust-toolchain. This includes, among other things, Cargo, which lets us work through the full development-cycle with our projects, like: create new projects, compile the code, run the code, format the code, and run the tests in our projects.

Add VS Code with a few Rust-extensions, and you'll have a great developer-experience to get started with.

Why Rust?

In early 2019, a Microsoft engineer revealed that about 70% of all vulnerabilities in their products are due to memory safety issues. Memory safety is something you get for free with C# and .NET. But sometimes, you need more tools to squeeze out every last drop of performance.

It's also generally very beneficial to learn new languages, which could inspire us to find new ways of solving problems. To specifically do so with a modern language, which could replace C/C++ over time and has a focus on both performance and productivity, could bring a very valuable tool to any developer's toolbox.

Rust has actually been the most loved language every single year, from the 2016 survey, all the way to this year's 2020 survey.

Rust Overview

Rust is a C-style language, similar to C# or C++, and even has influences from C# (among others), with a focus on memory safety and performance.

The slogan on Rust's official website is:

A language empowering everyone to build reliable and efficient software.

The language is statically typed and is primarily imperative but also has functional aspects, similar to C#. It's an open-source language initially developed by Mozilla.

Wikipedia describes the Rust programming language in the following way:

Rust is a multi-paradigm programming language focused on performance and safety, especially safe concurrency. Rust is syntactically similar to C++ but provides memory safety without using garbage collection.

As a C#-developer, you'll find the syntax familiar, with the "Hello World!" for Rust looking like this:

fn main() {
    println!("Hello World!");
}

Rust was announced in 2010, with version 1.0 released in 2015. In comparison, C# was released in the year 2000, Java in 1995, C++ in 1985, and C in 1972. So it's quite a modern language, which has been influenced by many other languages and has hopefully used many lessons learned from these.

Performance

Rust can be as fast as C and C++ and in some cases, it might be even faster. The code compiles to machine code, instead of compiling to an intermediate language (IL), like with C# or being interpreted on the fly, like with JavaScript or Ruby.

The memory management is not provided by using automated garbage collection (like in .NET/Java) or automatic reference counting (like in Swift/Objective C). The memory safety-guarantees are provided by Rust's key concept called Ownership. By enforcing Resource Acquisition Is Initialization (RAII), Rust makes sure that any objects which go out of scope get deconstructed and its resources are freed up.

Systems & Application Programming Language

Systems programming languages typically are more close to the metal and have more direct access to the physical hardware of the machine it is running on, which enables writing performant software, such as operating systems, drivers, embedded systems, game-engines, network services, and more. Assembly language, C, and C++ are examples of traditional systems programming languages.

C# is considered as an application programming language, which usually prioritizes productive ways of building software which gives functionality to end-users. They are usually not intended to compete on performance with systems programming languages.

Rust is a language that tries to straddle both systems and application programming.

Industry Adoption

The 2020 Stack Overflow Developer Survey shows that when it comes to the most professionally used programming language, C# has a 32,3% popularity, while Rust only has 4,8%. Comparing these numbers to JavaScript's 69,7% popularity might indicate that Rust is in an early phase of its widespread professional adoption.

The adoption of Rust does seem to be ramping up though, for good reasons. In a 2020 virtual talk about Rust at Microsoft, one of their cloud developer advocates said:

Rust is the industry's best chance at safe systems programming

It does seem like Microsoft is exploring gradually switching to Rust from C and C++. These languages are not memory safe, which has caused a lot of costly errors, as mentioned before, with Microsoft's having around 70% of all their security bugs related to memory safety issues.

In 2019, Microsoft experimented with rewriting a low-level component in Windows with Rust, with a reported generally positive experience.

It's said that Amazon Web Services (AWS) uses Rust to power the deployment of the Lambda serverless runtime and some parts of EC2.

Many other companies are adopting Rust, including big players like Facebook (also with Libra), Apple, Google (with Fuchsia), and Cloudflare.

"From C# to Rust"-Series

Given that I'm learning Rust as I'm going, the goals of this series might change over time. But at this time, some topics I aim to cover are:

• Fundamentals: Tools and concepts we need to understand
• Code basics: Learning the basics of Rust-code and how the concepts relate to C#
• Advanced code: Diving deeper into more advanced code and concepts in Rust
• Rust specific functionality: Functionality and concepts which exists in Rust, but not in C#
• Rust's drawbacks: Exploring what the reasons are behind the perceived steeper learning curve of Rust

There will probably be more subjects discovered along the way. Feel free to write in the comments if there are any specific subjects you're interested in, especially coming in as a C#-developer.

Summary

Some points that make me quite excited about Rust and motivated me to start this exploration are:

• Modern C-style language, like C#, should give familiarity
• The most loved language for half a decade
• Enables both high-level productivity and low-level performance
• Growing industry adoption, even by many of the giants

The announcement of 1.0 was done middle of May 2020, but the initial announcement came in a presentation named 10 Things I Regret About Node.js by Ryan Dahl in mid-2018.

Deno is not just a rearrangement of the first two and the last two letters of "Node". It's built on top of more than 11 years of experience from Node.js running in production all over the world, by the original creator of Node.js. So this does not seem like another case of "I don't like how this project is handled, so I'm making my own fork", it's a completely new implementation.

10 Regrets about Node.js

The 10 things Ryan Dahl regretted about Node.js, which he acknowledges are impossible to change now, seem to be large motivators for the creation of Deno. It's worth noting that JavaScript has changed a lot during its 11 years of existence and Node has driven a lot of those changes.

The numbered regrets brought up in the talk were:

1. Not sticking with promises: Promises allow the usage of async/await and avoids "Callback Hell".
2. Security: Your linter shouldn't get complete access to your computer and network.
3. The Build System (GYP): Awful experience for users. It's a non-JSON, Python adaptation of JSON.
4. package.json: Not a strictly necessary abstraction and doesn't exist on the web. Includes all sorts of unnecessary information.
5. node_modules: Massively complicates the module resolution. Deviates greatly from browser semantics.
6. require("module") without the extension ".js": Needlessly less explicit. Module loader has to query the file system at multiple locations.
7. index.js: Needlessly complicated the module loading system.

It was also mentioned that Deno supports the following things:

• Unhandled promises should die immediately
• Support top-level await
• Browser compatible where functionality overlaps

Introducing Deno

Deno is a runtime for both JavaScript and TypeScript, built on the V8 JavaScript engine and Rust, with the asynchronous runtime Tokio.

The feature highlights, as of version 1.0, are:

• Secure by default: Access to files, network or environment must be explicitly enabled
• Supports TypeScript out of the box
• Ships a single executable: No separate package-manager, like npm
• Built-in utilities: test runner, code formatter, built in debugger, dependency inspector and more
• Bundling: Scripts can be bundled into a single JavaScript file
• Standard modules: Audited and guaranteed to work with Deno

Executing JavaScript/TypeScript

Deno being a single executable file, not needing a separate package-manager or package.json-file, an example of a working HTTP server application looks like this:

import { serve } from "https://deno.land/std@0.50.0/http/server.ts";
for await (const req of serve({ port: 8000 })) {
  req.respond({ body: "Hello World\n" });
}

There is no need to install anything beforehand or add any configuration-files. All you need to run is:

deno run example.js

Since the code is executed in a sandbox, which is secure by default, the explicit access must be granted for the fetching the remote dependency, by adding the flag --allow-net to the command-line.

The remote dependency is cached locally and only reloaded if the script is executed with the flag --reload.

Limitations

Deno 1.0 has some known limitations, which include things like:

• No automatic compatibility with existing npm-packages
• HTTP server performance is not as good as Node.js, even if it's not too far away
• TypeScript performance issues

Since Deno uses ECMAScript modules, which uses import instead of require, any module using require has to be converted.

Summary

I'm surprised at how excited I am about the potential of Deno. For me, to have the creator of Node.js use a decade of learning to start over with a blank slate is what makes this a rare situation of high potential.

Some things I look forward to from Deno are:

• A fresh take on a JavaScript/TypeScript runtime
• First Class TypeScript Support
• Skipping package.json and npm install when you just want to get started fast
• Promises as default: Avoiding callback hell and mixed concepts between different parts of the code
• Not having to deal with the node_modules-folder

To enable the assignment of the value null to a type, you have to explicitly mark that type. This uses the same concept of nullable as introduced in C# 2.0, where you, for example, make an int nullable by adding a question mark after it: int?.

When we look at a regular example service-class, we can see which benefits can be had from Nullable reference types:

public class ProductService
{
    // This method accepts a non-null string for 'productId'
    // and always returns a string
    public string FormatProductId(string productId)
    {
        // ...
    }

    // This method accepts a nullable 'formattedProductId'
    // and returns a string or null
    public string? TryGetProductName(string? formattedProductId)
    {
        // ...
    }
}

This makes things all fine and clear. We know that the method FormatProductId never returns null and that it doesn't accept null in its parameter. We also know that the method TryGetProductName returns a string which could be null and that the parameter accepts a string which could be null.

This is great, this means that we don't have to perform a null-check on productId-parameter of the FormatProductId-method, right? Well, not exactly...

Confusion: Mixed nullable environments

In an environment where all your code has Nullable reference types enabled, you can trust the output of a method and the input to its parameters. In a mixed nullable environment, things are not as straight forward, especially when you look at how IntelliSense in Visual Studio signals what to expect from the code.

Scenario 1: Modern app & legacy library

Imagine that your new modern app has Nullable reference types enabled, but you're using an external library that is legacy and does not have this enabled. This external library can be your own old library or something you've included from NuGet.

The problem now becomes that the external library is signaling, for example, that it has a method that returns a string and not a string?, so you should be able to trust that it is not null, right? Unfortunately not. Even with a local non-nullable project, IntelliSense tells me that the returned string is not null, even when it is.

Scenario 2: Legacy app & modern library

Imagine that you have just put together a nice library that you want others to use, either in your project, organization or publicly through NuGet. One of the best parts about using Nullable reference types is that the compiler will warn you if you try to send in a null value as a parameter to a method that explicitly states that it doesn't support null.

Nice, now you can clean out all those noisy null-checks at the top of all the methods, right? Unfortunately not. Your code might be used by another assembly (or an older version of Visual Studio), which doesn't detect the non-nullability.

In a way, this means you have to reverse the way you do null-checks in your code.

public class ProductService
{
    // This method does not accept a null-value
    // and if it does, it should throw an exception
    public string FormatProductId(string productId)
    {
        if (productId == null)
            throw new ArgumentNullException(productId);
        // ...
    }

    // This method accepts null-values
    // and should adjust its logic accordingly
    public string? TryGetProductName(string? formattedProductId)
    {
        return
            formattedProductId != null
            ? GetProductName(formattedProductId)
            : null;
    }
}

Key takeaways

My own take-aways from exploring this aspect of Nullable reference types are:

• When building a library, always check for null in incoming method-arguments, even when Nullable reference types is enabled
• When consuming an external legacy library, don't trust the return-type to not be null (even if it says it's not)
• In a mixed nullable environment, the feature to guard us against NullReferenceExceptions is likely to mistakenly cause some more of them
• When this feature is fully adopted, there will be a reduction in a lot of the overhead in null-handling code

Thoughts

Hopefully, in .NET 5, this feature is enabled by default and these kinds of confusions, and described associated errors can be avoided.

One idea for an improvement to the IntelliSense-behavior around assemblies that are not known to have Nullable reference types enabled could be to show all these types as nullable. Both because it makes things super-clear, but also because of the fact that they actually are nullable.

This change would make everything in the whole .NET Core CLR light up as nullable, but as of .NET Core 3.1, it all is nullable, by definition.

To list the top 10 largest files in the Windows temporary folder, which is larger than 1 Mb and starts with the letter W, skipping the first 5, ordering by size, the C#-code with LINQ would look somewhat like this:

new System.IO.DirectoryInfo(@"C:\Windows\Temp")
    .GetFiles()
    .Where(x => x.Length > 1024 && x.Name.StartsWith("W"))
    .OrderByDescending(x => x.Length)
    .Select(x => new { x.Name, x.Length })
    .Skip(5)
    .Take(10)
    .ToList()
    .ForEach(x => Console.WriteLine($"{x.Name} ({x.Length})"));

The equivalent logic in PowerShell has a bit of a more daunting syntax, especially if you're not used to it:

Get-ChildItem "C:\Windows\Temp" `
| Where-Object {$_.Length -gt 1024 -and $_.Name.StartsWith("W")} `
| Sort-Object {$_.Length} -Descending `
| Select-Object -Property Name, Length -First 10 -Skip 5 `
| ForEach-Object {Write-Host "$($_.Name) ($($_.Length))"}

That's a bit explicit and verbose, but if you use the command Get-Alias in PowerShell, you will see a lot of useful aliases, which make the syntax a bit terser and easier to get an overview of:

gci "C:\Windows\Temp" `
| ?{$_.Length -gt 1024 -and $_.Name.StartsWith("W")} `
| sort{$_.Length} -Descending `
| select Name, Length -First 10 -Skip 5 `
| %{write "$($_.Name) ($($_.Length))"}

In a real scenario, you probably wouldn't write each result to the console, but let PowerShell present the result in its default grid format.

So I created another TagHelper, which allows me to wrap any HTML, inline code in ASP.NET Core and other TagHelpers, and get all the content inside the TagHelper's tag to be HTML-encoded, like this:

<html-encode>
    <a href="@Url.Action("Index")">Read More</a>
    @Html.TextBox("No_Longer_Recommended-TagHelpers_Preferred")
    <my-other-tag-helper />
</html-encode>

From this, I will get the raw HTML of the link with an UrlHelper-result, the result of the HTML-helper and the result of my other TagHelper.

The source-code for the html-encode-TagHelper is as follows:

[HtmlTargetElement("html-encode", TagStructure = TagStructure.NormalOrSelfClosing)]
public class HtmlEncodeTagHelper : TagHelper
{
    public override async Task ProcessAsync(TagHelperContext context, TagHelperOutput output)
    {
        var childContent = output.Content.IsModified
            ? output.Content.GetContent()
            : (await output.GetChildContentAsync()).GetContent();

        string encodedChildContent = WebUtility.HtmlEncode(childContent ?? string.Empty);

        output.TagName = null;
        output.Content.SetHtmlContent(encodedChildContent);
    }
}

What about when an API limits your requests per second? This is probably something you would want to handle somewhere central in your code and not spread out everywhere where you make an HTTP call to the API.

For me, the solution was to add a Outgoing request middleware to the setup of the HttpClientFactory.

With this, I can just configure the startup services to use this RateLimitHttpMessageHandler-class with the HttpClientFactory:

services
    .AddHttpClient<IApi, Api>()
    .AddHttpMessageHandler(() =>
        new RateLimitHttpMessageHandler(
            limitCount: 5,
            limitTime: TimeSpan.FromSeconds(1)))
    .SetHandlerLifetime(Timeout.InfiniteTimeSpan);

This ensures that wherever I use the class IApi, through dependency injection, it will limit the calls to the API to only 5 calls per second.

The simplified version of code for the RateLimitHttpMessageHandler:

public class RateLimitHttpMessageHandler : DelegatingHandler
{
    private readonly List<DateTimeOffset> _callLog =
        new List<DateTimeOffset>();
    private readonly TimeSpan _limitTime;
    private readonly int _limitCount;

    public RateLimitHttpMessageHandler(int limitCount, TimeSpan limitTime)
    {
        _limitCount = limitCount;
        _limitTime = limitTime;
    }

    protected override async Task<HttpResponseMessage> SendAsync(
        HttpRequestMessage request,
        CancellationToken cancellationToken)
    {
        var now = DateTimeOffset.UtcNow;

        lock (_callLog)
        {
            _callLog.Add(now);

            while (_callLog.Count > _limitCount)
                _callLog.RemoveAt(0);
        }

        await LimitDelay(now);

        return await base.SendAsync(request, cancellationToken);
    }

    private async Task LimitDelay(DateTimeOffset now)
    {
        if (_callLog.Count < _limitCount)
            return;

        var limit = now.Add(-_limitTime);

        var lastCall = DateTimeOffset.MinValue;
        var shouldLock = false;

        lock (_callLog)
        {
            lastCall = _callLog.FirstOrDefault();
            shouldLock = _callLog.Count(x => x >= limit) >= _limitCount;
        }

        var delayTime = shouldLock && (lastCall > DateTimeOffset.MinValue)
            ? (limit - lastCall)
            : TimeSpan.Zero;

        if (delayTime > TimeSpan.Zero)
            await Task.Delay(delayTime);
    }
}

• Ownership of the files: If the solution used disappears tomorrow, you can still access my files.
• Predictable URLs: The URL to the resources should never change. You don't want to have to update all your blog-posts or other external links floating around the internet.
• Good tooling: Avoiding slow web-upload, when uploading multiple and/or large files, but also easily getting an overview of your files.
• (Bonus) Pretty URLs: "Pretty" looking URLs are easier to check for copy-paste errors, but could also potentially benefit SEO.
• (Bonus) Low or no cost: Since there are free services out there, paying for file-hosting must be worth it.

Non-fitting Alternatives

When I started evaluating alternatives, a while back, Flickr was still a thing. The problem was that I couldn't predictable directly link to an image I've uploaded. After feeling all the obstacles, which indicated that using Flickr for image-hosting was being actively blocked, I understood it was too much of a hack.

Historically, I've been using Google's image hosting through Blogger, which is where this blog started out. The problem was that this also felt like I hack and I was always worried that the URLs would change and I'd have to go through every single blog-posts I've ever made and update all images.

Services like Dropbox and Google Drive seem to actively try to block the use of their services for this, even if they are accessible through the web.

Azure Storage for easy web file-hosting

Enter Azure Storage, with its widespread adoption, familiar interface and extremely affordably priced Blob Storage. It checks off all my points in the checklist and more. Giving it's backing, it's fair to assume more functionality will be added ongoingly.

Azure Blob Storage can be used to store data-blobs of almost any size in the Azure-cloud. By providing a path/key, you can read or write to that "file" at that "path". The overall performance of Azure Storage is great and also an important feature of the service, but the simple mechanisms of Azure Blob Storage make it very fast.

Expose blob-content to the internet

So you could build a web-app which accesses your files on Azure Blob Storage and expose them through URLs in your API, but you can also let Azure handle that for you, by activating anonymous read access to your blobs.

You can do this on blob-level, so you can have a dedicated blob for public files, separately from your other blobs in the same Storage-account. These files will be read-only when you use the option Blob (anonymous read access for blobs only), found under the Access policy-section of the selected blob.

Upload files

Then you can use the Azure Portal, programmatically use the Azure Blob Storage API to upload files, or you can use application Azure Storage Explorer, for a friendly GUI-experience to get started.

Now you can share your files anywhere you want, via the provided URL from Azure or through a more pretty URL, using a custom domain.

Add a custom domain

To fulfill the criteria of pretty URLs, you can set your own custom domain for an Azure Storage-account. If you do not do this, the default URL for Azure Blob storage is https://{storage-account-name}.blob.core.windows.net/{file-path}.

Activate Azure CDN

This is a great start for your small project to start out with, but you can in the future easily transition into using the full power of Azure Content Delivery Network (Azure CDN) on your existing Azure Storage-account, simply by activating it from the Azure CDN-section in your Storage-account.

Minimally for this reason, and mostly for fun, I decided to write a .NET Core Global Tool which quickly generates one or multiple GUIDs/UUIDs, in whatever format could be needed.

Installation

Download the .NET Core SDK 2.1 or later. Then install the dotnet-guid .NET Global Tool, using the command-line:

dotnet tool install -g dotnet-guid

Usage

Usage: guid [arguments] [options]

Arguments:
  Count         Defines how may GUIDs/UUIDs to generate. Defaults to 1.

Options:
  -?|-h|--help  Show help information
  -n            Formatted as 32 digits:
                00000000000000000000000000000000
  -d            Formatted as 32 digits separated by hyphens:
                00000000-0000-0000-0000-000000000000
  -b            Formatted as 32 digits separated by hyphens, enclosed in braces:
                {00000000-0000-0000-0000-000000000000}
  -p            Formatted as 32 digits separated by hyphens, enclosed in parentheses:
                (00000000-0000-0000-0000-000000000000)
  -x            Formatted as four hexadecimal values enclosed in braces,
                where the fourth value is a subset of eight hexadecimal values that is also enclosed in braces:
                {0x00000000,0x0000,0x0000,{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}}
  -e            Defines if the GUIDs/UUIDs should be empty, using zero-values only.
  -u            Defines if the GUIDs/UUIDs generated should be upper-cased letters.

Examples

To get a single GUID/UUID, simply type:

guid

To get 3 random GUIDs/UUIDs, with letters in upper-case, formatted with brackets:

guid 3 -b -u

You can find the source-code on GitHub and the package on Nuget.

You can find a great list of more .NET Core Global Tools on GitHub, maintained by Nate McMaster.

We developers like to think of developing software as an exact science, but sometimes, you just need to wipe your source-files to solve some kinds of problems.

For .NET-developers, there are many issues on Stackoverflow which are solved by just deleting your bin and obj-folders. For people using Node.js, probably just as many answers contains the step of removing your node_modules-folder.

Those are some of the reasons why I created dotnet-cleanup, which is a .NET Core Global Tool for cleaning up solution, project or folder. This was made easy by following Nate McMaster's post on getting started with creating a .NET Core global tool package.

Deleted files and folders are first moved to a temporary folder before deletion, so you can continue working with your projects, while the tool keeps cleaning up in background.

Installation

Download the .NET Core SDK 2.1 or later. Then install the dotnet-cleanup .NET Global Tool, using the command-line:

dotnet tool install -g dotnet-cleanup

Usage

Usage: cleanup [arguments] [options]

Arguments:
  PATH                  Path to the solution-file, project-file or folder to clean. Defaults to current working directory.

Options:
  -p|--paths            Defines the paths to clean. Defaults to 'bin', 'obj' and 'node_modules'.
  -y|--confirm-cleanup  Confirm prompt for file cleanup automatically.
  -nd|--no-delete       Defines if files should be deleted, after confirmation.
  -nm|--no-move         Defines if files should be moved before deletion, after confirmation.
  -t|--temp-path        Directory in which the deleted items should be moved to before being cleaned up. Defaults to system Temp-folder.
  -v|--verbosity        Sets the verbosity level of the command. Allowed levels are Minimal, Normal, Detailed and Debug.
  -?|-h|--help          Show help information

The argument PATH can point to a specific .sln-file or a project-file (.csproj, .fsharp, .vbproj). If a .sln-file is specified, all its projects will be cleaned.

If it points to a folder, the folder will be scanned for a single solution-file and then for a single project-file. If multiple files are detected an error will be shown and you need to specify the file.

If not solution or project is found, the folder will be cleaned as a project.

Example

To cleanup a typical web-project, you can specify the paths to be cleaned in the projects like this:

cleanup -p "bin" -p "obj"  -p "artifacts" -p "npm_modules"

You can find the source-code on GitHub and the package on Nuget.

You can find a great list of more .NET Core Global Tools on GitHub, maintained by Nate McMaster.

More convenient would be to able to pass in a Lambda-expression, specifying what field you want to do the distinction by, like this:

var distinctItems = items.Distinct(x => x.Id);

To do this, you can add the following extension-methods to your projects:

public static IQueryable<TSource> Distinct<TSource>(
    this IQueryable<TSource> source, Expression<Func<TSource, object>> predicate)
{
    // TODO: Null-check arguments
    return from item in source.GroupBy(predicate) select item.First();
}

public static IEnumerable<TSource> Distinct<TSource>(
    this IEnumerable<TSource> source, Func<TSource, object> predicate)
{
    // TODO: Null-check arguments
    return from item in source.GroupBy(predicate) select item.First();
}

The extension-method using IQueryable<T> works with ORMs like Entity Framework, while IEnumerable<T> works with all types of collections, in-memory or otherwise, depending on implementation.

Warning: Avoid using this with EF Core version 1.x or 2.0, since the .GroupBy-execution is always made in-memory. So you might get the whole content of your database loaded into memory. Only use it with EF Core 2.1 and above in production-scenarios.

In his article, Troy lists 3 ways (to do it wrong), which I have implemented for ASP.NET Core, and added support for one more way, which is URL versioning. This library supports the following ways to version your API:

• URL versioning
• Query string versioning
• Custom request header
• Content type

URL versioning:

HTTP GET:
https://my-web-app.com/api/v2/customers

Query string versioning:

HTTP GET:
https://my-web-app.com/api/customers?api-version=2

Custom request header:

HTTP GET:
https://my-web-app.com/api/customers
api-version: 2

Content type:

HTTP GET:
https://my-web-app.com/api/customers
Accept: application/vnd.api-version.v2+json

[RouteVersion]-attribute

All you need to do is use the [RouteVersion]-attribute on the Controller-Actions you want to version and provide the route-version as an argument:

[Route("api/v{api-version}/[controller]")]
[Route("api/[controller]")]
[ApiController]
public class CustomersController : ControllerBase
{
    [HttpGet]
    [RouteVersion(1)]
    public ActionResult<string> GetV1()
    {
        return "Get Customers Version 1";
    }

    [HttpGet]
    [RouteVersion(2)]
    public ActionResult<string> GetV2()
    {
        return "Get Customers Version 2";
    }

    [HttpPost]
    [RouteVersion(1)]
    public ActionResult<string> PostV1()
    {
        return "Post Customers Version 1";
    }

    [HttpPost]
    [RouteVersion(2)]
    public ActionResult<string> PostV2()
    {
        return "Post Customers Version 2";
    }
}

The attribute will only resolve versioning between Controller-Actions, everything else is handled by the regular ASP.NET Core routing, and behave as you're used to.

Configuration

In your Startup.cs you can configure what ways of API-versioning you want to support (all activated by default). You can also change the keys of the routing, query string, custom header and content type.

public void ConfigureServices(IServiceCollection services)
{
    services.ConfigureRouteVersions(options =>
    {        
        options.UseRoute = true;
        options.UseQuery = true;
        options.UseCustomHeader = true;
        options.UseAcceptHeader = true;

        // Set route-name in template used. For example: "api/v{version}/[controller]"
        // Default: "api-version"
        options.RouteKey = "version";

        // Set query string-key used. For example: "/api/customers?v=1"
        // Default: "api-version"
        options.QueryKey = "v"; // To use: '/api/customers?v=1'

        // Set custom version header used. For example: "my-app-api-version"
        // Default: "api-version"
        options.CustomHeaderKey = "my-app-api-version";

        // Set Accept-header vendor used. For example: "application/vnd.my-custom-api-header.v1+json"
        // Default: "application/vnd.api-version.v1+json"
        options.SetAcceptHeader("my-custom-api-header");

        // Set Accept-header regex-pattern. For example: "application/pre.my-custom-vendor-api.v1+json"
        options.AcceptRegexPattern = @"application\/pre\.my-custom-vendor-api\.v([\d]+)\+json";
    });

    services.AddMvc();
}

Default version

If you know that your new version of an API-endpoint is compatible with previous version, and if you want to support it, you can use the IsDefault-parameter with the [RouteVersion]-attribute. For example, if you've just added new fields to the next version and you find that is compatible enough to be the default version of the API-endpoint:

[Route("api/[controller]")]
[ApiController]
public class CustomersController : ControllerBase
{
    [HttpGet]
    [RouteVersion(1)]
    public ActionResult<string> GetV1()
    {
        return "Get Customers Version 1";
    }

    [HttpGet]
    [RouteVersion(2, IsDefault = true)]
    public ActionResult<string> GetV2()
    {
        return "Get Customers Version 2";
    }
}

Then you can make a call to the URL for the API-endpoint without specifying the version and get the default version, which in this example is v2:

HTTP GET:
https://my-web-app.com/api/customers/
> "Get Customers Version 2"

Contributing

You can find the source code on GitHub, the newest unstable build on MyGet and the latest version of the library on NuGet

If you're in the scenario of using a mono-repo, where you have multiple projects in a single repo, and you want to deploy this single code-base to multiple applications and services in Azure, there is a simple way to do this.

Kudu, the engine behind git-deployments in Azure App Service, has documentation on how to customize deployments, but only one of these ways works well with the mono-repo-scenario. The approach of using a .deployment-file unfortunately locks the configuration of the specified project into your source-code, so it won't work for mono-repos.

Instead, using the Application settings available in all Azure App Services, you use the key PROJECT to set the value for the path of the project you want to be deployed to your different Azure App Services. So this solution works for Function Apps, Web Apps, API Apps and much more.

Example

If you have the following code-structure in your single repository:

• /src/ExampleProject/ExampleProject.csproj
• /src/ExampleProject.FunctionsApp/ExampleProject.FunctionsApp.csproj
• /src/ExampleProject.WebApiApp/ExampleProject.WebApiApp.csproj
• /src/ExampleProject.WebApp/ExampleProject.WebApp.csproj
• /test/ExampleProject.Tests/ExampleProject.Tests.csproj

Then you'd set up your PROJECT-path in Application settings for your different Application Services like this:

• Function App: "src/ExampleProject.FunctionsApp"
• Web App: "src/ExampleProject.WebApp"
• API App: "src/ExampleProject.WebApiApp"

With the paths relative to the Git-repository's root-path. You can also point directly to the .csproj-file, if there is any risk of ambiguity in the same file-folder.

When this is done you can configure your Azure App Services for Continuous Deployment using the same repository, in GitHub, Bitbucket, local Git or any other source supported in Azure.

There are scenarios when you need to convert an anonymous type in C#, or any other type, into a dynamic, or more specifically to the underlying ExpandoObject-type.

My specific need was to be able to move the data from an anonymous type from the current assembly into a dynamically executed external assembly. So I created an extension-method for this, which moves all the properties from any object into a new ExpandoObject.

public static ExpandoObject ToExpandoObject(this object obj)
{
    // Null-check

    IDictionary expando = new ExpandoObject();

    foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(obj.GetType()))
    {
        expando.Add(property.Name, property.GetValue(obj));
    }

    return (ExpandoObject) expando;
}

You can use the extension-method on any type of object and choose to reference the resulting type by it's actual type ExpandoObject or as a dynamic.

var anonymous = new {Id = 123, Text = "Abc123", Test = true};

dynamic dynamicObject = anonymous.ToExpandoObject();
ExpandoObject expandoObject = anonymous.ToExpandoObject();

Since the code uses the type System.ComponentModel.TypeDescriptor, if you use .NET Core or .NET Standard, you might need to reference the Nuget-package named System.ComponentModel.TypeConverter.

Sometimes a regular lock can be too aggressive and lock too much running code for too long. You can solve this by cleverly locking on unique objects, but that handling is complex, error-prone and can become tedious.

Many times you know that you have a specific value or ID which is the key you want to lock on. For instance, you might want your code to not write to the database from multiple actions performed in parallel on your web-application. Using the Nuget-package KeyLocks will give you easy to write syntax to handle this:

private static KeyLock<string> _keyLock = new KeyLock<string>();

public void Main()
{
    Parallel.Invoke(
        () => { UpdateData("entity-123", "First new value"); },
        () => { UpdateData("entity-123", "Second new value"); }, // This will await line above
        () => { UpdateData("another-entity-456", "Another new value"); },        
        () => { UpdateData("yet-another-entity-789", "Yet another new value"); });
}

private void UpdateData(string id, string value)
{
    _keyLock.RunWithLock(id, () =>
    {
        // Execute locked code
    });
}

Make sure the instance of KeyLock<T> is shared between threads executing the code you want to lock on. In this case, I solved it by making the instance static and therefore shared across all instances of the code using it.

The package also contains the type NameLock is a short-hand term for KeyLock<string>. It defaults to being case-sensitive, but that can be changed by passing the correct IEqualityComparer<T> as a constructor-argument like this:

var nameLock = new NameLock(StringComparer.InvariantCultureIgnoreCase)

See the README-file on GitHub for the latest detailed information about KeyLocks. Or try it out through Nuget by running Install-Package KeyLocks in your project. You can even follow the absolutely latest build on MyGet.

According to Wikipedia the date and time-format RFC3339/ISO 8601 usages includes:

On the Internet, the World Wide Web Consortium (W3C) uses ISO 8601 in defining a profile of the standard that restricts the supported date and time formats to reduce the chance of error and the complexity of software.

My specific need to format a System.DateTime-value in a RFC3339-format came when I used one of Google's REST APIs and they required a parameter in the RFC3339-format. Here is the code is the extension-method which provides the functionality of formatting a DateTime as a string in RFC3339-format:

public static string ToRfc3339String(this DateTime dateTime)
{
    return dateTime.ToString("yyyy-MM-dd'T'HH:mm:ss.fffzzz", DateTimeFormatInfo.InvariantInfo);
}

There are many situations when you handle URLs or URIs in applications today, no matter if it's a web-application or not. Often you need to handle absolute URLs, like https://testsite.com/section/page, and relative URLs, like /section/page.html.

To easily convert URLs between absolute and relative, or just ensure these two formats, I created extension-methods for the type System.Uri, which allows you to write code like this:

var absoluteToRelative = new Uri("https://www.test-relative.com/customers/details.html").ToRelative();
// Outputs: "/customers/details.html"

var relativeToAbsolute = new Uri("/orders/id-123/", UriKind.Relative).ToAbsolute("https://www.test-absolute.com");
// Outputs: "https://www.test-absolute.com/orders/id-123/"

The extension-methods which makes this possible are the following:

public static string ToRelative(this Uri uri)
{
    // TODO: Null-checks

    return uri.IsAbsoluteUri ? uri.PathAndQuery : uri.OriginalString;
}

public static string ToAbsolute(this Uri uri, string baseUrl)
{
    // TODO: Null-checks

    var baseUri = new Uri(baseUrl);

    return uri.ToAbsolute(baseUri);
}

public static string ToAbsolute(this Uri uri, Uri baseUri)
{
    // TODO: Null-checks

    var relative = uri.ToRelative();

    if (Uri.TryCreate(baseUri, relative, out var absolute))
    {
        return absolute.ToString();
    }

    return uri.IsAbsoluteUri ? uri.ToString() : null;
}

• Register AutoMapper's mappings through Autofac's component-registration for dependency-injection
• Use registered components in Autofac for dependency-injection into AutoMapper's mapped objects

This is actually possible! It's done by providing AutoMapper with Autofac's IComponentContext-object, which is not dependent on if you've registered everything you need in the Autofac component-registrations, before configuring AutoMapper. So you can register more components after registering your AutoMapper-configuration and still access all these in your AutoMapper context when they get resolved later in your code.

We'll start with the code for registering the Autofac-components and follow it with some explaining:

public IContainer RegisterComponents()
{
    var builder = new ContainerBuilder();

    builder.RegisterType<PreMapperComponent>().As<IPreMapperComponent>();

    builder.Register(ConfigureMapper).SingleInstance();

    builder.RegisterType<PostMapperComponent>().As<IPostMapperComponent>();

    return builder.Build();
}

private IMapper ConfigureMapper(IComponentContext context)
{
    var configuration = new MapperConfiguration(config =>
    {
        var ctx = context.Resolve<IComponentContext>();

        config.CreateMap<EntityType, DtoType>()
            .ConstructUsing(_ =>
                new DtoType(ctx.Resolve<IPreMapperComponent>(), ctx.Resolve<IPostMapperComponent>()));
    });

    return configuration.CreateMapper();
}

The method RegisterComponents is included to show a somewhat realistic scenario, and for this case specifically showing that you can register components in Autofac both before and after configuring AutoMapper.

The code var ctx = context.Resolve<IComponentContext>() might look strange, but is crucial for this solution to work. Why not use the context-argument directly in the ConfigureMapper-method? Because it will throw an exception starting with This resolve operation has already ended, and instructs you to resolve IComponentContext again, which is what we're doing here.

Running the AutoMapper-code

Then we run the code using AutoMapper and the mapping of types needing dependency-injection of constructor-parameters:

public static void Run(IContainer container)
{
    var mapper = container.Resolve<IMapper>();

    var source = new EntityType(123, "Test-text", "Test-description");

    var dto = mapper.Map<DtoType>(source);

    dto.RunComponents();
}

The code dto.RunComponents() is the one that executes the injected implementations of the interfaces IPreMapperComponent and IPostMapperComponent used in the type DtoType.

You can find all the code-files involved in this example in this Gist.

This can all also be done through the recommended approach of Modules in Autofac and Profiles in AutoMapper.

Sometimes when you do calculations on values you know that the result should not fall outside two specific values. For example, if your calculating a percentage-value as an int-value, then you know the result should be between 0 and 100.

public int GetPercentage(int val1, int val2)
{
    var calculation = val1 / val2;
    var ensuredPercentage = calculation.Clamp(0, 100);
    return ensuredPercentage;
}

This functionality can easily be extended to all classes which inherits from System.IComparable<T>, which are for example all types of numbers like int, double, long and so on, but also DateTime and more.

The following extension-method adds the Clamp-method to all objects of types inheriting from IComparable<T>:

public static T Clamp<T>(this T value, T min, T max)
    where T : IComparable<T>
{
    var comparer = Comparer<T>.Default;

    if (comparer == null)
        throw new ArgumentException($"Failed to get default comparer for type '{typeof(T).FullName}'.");

    var isMinGreaterThanMax = comparer.Compare(min, max) > 0;

    if (isMinGreaterThanMax)
    {
        throw new ArgumentOutOfRangeException(
            nameof(min),
            "Minimum value cannot be larger than maximum value.");
    }

    var isValueLessThanMin = comparer.Compare(value, min) < 0;
    var isValueGreaterThanMax = !isValueLessThanMin && comparer.Compare(value, max) > 0;

    return isValueLessThanMin ? min : (isValueGreaterThanMax ? max : value);
}

The previous post shows examples on how to use attributes to set SEO-specific values for Controller-Actions and in Views, which is also used in ASP.NET Core MVC. What is new to Core MVC is how you register the SEO-helper as a Service for Dependency Injection and use Tag Helpers instead of HTML Helpers.

To register the SEO-helper as a service for Dependency Injection you just need to use the framework's provided extension-method in the ConfigureServices-method inside Startup.cs:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddMvc();

        services.AddSeoHelper();
    }
}

These SEO-values can easily be accessed and rendered as HTML-tags inside Views through provided Tag Helpers:

<head>
    <seo-title />

    <seo-link-canonical />
    <seo-meta-description />
    <seo-meta-keywords />
    <seo-meta-robots-index />
</head>

To access these Tag Helpers you need to reference them in you _ViewImports.cshtml:

@addTagHelper *, AspNetSeo.CoreMvc
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

See the README-file on GitHub for the latest detailed information about this ASP.NET SEO-framework. Or try it out through Nuget by running Install-Package AspNetSeo.CoreMvc or Install-Package AspNetSeo.Mvc in your project. You can even follow the absolutely latest build on MyGet.

For any serious web-application you should always implement a solid Search engine optimization-strategy, but there is no standardized way to handle this in ASP.NET MVC, out of the box.

You could easily use the ViewBag-object to send dynamic values from Controller-Actions into Views, like this, for example:

public ActionResult Index()
{
    this.ViewBag.PageTitle = "This is the page title";

    return this.View();
}

Then you'd have to make sure you correctly spell or copy-paste ViewBag.PageTitle correctly into your View:

<head>
    <title>@ViewBag.PageTitle</title>
    <!-- More head-values -->
</head>

One problem is that if you refactor the naming for ViewBag.PageTitle into, for example ViewBag.Title, this will break the functionality, potentially website-wide, because you won't get any tooling-help from Visual Studio for that rename.

This is why I created a framework for ASP.NET MVC SEO, to get structured and reusable functionality around the SEO-data for a web-application. The framework is available on Nuget, with the source-code on GitHub.

Setting SEO-values

You can set SEO-values using the properties on a SeoHelper-object in Controller-Actions and Views, or you can use ActionFilter-attributes in Controllers, to set SEO-related data like:

• Meta-Description
• Meta-Keywords
• Title, split on page-title and base-title (website-title)
• Canonical Link
• Meta No-index for robots

This can be done inside Controllers and Controller-Actions:

[SeoBaseTitle("Website name")]
public class InfoController : SeoController
{
    [SeoTitle("Listing items")]
    [SeoMetaDescription("List of the company's product-items")]
    public ActionResult List()
    {
        var list = this.GetList();

        if (list.Any())
        {
            this.Seo.Title += $" (Total: {list.Count})";
            this.Seo.LinkCanonical = "~/pages/list.html";
        }
        else
        {
            this.Seo.MetaRobotsNoIndex = true;
        }

        return this.View(model);
    }
}

If you don't want to inherit from SeoController to get access to the this.Seo-property, you can use the extension-method GetSeoHelper:

public class InfoController : Controller
{
    public ActionResult List()
    {
        var seo = this.GetSeoHelper();

        seo.Title = "Page title";

        return this.View(model);
    }
}

You can even set SEO-values inside Views:

@{
    this.Layout = null;
    this.Seo.MetaRobotsNoIndex = true; // Always block Robots from indexing this View
}

Rendering SEO-values

These SEO-values can easily be accessed and rendered as HTML-tags inside Views through provided HtmlHelper-extensions:

<head>
    @Html.SeoTitle()

    @Html.SeoLinkCanonical()
    @Html.SeoMetaDescription()
    @Html.SeoMetaKeywords()
    @Html.SeoMetaRobotsIndex()
</head>

See the README-file on GitHub for the latest detailed information about this ASP.NET MVC SEO-framework. Or try it out through Nuget by running Install-Package AspNetSeo.Mvc in your project. You can even follow the absolutely latest build on MyGet.

For example, you might want 2016-03-07 14:35 UTC to show as 2016-03-07 15:35 for a visitor from a CET-timezone.

If you want to dynamically show the local date and time you can use the web-client's information through JavaScript and format it with Moment.js, for any user, anywhere in the world.

To do this in a way that is fault-tolerant and also SEO-friendly I want the UTC-DateTime to be hard-coded in the HTML and let Moment.js format it on the fly, when the page loads. To do this I need to populate my .cshtml-file with the following:

<span class="local-datetime"
        title="@(Model.DateUtc.ToString("yyyy-MM-dd HH:mm")) UTC"
        data-utc="@(Model.DateUtc.GetEpochTicks())">
    @(Model.DateUtc.ToString("yyyy-MM-dd HH:mm")) UTC
</span>

Make sure you run .ToUniversalTime() on your DateTime first.

Notice the .GetEpochTicks()-extension method. It makes sure the format of the DateTime is passed in a format that Moment.js can handle easily. The implementation looks like this:

private static readonly DateTime Epoch = new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc);

public static double GetEpochTicks(this DateTime dateTime)
{
    return dateTime.Subtract(Epoch).TotalMilliseconds;
}

The last step is to tell Moment.js to format our DateTime to a local format:

$('.local-datetime').each(function() {
    var $this = $(this), utcDate = parseInt($this.attr('data-utc'), 10) || 0;

    if (!utcDate) {
        return;
    }

    var local = moment.utc(utcDate).local();
    var formattedDate = local.format('YYYY-MM-DD HH:mm');
    $this.text(formattedDate);
});

If this (or other, unrelated) JavaScript-code would fail for any reason the UTC-DateTime is the actually HTML-content and will still be displayed.

Have you ever written a very usable Route-constraint in ASP.NET MVC or in WebAPI than you wanted to share between them both? For example a constraint that supports nullable Guids (Guid?) as route-parameter.

This can be done by implementing both System.Web.Routing.IRouteConstraint and System.Web.Http.Routing.IHttpRouteConstraint.

Hopefully this article will be obsolete with the release of ASP.NET 5, but until then, here's how you solve this problem:

public class NullableGuidConstraint : IRouteConstraint, IHttpRouteConstraint
{
    // ASP.NET MVC-signature
    public bool Match(
        HttpContextBase httpContext,
        Route route,
        string parameterName,
        RouteValueDictionary values,
        RouteDirection routeDirection)
    {
        return MatchInternal(parameterName, values);
    }

    // WebAPI-signature
    public bool Match(
        HttpRequestMessage request,
        IHttpRoute route,
        string parameterName,
        IDictionary values,
        HttpRouteDirection routeDirection)
    {
        return MatchInternal(parameterName, values);
    }

    private static bool MatchInternal(string parameterName, IDictionary values)
    {
        object value;
        if (!values.TryGetValue(parameterName, out value))
        {
            return false;
        }

        if (value is Guid)
        {
            return true;
        }

        string stringValue = Convert.ToString(value, CultureInfo.InvariantCulture);

        Guid guid;
        bool isMatch = string.IsNullOrWhiteSpace(stringValue) || Guid.TryParse(stringValue, out guid);
        return isMatch;
    }
}

Then you register this constraint through, for example, DefaultInlineConstraintResolver in System.Web.Mvc.Routing for ASP.NET MVC and System.Web.Http.Routing for WebAPI.

var constraintResolver = new DefaultInlineConstraintResolver();
constraintResolver.ConstraintMap.Add("guid?", typeof(NullableGuidConstraint));

// ASP.NET MVC
routes.MapMvcAttributeRoutes(constraintResolver);

// WebAPI
routes.MapHttpAttributeRoutes(constraintResolver);

Now you can write attribute-routes like this:

[Route("{controller}/{action}/{id=guid?}")]

I use the profile-file for Current User in the console located here:

%UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1

When you've ensured that this file is created you can enter PowerShell-scripts that will run every time you open your PowerShell-console. Ensure that your execution policy is configured to support this:

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

For example you can create a PowerShell-alias for the git-command to work with just using g instead:

set-alias g git

Now I can just type g status and save many, many seconds and key-strokes during a long week of Git-usage.

// Write the content of a control inside a view:
Html.RenderPartial("~/Controls/ControlVirtualPath.ascx");

// Or to get the content of a control as a MvcHtmlString, for further manipulation:
Html.Partial("~/Controls/CustomControl.ascx")

It's important that your controls inherits from System.Web.Mvc.ViewUserControl and NOT the old System.Web.UI.UserControl.

One performance-tip that is often mentioned around ASP.NET MVC is to deactivate the WebForms-View Engine for MVC Razor-views (which actually turns out to maybe not make such a big difference after all). This will not prevent .aspx, .ascx and other WebForms-files from working.

But you still want your .ascx-files to work inline in your MVC Razor-views. This can be achieved by implementing your own class that inherits RazorViewEngine, which only uses the WebFormViewEngine when actually needed.

Global.asax (or other config-class)

// Remove WebFormViewEngine (and RazorViewEngine)
ViewEngines.Engines.Clear();
ViewEngines.Engines.Add(new CustomRazorViewEngine());

CustomRazorViewEngine : System.Web.Mvc.RazorViewEngine

private static readonly WebFormViewEngine WebFormsEngine = new WebFormViewEngine();

public override ViewEngineResult FindPartialView(
    ControllerContext context, string name, bool useCache)
{
    if (name.EndsWith(".ascx"))
    {
        return WebFormsEngine.FindPartialView(context, name, useCache);
    }

    return base.FindPartialView(context, name, useCache);
}

If you need the actual class of the control to do some further analysis/manipulation, you can do the following anywhere in your code:

var viewPage = new ViewPage();
var control = viewPage.LoadControl("~/Controls/ControlVirtualPath.ascx") as ControlType;

To be able to serialize an object containing a property of a type inheriting from IHtmlString, like HtmlString and MvcHtmlString, to then, for instance, cache the serialized object, you need to implement your own Newtonsoft.Json.JsonConverter that handles the serialization and deserialization.

HtmlStringConverter : Newtonsoft.Json.JsonConverter

public override bool CanConvert(Type objectType)
{
    return typeof(IHtmlString).IsAssignableFrom(objectType);
}

public override object ReadJson(
    JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
    var value = reader.Value as string;
    // Specifically MvcHtmlString
    if (objectType == typeof(MvcHtmlString))
    {
        return new MvcHtmlString(value);
    }
    // Generally HtmlString
    if (objectType == typeof(HtmlString))
    {
        return new HtmlString(value);
    }

    // Fallback for other (future?) implementations of IHtmlString
    return Activator.CreateInstance(objectType, value);
}

public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
{
    var htmlString = value as HtmlString;
    if (htmlString == null)
    {
        return;
    }

    writer.WriteValue(htmlString.ToString());
}

You then have to register this Converter in your JsonSerializerSettings like this:

CurrentConverter.Converters.Add(new HtmlStringConverter());

In the following URL you very specifically can see an ID-value and a potential Category-value.

http://test.com/products/details.aspx?id=123&category=tea-cups

So you probably want to use Regex and point out named groups in above URL.

^(?:.*)\/?products\/details\.aspx\?id=(?<id>[\d]*)(&category=(?<category>[^&]*))?

Then you want to get those named values into a RouteValueDictionary, with above named Keys, like <id> and <category> with the Regex-matched Values in the URL. You can then, for example, send it to a UrlHelper. This is what the following method does:

public static RouteValueDictionary GetRegexRouteValues(string url, string urlPattern)
{
    if (url == null)
    {
        throw new ArgumentNullException("url");
    }
    if (urlPattern == null)
    {
        throw new ArgumentNullException("urlPattern");
    }

    var regex = new Regex(urlPattern);
    var match = regex.Match(url);
    if (!match.Success)
    {
        return null;
    }

    var namedGroupNames = regex.GetGroupNames().Where(x => x != null && !Regex.IsMatch(x, @"^[0-9]+$"));
    var groups = (from groupName in namedGroupNames
                  let groupItem = match.Groups[groupName]
                  where groupItem != null
                  select new KeyValuePair<string, string>(groupName, groupItem.Value)).ToList();

    var routeValues = new RouteValueDictionary();
    groups.ForEach(x => routeValues.Add(x.Key, x.Value));

    return routeValues;
}

Now you can write code that is more easy to read and maintain to redirect specific URLs:

private static void RedirectProductDetails(string requestUrl) {
    string urlRegex = @"^(?:.*)\/?products\/details\.aspx\?id=(?<id>[\d]*)(&category=(?<category>[^&]*))?";
    var routeValues = GetRegexRouteValues(requestUrl, urlRegex);

    routeValues["controller"] = "Products";
    routeValues["action"] = "Details";
    return this.Url.RouteUrl(routeValues);
}

ViewSource is an app for viewing the HTML-source of any website from your web-browser. Which enables you to view source from mobile browsers.

Just enter any URL and view the HTML-source. You also get a list of CSS-files and JavaScript-files, which you can view the source of, instantly in your browser.

You can quickly reach the app through bit.ly/vsource.

Fork on GitHub

As always, the source is available on GitHub for forking.

Following some SEO best-practices that tells us to use trailing slashes on our URLs I used the IIS Manager and added the IIS URL Rewrite-module's built-in rule "Append or remove the trailing slash symbol", which creates the following rule:

 <rule name="Add trailing slash" stopProcessing="true">
  <match url="(.*[^/])$" />
  <conditions>
    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
  </conditions>
  <action type="Redirect" redirectType="Permanent" url="{R:1}/" />
</rule>

This rule takes into account and doesn't apply the rule to files and directories that exists on disk. But there is a big problem with this generic rule.

If you are dynamically serving up files with extensions, then an URL like:

http://website.com/about.html

will become:

http://website.com/about.html/

Adding conditions for specific file-endings

To solve this you can add conditions for certain file-endings, like .html and .aspx:

<conditions>
  <!-- ... -->
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.html$" negate="true" />
  <add input="{REQUEST_FILENAME}" pattern="(.*?)\.aspx$" negate="true" />
</conditions>

Since the rules above already don't apply for files physically on disk, you don't need to add file-endings like .css, .png or .js.

Update: Match ANY file-ending

If you want to match just any file-ending at all, you use the following pattern:

<conditions>
  <!-- ... -->
  <add input="{URL}" pattern=".*/[^.]*\.[\d\w]+$" negate="true" />
</conditions>

Files in project

Create a file named Web.Base.config, besides the existing Web.Debug.config and Web.Release.config. This file will be the equivalent to your old Web.config, as it will be the base for the tranformation. You will end up with these files:

• Web.config
• Web.Base.config
• Web.Debug.config
• Web.Release.config

Web.config

Add the following configuration to the bottom of your .csproj-file, just before the closing </Project>-tag:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets" />
<Target Name="BeforeBuild">
    <TransformXml Source="Web.Base.config" Transform="Web.$(Configuration).config" Destination="Web.config" />
</Target>

UPDATE: From a reminder in the comments I realized that I also have a problem with Visual Studio transforming the XML twice, when Publishing a project. The solution to this is to add a Condition to the Target-tag like this:

<Target Name="BeforeBuild" Condition="'$(PublishProfileName)' == '' And '$(WebPublishProfileFile)' == ''">

You can now build, run your project or publish it all depending on what Solution Configuration you have selected. Debug or Release. Just press your CTRL+SHIFT+B and see the Web.config-file be transformed.

Version control

I recommend that you leave Web.config out of your Version Control. This solution for transforming the Web.config on the fly would mean that this specific file would constantly be modified and if one person is working with Debug and another person is working with Release the Web.config would probably get big changes constantly.

Testing-tool

The people over at elmah.io has created the Web.config Transformation Tester, where you can try out what the result will be of combining a Web.config-file with a transformation.

The tool can even show you what the diff from the original file is when the transformation is applied.

string currentAction =
    ViewContext.Controller.ValueProvider.GetValue("action").RawValue.ToString();
string currentController =
    ViewContext.Controller.ValueProvider.GetValue("controller").RawValue).ToString();

Then you can do customization code like this in your _Layout.cshtml-file.

bool isIndexPage = currentAction.Equals("index", StringComparison.InvariantCultureIgnoreCase)
    && currentController.Equals("blog", StringComparison.InvariantCultureIgnoreCase);

Disclaimer: Of course this breaks the fundamental rules of separation of concerns in MVC, between the View and the Controller, but sometimes you just don't want, or can, pass around sufficient data between the View and the Controller.

The accepted answer had about 72 lines of code. One explanation for this could be that I did specify that I wanted the solution to implement IFormatProvider. Not sure why I did that, probably seemed right at the time, in the end of 2008.

One creative solution was to use a Win32 API call to StrFormatByteSizeA

[DllImport("Shlwapi.dll", CharSet = CharSet.Auto)]
    public static extern long StrFormatByteSize(long fileSize, [MarshalAs(UnmanagedType.LPTStr)] StringBuilder buffer, int bufferSize);

Compact, clean, cross-platform solution

For the sake of simplicity, readability and the bonus of cross-platform I re-implemented an earlier solution I found, that was written in JavaScript. But the solution was easily translateble into C#.

public static class FileSizeHelper
{
    private static readonly string[] Units = { "B", "KB", "MB", "GB", "TB", "PB", "EB", "ZB", "YB" };

    private static string GetReadableFileSize(long size) // Size in bytes
    {
        int unitIndex = 0;
        while (size >= 1024)
        {
            size /= 1024;
            ++unitIndex;
        }

        string unit = Units[unitIndex];
        return string.Format("{0:0.#} {1}", size, unit);
    }
}

string ftpPath = string.Format("ftp://{0}/{1}", urlOrIpNumber, filePath);
FtpWebRequest request = (FtpWebRequest)WebRequest.Create(ftpPath);
request.Method = WebRequestMethods.Ftp.UploadFile;
request.Credentials = new NetworkCredential (userName, password);

byte[] fileContents = GetFileContent();
request.ContentLength = fileContents.Length;

using(var requestStream = request.GetRequestStream())
{
    requestStream.Write(fileContents, 0, fileContents.Length);
    requestStream.Close();
}

All you need to do is reference the System.Net namespace.

Update: Shorter code version

This code comes from Mads Kristensen, written in the middle of 2006.

private static void Upload(string ftpServer, string userName, string password, string filename)
{
   using (var client = new WebClient())
   {
      client.Credentials = new NetworkCredential(userName, password);
      client.UploadFile(ftpServer + "/" + new FileInfo(filename).Name, "STOR", filename);
   }
}

I'm not sure if there are any scenarios that this code doesn't work with.

The application is an ASP.NET MVC-app, using Justin Etheredge's framework for minification called SquishIt. The app also uses ASP.NET Web API together with some simple jQuery to display the results of the minifications without any page-reloads.

The SquishIt-framework is a very easy to use and provides multiple minifiers for both JavaScript and CSS.

JavaScript minifiers:

• Google Closure*
• Douglas Crockford's JsMin
• Microsoft Ajax Minifier
• Yahoo's YUI Compressor

* At the moment of writing this post, Google Closure is not working as expected.

CSS minifiers:

• Microsoft Ajax Minifier
• Yahoo's YUI Compressor

Enjoy it at squishify.apphb.com and fork it on GitHub.

App-relative URLs automatically resolved

In Razor v1 your views would be littered with code like this:

<script src\="@Url.Content("~/content/scripts.js")"\></script>

But in Razor v2 you can shorten it with a tilde in front of the URL, which was used a lot in WebForms:

<script src\="~/content/scripts.js"\></script>

This will work for any HTML-attribute that starts with the title-sign.

Conditional attributes hides null-valued attributes

Razor v1 treated null-valued attributes as empty string, writing out attributes empty values. Razor v2 will instead skip even writing out the attribute that has a null value:

@{ string itemId \= string.Empty; string itemClass \= "class-of-item"; string itemValue \= null; } <div id\="@itemId" class\="@itemClass @itemValue" rel\="@itemValue"\></div\>

Will result in this HTML:

<div id\="" class\="class-of-item"\></div>

Note that string.Empty still makes Razor v2 to write out the attribute. Any data-attribute will ignore this rule and always write out the attribute.

Support for unclosed HTML-tags

The HTML5-specs clearly states that unclosed HTML-tags are supported, but Razor v1 didn't have an advanced enough parser to support this. Razor v2 now supports this with the elements listed in W3C's spec.

What else?

There has been some major improvements on how the syntax-trees are structured and other deep functionality in the language. The focus was internal clean-up and future-proofing.

From those needs I took some evening hours to build DevSum Scheduler. It's a web-app that allows you to highlight which talks you're going to attend.

The app uses HTML Agility Pack to get the data from DevSum's own website and then ASP.NET MVC Razor to display the content properly. To store this I've used HTML 5 LocalStorage to persist the choices made.

There are many other technologies used, which are listed on the about-page. Since the website is suppose to help the attendees by being available on their smart-phones, I've used CSS Media Queries for mobile layout and Modernizr for feature-detection in the web-browser.

Check out the full source-code on GitHub. Again, the outstanding AppHarbour has been used to quickly get the app on the Internet (through a GitHub-service hook of course).

This time the solution to the problem are actually listed in those release-notes. You need to the explicitly state the version-numbers of the references in your web.config.

Add a new appSettings-entry for explicitly stating the version of WebPages to use:

<appSettings> <add key\="webpages:Version" value\="1.0.0.0"/> <!-- ... --> </appSettings>

Then you have to edit your .csproj-file, where you need to find your references to System.Web.WebPages and System.Web.Helpers and makes sure they have the explicit version-numbers like this:

<Reference Include\="System.Web.WebPages, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"/> <Reference Include\="System.Web.Helpers, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Hopefully this will be resolved in the final version of MVC 4 or maybe the case is that the references to versions in Razor v1 were just too loose in MVC 3-projects.

GitHub allows you to directly deploy to AppHarbor on checkin/push to the Git-repository, which is a very powerful and useful feature, to quickly get your ASP.NET web-apps online in the cloud.

It started out with a need to encode strings for HTML and developed into a quick test of how Web API on MVC 4 works in an AJAX-enabled web-app.

Try it out at http://htmlencoder.apphb.com and fork it on GitHub.

Sections - Replacement for asp:ContentPlaceHolder and asp:Content

Where you the old WebForms view-engine used to use the controls and to dynamically switch out parts of the content on a page, the Razor view-engine uses sections.

_Layout.cshtml (Equivalent to a .master-page):

<div>Template content</div>
@RenderBody()
<div>More template content</div>
@RenderSection("OtherContent", required: false)

Page.cshtml:

@section OtherContent {
    <span>Other content goes here</span>
}
<div>Main page-content</div>

In above code the RenderSection-method in the _Layout.cshtml renders the content within the matching @section in the Page.cshtml. The required-parameter indicates if the section is required and should throw an exception if the section doesn't exist. The RenderBody-method renders the rest of the content in the Page.cshtml, which is not inside any section.

Declaring the ViewModel

In the old WebForms view-engine your declaration of the view-model would look like something like this:

<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
    Inherits="System.Web.Mvc.ViewPage<MyViewModel>" %>

While in the Razor view-engine declaring your view-model is as easy as this:

@model MyViewModel

Inline C#-code in the HTML

If you wanted to loop over a collection in your view-model in WebForms view-engine your code would look something like this:

<% foreach(var item in Model.Items) { %>
    <% if(item.IsValid()) { %>
        <div class="<%: item.ClassName %>">&;lt;%: item.Title %></div>
    <% } %>
<% } %>

The percent-tags make it a bit hard to quickly get an overview of what is HTML and what is code. This is one of the largest upsides to the Razor view-engine, where the same code would be written much more readable like this:

@foreach(var item in Model.Items) {
    if(item.IsValid())
    {
        <div class="@item.ClassName">@item.Title</div>
    }
}

If you make a proper installation of MVC 3 you will get syntax-highlighting in Visual Studio for separating C#-code and HTML-tags.

Advanced inline C#-code

Razor is extremely intelligent when it comes to determining when code starts and ends behind the @-signs, which is very well visualized by the IntelliSense in Visual Studio.

<div>This is @Model.Name's page</div>

Since the apostrophe doesn't follow any pattern that could make it correct C#-code, Razor knows to cut the code from there.

If you want to be extra clear in your code, against other developers, but also against Razor, as to where the code starts and ends, you can use parentheses like this:

<div>This is @(Model.Name)'s page and has the status "@(Model.Status)"!</div>

Inline C#-code for logic

You can include code on the page that is not necessarily written out on the page directly, but handles logic and page-specific functionality. For this you use the @-sign, followed by curly braces.

<div>Other content</div>
@{
    string capitalizedTitle = Model.Title.ToUpper();
}
<h1>Page about @capitalizedTitle</h1>

This is used in the templates that comes with MVC 3 to set which Layout-file to use. But you can use this on your own for setting the title-text in the title-tag.

Page.cshtml:

@{  
    ViewBag.Title = "Index titel - " + Model.SubTitle;
}

\_Layout.cshtml:

<head>
    <title>@ViewBag.Title</title>
    <!-- ... -->

Helpers - Reusing code specific to view-template

With the new @helper-syntax in Razor you can easily write re-usable methods that deals with output-functionality within view-templates.

@helper ShowInfo(string name, bool hasContent) {
    if(hasContent) {
        <div>This is info about @name.ToUpper()</div>
    }
}

Namespaces

Using a namespace is very easy and reminds us a lot of the old way to do it:

@namespace System.ComponentModel.DataAnnotations

Server-side comments

To do server-side comments with Razor you can click the "Comment" toolbar button or press Ctrl+K, Ctrl+C to apply a server-side comment. The commented code is place between a @* and a *@ and looks like this:

@" This is the text of the model. MUST be HTML-encoded. "@
<div class="special-elemet">@Model.Text</div>

Global settings for view-templates

If you place a file named _ViewStart.cshtml in the root of the ~/Views-folder, the Razor-code in this code will be applied as default to all view-templates in the sub-folders. In the templates that comes with MVC 3 this is used to set the default Layout-file to be used for the view-templates.

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

Not HTML-encoding content

In the old WebForms view-engine you could use a colon-character instead of an equals-sign to HTML-encode content like this:

<%= ContentToBeOutputWithoutEncoding %>  
<%: ContentToBeEncoded %>

The Razor view-engine automatically HTML-encodes whatever strings you output without explicitly using Html.Raw-method like this:

@Html.Raw(ContentToBeOutputWithoutEncoding)

The <text>-tag for Razor

The way Razor analyzes the code to find the start and end only makes it it possible to have one element (with multiple children of course) inside an expression. To resolve this Razor introduces a <text>-tag, where you can nest multiple lines of code:

<text>
    <div>One nested item</div>
    <span>Another nested item</span>
</text>

It's a jQuery-plugin that easily allows the user to add one or more Google Maps-maps with markers and info-windows to the website.

It uses a simple object-literal as an argument for configuration when calling. To add a map to a div-tag with and ID, simple use the following code:

$('#map-placeholder').jMapMarkers({
    mapOptions: { // Straight Google Maps API-configuration
        zoom: 1,
        mapTypeId: google.maps.MapTypeId.ROADMAP,
        mapTypeControl: false
    },
    markers: [
        { lat: '59.329444', long: '18.068611', title: 'Stockholm', desc: 'Capital of Sweden' },
        { lat: '59.949444', long: '10.756389', title: 'Oslo', desc: 'Capital of Norway' }
    ]
});

You can even add on more markers after the initial map has been added. Just leave out the mapOptions-argument in the configurations-arguments, like this:

$('#map-placeholder').jMapMarkers({
    markers: [
        { lat: 52.500556, long: 13.398889, title: 'Berlin', desc: 'Capital of Germany' },
        { lat: 48.8567, long: 2.3508, title: 'Paris', desc: 'Capital of France' },
        { lat: 51.507222, long: -0.1275, title: 'London', desc: 'Capital of England' }
    ]
});

You can find examples in the demo.html-file in the GitHub-project.

A big bonus-feature is that if you don't state otherwise the plugin will automatically zoom and move the map so that all markers are visible, after markers are added to the map.

As it say in the GitHub-README: please feel free to fork and/or give feedback.

I simply recorded a macro while converting one Word-file into a PDF-file and then Googled for some code to access files on disc and put it all together in a loop.

Sub ConvertWordsToPdfs()

    Dim directory As String    
    directory = "C:\Wordup"
  
    Dim fso, newFile, folder, files
    Set fso = CreateObject("Scripting.FileSystemObject")
    
    Set folder = fso.GetFolder(directory)
    Set files = folder.files
    
    For Each file In files

        Dim newName As String
        newName = Replace(file.Path, ".doc", ".pdf")
                
        Documents.Open FileName:=file.Path, _
            ConfirmConversions:=False, ReadOnly:=False, AddToRecentFiles:=False, _
            PasswordDocument:="", PasswordTemplate:="", Revert:=False, _
            WritePasswordDocument:="", WritePasswordTemplate:="", Format:= _
            wdOpenFormatAuto, XMLTransform:=""
            
        ActiveDocument.ExportAsFixedFormat OutputFileName:=newName, _
            ExportFormat:=wdExportFormatPDF, OpenAfterExport:=False, OptimizeFor:= _
            wdExportOptimizeForPrint, Range:=wdExportAllDocument, From:=1, To:=1, _
            Item:=wdExportDocumentContent, IncludeDocProps:=True, KeepIRM:=True, _
            CreateBookmarks:=wdExportCreateNoBookmarks, DocStructureTags:=True, _
            BitmapMissingFonts:=True, UseISO19005_1:=False
        
        ActiveDocument.Close
      
    Next

End Sub

I guess I won't update or tune this macro a lot, but you can find this macro as a Github Gist as well.

When you include a Google Maps to your website via the Google Maps JavaScript API uses the browser's set preferred language to display the texts. Sometimes this doesn't turned out as planned and you want to be able to override this with your own choice.

Changing language is done with an additional argument when referencing the script-file. The argument used is language.

<script type="text/javascript"
    src="http://maps.google.com/maps/api/js?sensor=false&language=ja">

There is of course a reference to the supported languages and their language codes.

Region Localization

To set the language of the names of the countries, cities and other places, you can use the Region Localization.

Worth noticing in the code is that we handle a key-press on the Enter-button instantly, while otherwise we only execute the functionality after the user left the keyboard alone for 0,5 seconds.

var filterTimeoutId = 0;

var textboxFunction = function() {
   // The function the textbox should perform
};

$('input#TextBox').keypress(function (e) {
    if (e.which === 13) { // Enter-key
        e.preventDefault(); // Prevent page postback
        clearTimeout(filterTimeoutId);

        textboxFunction();
        return;
    }

    clearTimeout(filterTimeoutId);
    var timeout = 500; // Timeout in milliseconds
    filterTimeoutId = setTimeout(textboxFunction, timeout);
});

After the usual searching of Google and Stackoverflow I've put together a combination of different solutions that seems to solve this issue.

• Step 1: Expand your references and bring up the properties-window. Set Specific Version to True:
  
• Step 2: Right click on the project and click Untload Project:
  
• Step 3: Right click again on the project and click Edit ...csproject.
• Step 4: Add an XML-element with the name SpecificVersion with the value True beneath the reference in question:
  
• Step 5: Right click on the project and click Reload Project.

This works for me so far.

After spending almost as much time searching for something already built as it would have taken to build it, I did just that, I took matters into my own hands.

In my case I solved it with Yahoo's YUI 2, but you can do it just as well in any other Javascript-library, like jQuery.

<!-- Static banners above conditional scrolling one -->
<div id="scrollBanner" class="scrollBanner">
<!-- Image and/or flash-banners -->
<img src="Banner.gif" alt="Banner" />
</div>

What we need to do is to find the element to scroll in the DOM and find it's initial Y-position. Then we add a listener to the scroll-event and just flip the CSS-class of the element, depending if we've scrolled past it or not.

var scrollBanner = document.getElementById("scrollBanner");
// Initial banner Y-position
var bannerYPos = YAHOO.util.Dom.getY(scrollBanner);

YAHOO.util.Event.addListener(window, 'scroll',
    function() {
        var isBannerAboveScrollTop = (YAHOO.util.Dom.getDocumentScrollTop() > bannerYPos);
        var oldClassName = isBannerAboveScrollTop ? "scrollBanner" : "scrollBanner_fixed";
        var newClassName = isBannerAboveScrollTop ? "scrollBanner_fixed" : "scrollBanner";
        YAHOO.util.Dom.replaceClass(scrollBanner, oldClassName, newClassName);
    }
);

Just style your scrollingBanner_fixed-class with a fixed position and the width you want it to have. Adjust the top-setting to set how high up on the screen the scrolling banner should be. You could also use padding to make the scrolling-experience more smooth.

.scrollingBanner_fixed {
    position: fixed;
    top: 0px;
    width: 100px;
}

This code could of course also be used for good, to have some kind of toolbar that would scroll along on a page.

Clean URIs are one component of a clean website, and it is an important one. The majority of end-user access to the Internet involves a URI, and whether or not the user actually enters the URI, they are working with one nonetheless.

Here is an outtake of the general principles of the article:

• A URI must represent an object, uniquely and permanently - The URI must be unique so that it is a one-to-one match – one URI per one data object.
• Be as human-friendly as possible - URIs should be designed with the end user in mind. SEO and ease of development should come second.
• Consistency - URIs across a site must be consistent in format. Once you pick your URI structure, be consistent and follow it!
• “Hackable” URIs - Related to consistency, URIs should be structured so that they are intelligibly “hackable” or changeable.
• Keywords - The URI should be composed of keywords that are important to the content of the page. So, if the URI is for a blog post that has a long title, only the words important to the content of the page should be in the URI.

When it comes to technical details, here are their concerned bullet-points:

• No WWW - The www. should be dropped from the website URI, as it is unnecessary typing and violates the rules of being as human-friendly as possible and not including unnecessary information in the URI.
• Format - Google News has some interesting requirements for webpages that want to be listed in the Google News results – Google requires at least a 3-digit unique number.
• All lowercase - All characters must be lowercase. Attempting to describe a URI to someone when mixed case is involved is next to impossible.
• URI identifiers should be made URI friendly - A URI might contain the title of a post, and that title might contain characters that are not URI-friendly. That post title must therefore be made URI friendly. [...] Spaces should be replaced with hyphens.

Scott Mitchell has written an article on 4GuysFromRolla.com about Techniques for Preventing Duplicate URLs in Your Website.

A key tenet of search engine optimization is URL normalization, or URL canonicalization. URL normalization is the process of eliminating duplicate URLs in your website. This article explores four different ways to implement URL normalization in your ASP.NET website.

The important subjects of this article are the following:

• First Things First: Deciding on a Canonical URL Format - Before we examine techniques for normalizing URLs, and certainly before such techniques can be implemented, we must first decide on a canonical URL format.
• URL Normalization Using Permanent Redirects - [...] when a search engine spider receives a 301 status it updates its index with the new URL. Therefore, if anytime a request comes in for a non-canonical URL we immediately issue a permanent redirect to the same page but use the canonical form then a search engine spider crawling our site will only maintain the canonical form in its index.
• Issuing Permanent Redirects From ASP.NET - Every time an incoming request is handled by the ASP.NET engine, it raises the BeginRequest event. You can execute code in response to this event by creating an HTTP Module or by creating the Application_BeginRequest event handler in Global.asax.
• Rewriting URLs Into Canonical Form Using IIS 7's URL Rewrite Module - Shortly after releasing IIS 7, Microsoft created and released a free URL Rewrite Module. The URL Rewrite Module makes it easy to define URL rewriting rules in your Web.config file.
• Rewriting URLs Into Canonical Form Using ISAPI_Rewrite - Microsoft's URL Rewriter Module is a great choice if you are using IIS 7, but if you are using previous version of IIS you're out of luck.
• Telling Search Engine Spiders Your Canonical Form In Markup - Consider a URL that may include querystring parameters that don't affect the content rendered on the page or only affect non-essential parts of the page.
  In the case of YouTube, all video pages specify a <link> element like so, regardless of whether the querystring includes just the videoId or the videoId and other parameters:

<link rel\="canonical" href\="/watch?v=videoId"\>

All the code in this article should be put in a class inheriting from System.Web.UI.Page. Like a page's Code-behind file or your own PageBase-class.

First we need some common logic for both loading and saving a compressed View State, the name of the hidden field to use.

private const string ViewStateFieldName = "SEOVIEWSTATE";

We start with the loading-part, where you see the use of my implementation of the CompressionHelper-class, which simplifies compression. It also solves the issue with DeflateStream and GZipStream inflating already compressed data, which is resolved in .NET Framework 4.

protected override object LoadPageStateFromPersistenceMedium() {
    return LoadCompressedPageState();
}

private object LoadCompressedPageState() {
    string viewState = Request.Form[ViewStateFieldName];
    if(string.IsNullOrEmpty(viewState)) {
        return string.Empty;
    }

    byte[] bytes = Convert.FromBase64String(viewState.Substring(1));

    bool isCompressed = Convert.ToBoolean(Convert.ToInt32(viewState.Substring(0, 1)));
    if(isCompressed) {
        bytes = CompressionHelper.Decompress(bytes);
    }

    string decompressedBase64 = Convert.ToBase64String(bytes);

    ObjectStateFormatter formatter = new ObjectStateFormatter();
    return formatter.Deserialize(decompressedBase64);
}

We then move on to the implementation of saving the page's state.

protected override void SavePageStateToPersistenceMedium(object state) {
    SaveCompressedPageState(state);
}

private void SaveCompressedPageState(object state) {
    byte[] viewStateBytes;
    using(MemoryStream stream = new MemoryStream()) {
        ObjectStateFormatter formatter = new ObjectStateFormatter();
        formatter.Serialize(stream, state);
        viewStateBytes = stream.ToArray();
    }

    byte[] compressed;
    bool successfulCompress = CompressionHelper.TryCompress(viewStateBytes, out compressed);
    string compressedBase64 =
        Convert.ToInt32(successfulCompress) + Convert.ToBase64String(compressed);

    ClientScript.RegisterHiddenField(ViewStateFieldName, compressedBase64);
}

So the summary is that this will compress the View State of an ASP.NET WebForms page, if the View State is large enough. Otherwise it will just keep it the way it is.

Since Google and other search-engines only indexes X amount of KB of a page, you don't want half of that content to be meaningless View State (which you should TRULY understand by now).

One solution is to compress the View State, but in this article I will show you how to move it to the bottom of the Form-tag. To achieve the latter, I will use a HttpModule, which will intercept all requests to files served through ASP.NET in the IIS.

First we need to hook in to the BeginRequest-event to only intercept requests to .aspx-pages.

public class ViewStateSeoHttpModule : IHttpModule {
    public void Init(HttpApplication context) {
        context.BeginRequest += new EventHandler(BeginRequest);
    }

    private void BeginRequest(object sender, EventArgs e) {
        HttpApplication application = sender as HttpApplication;

        bool isAspNetPageRequest = GetIsAspNetPageRequest(application);
        if(isAspNetPageRequest) {
            application.Context.Response.Filter =
                new ViewStateSeoFilter(application.Context.Response.Filter);
        }
    }

    private bool GetIsAspNetPageRequest(HttpApplication application) {
        string requestInfo = application.Context.Request.Url.Segments.Last();
        bool isAspNetPageRequest = requestInfo.ToLowerInvariant().Contains(".aspx");
        return isAspNetPageRequest;
    }
    // [...]

What we do here is add a Reponse Filter which moves the View State to the bottom of the Form. I made this to an internal class called ViewStateSeoFilter.

internal class ViewStateSeoFilter : Stream {
    private string _topPageHiddenFields;
    private Stream _originalFilter;

    public ViewStateSeoFilter(Stream originalFilter) {
        _originalFilter = originalFilter;
    }

    public override bool CanRead { get { return true; } }
    public override bool CanSeek { get { return true; } }
    public override bool CanWrite { get { return true; } }
    public override long Length { get { return 0; } }
    public override long Position { get; set; }

    public override void Flush() {
        _originalFilter.Flush();
    }

    public override int Read(byte[] buffer, int offset, int count) {
        return _originalFilter.Read(buffer, offset, count);
    }

    public override long Seek(long offset, SeekOrigin origin) {
        return _originalFilter.Seek(offset, origin);
    }

    public override void SetLength(long value) {
        _originalFilter.SetLength(value);
    }
    public override void Close() {
        _originalFilter.Close();
    }

    public override void Write(byte[] buffer, int offset, int count) {
        byte[] data = new byte[count];
        Buffer.BlockCopy(buffer, offset, data, 0, count);
        string html = Encoding.Default.GetString(buffer);

        html = ExtractPageTopHiddenFields(html);
        html = InsertExtractedHiddenFields(html);

        byte[] outdata = Encoding.Default.GetBytes(html);
        _originalFilter.Write(outdata, 0, outdata.GetLength(0));
    }

    private string ExtractPageTopHiddenFields(string html) {
        int formStartIndex = html.IndexOf("<form");
        if(formStartIndex < 0) {
            return html;
        }

        int divStartOpenIndex = html.IndexOf("<div", formStartIndex);
        if(divStartOpenIndex < 0) {
            return html;
        }
        int divStartCloseIndex = html.IndexOf(">", divStartOpenIndex);
        int divStartLenght = divStartCloseIndex - divStartOpenIndex;
        int divEndOpenIndex = html.IndexOf("</div", divStartOpenIndex);
        int divEndCloseIndex = html.IndexOf(">", divEndOpenIndex);

        int divContentLength = divEndOpenIndex - divStartCloseIndex - 1;

        _topPageHiddenFields = html.Substring(divStartCloseIndex + 1, divContentLength);
        html = html.Remove(divStartOpenIndex, divEndCloseIndex - divStartOpenIndex + 1);
        return html;
    }

    private string InsertExtractedHiddenFields(string html) {
        if(string.IsNullOrEmpty(_topPageHiddenFields)) {
            return html;
        }

        int insertIndex = html.IndexOf("</form>");
        if(insertIndex > 0) {
            html = html.Insert(insertIndex, _topPageHiddenFields + Environment.NewLine);
            _topPageHiddenFields = null;
        }

        return html;
    }
}

One bonus is that it moves all available Hidden Input HTML-tags controlled by ASP.NET to the bottom of the Form-tag. It seems to skip the Hidden Input that handles EventValidation, which is a good thing, because ASP.NET seems to want this tag early in the Page Life Cycle.

I decided to write down and document for myself the different paths provided by ASP.NET, to get a grip on the subject and a reference to turn to.

The path I will be requesting is:
http://www.myurl.com/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue

This will be an ASP.NET-application named MyApplication in the IIS.

Request-reference

Here is the result returned by the Request-property of the page, which is a HttpRequest.

[Request.ApplicationPath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.applicationpath.aspx):
/MyApplication - Gets the ASP.NET application's virtual application root path on the server.

[Request.AppRelativeCurrentExecutionFilePath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.apprelativecurrentexecutionfilepath.aspx):
/MyFolder/MyPage.aspx _- Gets the virtual path of the application root and makes it relative by using the tilde () notation for the application root (as in "~/page.aspx")._

[Request.CurrentExecutionFilePath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.currentexecutionfilepath.aspx):
/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

[Request.FilePath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.filepath.aspx):
/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

[Request.Path](https://msdn.microsoft.com/en-us/library/system.web.httprequest.path.aspx):
/MyApplication/MyFolder/MyPage.aspx - Gets the virtual path of the current request.

[Request.PathInfo](https://msdn.microsoft.com/en-us/library/system.web.httprequest.pathinfo.aspx):
- Gets additional path information for a resource with a URL extension.

[Request.PhysicalApplicationPath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.physicalapplicationpath.aspx):
C:\Visual Studio Projects\MyApplication\ - Gets the physical file system path of the currently executing server application's root directory.

[Request.PhysicalPath](https://msdn.microsoft.com/en-us/library/system.web.httprequest.physicalpath.aspx):
C:\Visual Studio Projects\MyApplication\MyFolder\MyPage.aspx - Gets the physical file system path corresponding to the requested URL.

[Request.RawUrl](https://msdn.microsoft.com/en-us/library/system.web.httprequest.rawurl.aspx):
/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the ASP.NET application's virtual application root path on the server.

Request.Url-reference

Then there is the property [Request.Url](https://msdn.microsoft.com/en-us/library/system.web.httprequest.url.aspx) that returns a [System.Uri](https://msdn.microsoft.com/en-us/library/system.uri_properties.aspx) , with all its properties. This is an interesting thing to explore as well.

[Request.Url.AbsolutePath](https://msdn.microsoft.com/en-us/library/system.uri.absolutepath.aspx):
/MyApplication/MyFolder/MyPage.aspx - Gets the absolute path of the URI.

[Request.Url.AbsoluteUri](https://msdn.microsoft.com/en-us/library/system.uri.absoluteuri.aspx):
http://www.myurl.com/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the absolute URI.

[Request.Url.DnsSafeHost](https://msdn.microsoft.com/en-us/library/system.uri.dnssafehost.aspx):
www.myurl.com - Gets an unescaped host name that is safe to use for DNS resolution.

[Request.Url.Host](https://msdn.microsoft.com/en-us/library/system.uri.host.aspx):
www.myurl.com - Gets the host component of this instance.

[Request.Url.LocalPath](https://msdn.microsoft.com/en-us/library/system.uri.localpath.aspx):
/MyApplication/MyFolder/MyPage.aspx - Gets a local operating-system representation of a file name.

[Request.Url.OriginalString](https://msdn.microsoft.com/en-us/library/system.uri.originalstring.aspx):
http://www.myurl.com:80/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the original URI string that was passed to the Uri constructor.

[Request.Url.PathAndQuery](https://msdn.microsoft.com/en-us/library/system.uri.pathandquery.aspx):
/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets the AbsolutePath and Query properties separated by a question mark (?).

[Request.Url.Query](https://msdn.microsoft.com/en-us/library/system.uri.query.aspx):
?QueryStringKey=QueryStringValue - Gets any query information included in the specified URI.

[Request.Url.ToString()](https://msdn.microsoft.com/en-us/library/system.uri.tostring.aspx):
http://www.myurl.com/MyApplication/MyFolder/MyPage.aspx?QueryStringKey=QueryStringValue - Gets a canonical string representation for the specified Uri instance.

Request also has the property [Request.UrlReferrer](https://msdn.microsoft.com/en-us/library/system.web.httprequest.urlreferrer.aspx) which is of the type System.Uri and has the same properties as Request.Url. It has the following description: Gets information about the URL of the client's previous request that linked to the current URL.

class Program {
    static void f(Int32 x) { }
    static void f(dynamic x) {}
    static void f(Int32 x, dynamic y) {}
    static void f(dynamic x, Int32 y) {}
    static void f(Int32 x, dynamic y, Int32 z) {}
    static void f(dynamic x, Int32 y, dynamic z) {}
    static void Main(string[] args) {
        f(10); // Works - obvious
        f(10, 10); // Ambiguous - obvious
        f(10, 10, 10); // Ambiguous - not so obvious - since it should be possible to resolve
    }
}

...the behavior is totally by design:

• dynamic in method signatures doesn't come into it: it behaves like System.Object does.
• Given that, neither of the ternary signatures is better because each fits better than the other on some arguments (Int32 fits 10 better than object does)

The key point here, in bold, because it's significant is: having the type dynamic means "use my runtime type for binding".

It all becomes very clear when Reflector is used on the code. This loosens up some thought-patterns and makes it easier to really understand the dynamic -keyword.

Another way to look at this is with Reflector. This C# code:

static void f(Int32 x, dynamic y, Int32 z) {}

is essentially this, from a method signature point of view:

static void f(int x, \[Dynamic\] object y, int z) {}

and if there was a method that returned dynamic, it'd look like this:

[return: Dynamic]
private static object GetCalculator() {}

The tool StyleCop is Microsoft's tool for enforcing these guidelines.

StyleCop analyzes C# source code to enforce a set of style and consistency rules. It can be run from inside of Visual Studio or integrated into an MSBuild project.

After asking a question Visual Studio C#-settings and StyleCop (MS Source Analysis) on Stackoverflow I set out to try to get C# in Visual Studio to behave as compliant as possible.

The result after some testing around was this Visual Studio settings file. You can easily import these settings to your own Visual Studio.

It's mainly about placements of parentheses and curly-braces.

Yes, it can be a bit of a hassle to get used to having the curly-braces on the same line as the namespace-declaration, the class-declaration and method-declaration, but it saves some space and I got used to it quiet quickly and now have problems going back.

namespace TestApp {
    public class TestObject {
        static TestObject() {
            if(true) {
                DoSomething();
                DoSomething2();
            } else {
                DoSomethingElse()
            }
        }
    }
}

This is as close as I can get to the conventions. It's worth to note that StyleCop can differ a bit from the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries .