DEV Community: masters.🤔

Verifying Assembly Redirects Before Runtime

masters.🤔 — Tue, 06 Oct 2020 21:41:55 +0000

This week's "yak shaving" project was updating a library dependency in across several large .NET solutions in a monorepo. It took about as long as we expected, but not for the reasons we expected - this is a tale about assembly binding redirects.

The library (Npgsql) was bumped two major versions, from 2.x to 4.x. The primary advantage of the update in our case was added .NET Core support, allowing us to incrementally port services in this monorepo over to .NET Core.

Our dependency structure looks like this:

- Npgsql
  - SharedBusinessLogic
    - Web UI layer
    - Some async services that generate reports
    - An unrelated UI project that doesn't use Npgsql directly

There were a few database queries that broke but overall the update seemed to go fine, tests were passing locally and on CI.

However, after merging and deploying the branch to one of our test environments, one of our projects started throwing errors on certain routes:

What happened?

An updated graph of dependencies after the update:

- System.Runtime.CompilerServices.Unsafe
- System.Numerics.Vectors
- System.Memory
- System.Threading.Tasks.Extensions
  - Npgsql
    - SharedBusinessLogic
      - Web UI layer
      - Some async services that generate reports
      - An unrelated UI project that doesn't use Npgsql directly

The Npgsql dependency now targets netstandard, which means we can reference it via .NET Core and .NET Framework (legacy) without compatibility hacks. However, to accomplish this, some of the dependencies that were previously referenced in the installed .NET runtime are now referenced via NuGet packages. By convention, most of these are prefixed System. in the dependency list.

However, some of our other app dependencies already had references to these System. assemblies, but for different versions.

Confused? Let's talk a bit about how this works.

In .NET Core projects assembly binding redirects are not necessary, but many of our projects still run on .NET 4.8, also referred to as .NET Framework, or netfx.

At runtime, the .NET Framework tries to resolve a specific version of any dependencies requested. If the exact version is not present in the bin folder, an assembly binding redirect is required to "force" the runtime to resolve to a specific version, or an exception will be thrown. These binding redirects are specified in a config file and checked at runtime.

For further reading, I recommend Nick Craver's excellent post on binding redirects here.

To complicate matters further, not all assemblies are loaded and checked at application startup. We found that only some of our server-side routes caused the Npgsql assembly to load, so building and running just the home route was not enough.

OK, so we'll update these bindings now that we know that the code crashes. But how can we know about this problem before running every possible route on our web app?

Our first attempt was to use the msbuild /warnaserror flag. With this switch, warnings will be printed for NuGet level restore problems (downgrade warnings), and binding redirects that are mismatched or missing entirely. More information here.

C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2084,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly. 

In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"><dependentAssembly><assemblyIdentity name="System.Memory" culture="neutral" publicKeyToken="cc7b13ffcd2ddd51" /><bindingRedirect oldVersion="0.0.0.0-4.0.1.1" newVersion="4.0.1.1" /></dependentAssembly></assemblyBinding>

In our case, we could not use /warnaserror yet because we wanted to progressively roll out this validation, and additionally:

Alert on binding redirects that are targeting an old version of the library
Warn on outdated redirects for assemblies not present in the bin folder (deleted dependencies)
Run the tool on an entire git repository locally to quickly sanity check repos with multiple solution files
Generate missing bindings without copy-pasting text from msbuild's output

We ended up putting together a Powershell script to handle this. It has no dependencies and has been tested on Powershell 5. Check it out here if you're interested

The basic idea is this:

Find any web.config or app.config files within a folder, recursively
For each resolved config, open the bin folder and load every DLL, building a map of versions and publicKeyTokens
Check to make sure the lists match
If they don't, fail the build
???
Profit

With increased confidence in our build tooling, we can be more proactive about moving shared projects to netstandard, and ultimately ship more projects using .NET Core.

Happy shipping!

The case for Embeddable Ember

masters.🤔 — Mon, 17 Jun 2019 21:22:20 +0000

Photo by Karl Bewick on Unsplash

In this post I'm proposing some improvements for Ember in an important, but often overlooked use case: embedding Ember components in non-Ember applications. Ember is great for brand new web applications. But what story do we tell for existing apps that are looking to transition to Ember?

Consider a single page application that started in 2016 that uses React and webpack. There's already support for pulling in ES modules and rolling them into the production bundle. However, the team has heard about the many tooling improvements to Ember and wants to experiment shipping a small component in this existing React app. However, because the app uses a client-side router, there needs to be a mechanism to load the Ember app and render into a div without resorting to an iframe.

Teams might choose not to adopt Ember because they can't afford a several month feature freeze to port components over. This post aims to solve these pain points so that teams are free to progressively ship Ember components in their apps and migrate the application over time.

Ember applications are built and packaged with the ember-cli tooling. Because the CLI tooling and the framework are deeply integrated, addons can be developed that make modifications to the build process. A few great examples of this are adding type checking with ember-cli-typescript, generating thin wrappers for ES modules with ember-auto-import, or even transforming imports from module syntax import { computed } from '@ember/object' to Ember.computed. One drawback of this tooling, however, is the artifacts it emits are not ideal for embedded scenarios.

Let's consider what embedding an Ember component in a React app could look like:

React component

function ListUsers() {
  const users = [{ id: 1, name: 'masters' }];
  return <UsersWrapper users={users} />;
}

Ember component, invoked from React

<div class="some-app__users">
  {{#each @users as |user|}}
    <div class="some-app__users__id">ID: {{user.id}}</div>
    <div class="some-app__users__id">Name: {{user.name}}</div>
  {{/each}}
</div>

There isn't currently a way to mix Ember components in existing React applications like this. However, if we introduce a simple wrapper component:

import React, { useEffect, useRef } from 'react';
import TinyEmber from 'tiny-ember-app';
import Users from './ember-components/users';

function UsersWrapper(props) {
  const containerRef = useRef();
  // this is invoked when the host component mounts
  useEffect(() => {
    const mountedInstance = TinyEmber.mount(Users, containerRef.current, props);

    // this is called when the host component unmounts
    return () => mountedInstance.destroy();
  }, []);

  return <div ref={containerRef} />;
}

TinyEmber in this example is a fake library that provides a thin API over Ember itself. The mount method takes in a reference to the component to be rendered (which it will handle initializing), a DOM node, and a set of initial component arguments. This is very similar to the design of ReactDOM.render, but also accepts initial component arguments for the root Ember component. Note that these initial component arguments will only be used for the first render of the Ember component - synchronizing state updates between the parent app and the Ember app left as an exercise for the reader (message passing could be used in this case).

The consuming app (React in this case) has a different component model, but it can still seamlessly mount and unmount Ember components and pass data to them. As the new app grows in size, "legacy" components can coexist with newer Ember components, and older components ported over one at a time. Optionally in the future, these old components can be removed entirely, and the transition to fully Ember components is complete.

Embedding Ember applications is already documented, but the current approach has a few limitations.

Hard-coded selector for root node

The selector for the containing element div is specified at build-time, and the emitted output from ember build contains statements to initialize the app and render it on the page as soon as the bundle finishes parsing. The current initialization code would need to be handled by the consumer so that the component could be initialized and destroyed when the parent component is unmounting, potentially multiple times within the lifetime of the parent app.

Missing API to mount / unmount Ember components

There isn't currently a thin API to render Ember or Glimmer components by themselves. It looks like some support for this lives in the GlimmerJS repo, and a new standalone wrapper could probably be written to hack this together. I'd love it if there was a first-class API for this though. There also doesn't seem to be a concept of initializing the root Ember component with initial arguments at runtime.

Building Ember components for external use

Components also would need to exported in a way where they can be referenced by an external bundler. For example, ember build could emit a library Javascript bundle containing just the Ember components, and something like webpack-node-externals to reference the @ember vendor imports. That way if lodash was included in an Ember component and in the host application, the vendor bundle would only include one copy. Webpack has excellent support for emitting bundles that are compatible with CommonJS import syntax, so maybe some of this support could be leveraged in Embroider. If this wasn't possible in the near term, exposing the root component as window.EmberComponents.MyRootComponentNameHere could work in the interim before the bundler changes land.

Components without the services

The current Ember architecture may not work well with an environment that needs to unmount the root component via a single page app route transition, as the javascript context would not be reloaded between virtual page transitions. If addons or services make assumptions about only being initialized once, this could be problematic. For this reason, we should focus on just supporting rendering Ember components without many of the monolith services that could be injected (such as ember-data and the router). After the story for rendering components is stable, support for these more complicated services could be added.

Prior art

After writing this article, I discovered that react-svelte exists already! You can check out the component implementation here, which has support for mounting, updating, and destroying the underlying Svelte component.

Thanks for reading!

By exposing an API to render components from other JS frameworks, Ember provides a better migration story for existing single page applications. Although React was used as an example, the same concepts apply to an existing app written with jQuery, or any other front-end framework for that matter. Many of the pieces are already in place to support this API (such as explicit this.args for Glimmer components and removing the dependency on jQuery). I look forward to seeing what progress we can make towards that goal this year!

Thanks to Frank Tan, Shane Warren, and Chris Krycho for reviewing earlier drafts.

EmberJS2019

Build hacks - Faster Ember builds with Docker on Windows

masters.🤔 — Fri, 17 May 2019 17:23:48 +0000

When I joined a team maintaining an Ember web app, I was surprised to learn that almost the whole team developed exclusively on MacBooks. The team experienced slow Ember builds on Windows, and dealing with native Node dependencies (such as node-gyp) was a frustrating experience. Microsoft has made some recent improvements to support Node-based development environments on Windows, so I set out to see what we could do to make this better.

Note: WSL2 has been announced, which resolves many of the performance pains we experienced. This post should still be relevant for those wanting to use Docker as a development container.

Just show me the code!

A working demo of the Docker setup is available on GitHub. We'll link to it throughout this article.

Why are builds so slow?

Ember's build pipeline creates a lot of temporary files, which we confirmed by using Process Monitor. Our suspicion was that the Windows NTFS filesystem itself has more overhead than other platforms, and creating a bunch of temporary files on disk and then reading them is where our main bottleneck was.

An example of some of the temporary files created during a build:

Our first approach to speed up builds was to leverage the Windows subsystem for Linux (WSL), which simulates a Linux environment without using a VM. You can find more detail here for how the filesystem mapping works, but the important part is the host's native filesystem is still used to store the underlying files (NTFS).

A screenshot of local filesystem activity running builds under WSL:

We confirmed our expectation that builds would be as slow as they were on a native Windows environment, so we moved on to other options. Our next step was to get the build workspace out of NTFS entirely, which meant using some kind of VM. Docker for Windows turned out to be a great fit for this.

What we needed

An easy setup for all Windows developers on the team. The only requirements on the host should be Docker and .NET Core.
Avoid (where possible) native dependencies on the host (such as build-essential or node-sass bindings)
A running dev server in the container (ember serve in this case) that can be notified when files change, which serves built assets over HTTP
Very fast access to read and write a bunch of temporary files

Configuring the container

We settled on running the entire Ember build pipeline within Docker and using the container's Linux-based filesystem, with some scripts to sync over just the application source from the host workstation. Let's go into detail on how this was accomplished.

Tools used:

Docker exposes the application source via a shared /host-app mount. This is always in sync with the host, but it's a poor place for temporary files, since it's exposed as a SMB mount point. At container start, the source is copied from the host to a directory within the container's filesystem in /app, and then the build process runs. It's important that the node_modules restore happens within the container and not over the shared mount so that the build has fast access to its dependencies. Passed in docker-cli arguments can be used via --build-arg to control steps run during build process, such as doing an initial unit test run.

Notifying the container of updates

Tools used:

The /host-app mount does not raise notifications when files change, so we need a way to sync over changes to the container's /app directory. We could use polling but that's slow and uses unnecessary CPU time, so instead we built a tool that simulates file change notifications from the container host. The DockerVolumeWatcher tool uses the Windows Filesystem APIs to watch for all files changed within directories that are mapped to containers via host mounts, ignoring anything listed in .dockerignore.

When an a file is changed, chmod is run within the container on the file that was changed (via chmod $(stat -c %a {filepath}) {filepath}) to raise the file changed event to the container's running processes. This hack works well for this case, as it doesn't actually modify the file contents on the host. Using a tool like touch would trigger another file modification event, which we don't want here. From here, a simple mirroring tool can be used (such as lsync) to copy over the changed source from /host-app to app.

Making the developer experience even better

Building containers creates a lot of artifacts, and after a few days of building new images, the Docker filesystem may run out of space. To counter this, we made a Powershell script as a part of starting up the dev environment that does a few things:

Start DockerVolumeWatcher
Clean up containers and images older than 24 hours
Sanity check that the FS watcher is working by creating a file on the host and checking for its existence via docker exec

You can check out the source for the script here.

Rough edges

This setup works well but requires a few workflow changes. For some VS code plugins, a recent version of Node is required for linting support. Package updates also require attaching to the container, running yarn add <package>, and copying over the changed manifest with cp /app/package.json /host-app/package.json (same with the lockfile). Rebuilding the container after packages have been updated is also slower than native package updating, as the container is starting from a fresh state. To work around this, you can create a "delta" and run package restore twice:

COPY --chown=user:user ./package-base.json ./package.json
COPY --chown=user:user ./yarn-base.lock ./yarn.lock

# Restore initial packages (cached in future container builds)
RUN yarn

COPY --chown=user:user ./package.json .
COPY --chown=user:user ./yarn.lock .

# This should be very fast, since it only restores missing packages
RUN yarn

Switching branches on the host also does not work very well, as hundreds of file notifications are generated at once. Sometimes the container has to be re-started to get back into a good state.

How fast is this, really

Results taken using a median after 5 passes, on an Intel Xeon E-2176M processor with 32 GB RAM and SSD.

The build was run with administrative privileges so the Ember build could use symlinks to speed up the build. More info here

Environment	Package restore	First build	Watch-mode rebuild
Windows native	67.51s	120.04s	6.017s
WSL	164.67s	208.13s	33.52s
Docker container	118.81s	70.61s	0.68s

Bonus: Containers for continuous integration builds

Many CI services support Dockerfile as the build recipe, such as Github Actions and Travis. If your build requires complicated setup steps, such as installing a specific version of Chrome or creating symlinks to other folders, using a Dockerfile can prevent the need to synchronize commands between CI scripts and local dev scripts.

Thanks for reading!

This was a fun experiment to see how fast we could get local builds. We're also testing out the Remote Containers extention for VS Code, and we look forward to using WSL2 when it releases in June 2019 to see how we can simplify this setup without sacrificing speed!

If you made it this far, consider getting involved with an OSS project you use on a daily basis. Chances are they could use a hand updating documentation, tests, or fixing some bugs. The .NET Foundation project list is a good place to start if you're looking for projects that need help.

Cheers 🍻

I'm on Twitter @dustinsoftware

Thanks to Tamar Kornblum and Frank Tan for reviewing earlier drafts of this post.

Making renders faster with the React 16.5 profiler

masters.🤔 — Tue, 25 Sep 2018 22:00:09 +0000

React 16.5 recently shipped, which added support for some new Profiling tools. We recently used these tools to identify a major source of slow render performance.

Faithlife.com is a web application powered by React 16.3. The homepage consists of a reverse-chronological timeline of posts. We received some reports that interactions with posts (such as replying) caused the browser to lag, depending on how far down the post was on the page. The further down the page the post was, the more lag occurred.

After updating React to 16.5 on a local copy of Faithlife, our next step was to start profiling and capture what components were re-rendering. Below is a screenshot of what the tools showed us clicking the 'Like' button on any post:

The blue blocks below NewsFeed show render being called on all the posts in the feed. If there were 10 items loaded, NewsFeedItem and all its children would get rendered 10 times. This can be fine for small components, but if the render tree is deep, rendering a component and its children unnecessarily can cause performance problems. As a user scrolls down on the page, more posts get loaded in the feed. This causes render to get called for posts all the way at the top, even though they haven't changed!

This seemed like a good time to try changing NewsFeedItem to extend PureComponent, which will skip re-rendering the component and its children if the props have not changed (a shallow comparison is used for this check).

Unfortunately applying PureComponent was not enough - profiling again showed that unnecessary component renders were still happening. We then uncovered two issues preventing us from leveraging PureComponent's optimizations:

First roadblock: Use of children props.

We had a component that looked something like this:

<NewsFeedItem contents={item.contents}>
  <VisibilitySensor itemId={item.id} onChange={this.handleVisibilityChange} />
</NewsFeedItem>

This compiles down to:

React.createElement(
  NewsFeedItem,
  { contents: item.contents },
  React.createElement(VisibilitySensor, { itemId: item.id, onChange: this.handleVisibilityChange })
);

Because React creates a new instance of VisibilitySensor during each render, the children prop always changes, so making NewsFeedItem a PureComponent would make things worse, since a shallow comparison in shouldComponentUpdate may not be cheap to run and will always return true.

Our solution here was to move VisibilitySensor into a render prop and use a bound function:

<NewsFeedItemWithHandlers
  contents={item.contents}
  itemId={item.id}
  handleVisibilityChange={this.handleVisibilityChange}
/>

class NewsFeedItemWithHandlers extends PureComponent {
  // The arrow function needs to get created outside of render, or the shallow comparison will fail
  renderVisibilitySensor = () => (
    <VisibilitySensor
      itemId={this.props.itemId}
      onChange={this.handleVisibilityChange}
    />
  );

  render() {
    <NewsFeedItem
      contents={this.props.contents}
      renderVisibilitySensor={this.renderVisibilitySensor}
    />;
  }
}

Because the bound function only gets created once, the same function instance will be passed as props to NewsFeedItem.

Second roadblock: Inline object created during render

We had some code that was creating a new instance of a url helper in each render:

getUrlHelper = () => new NewsFeedUrlHelper(
    this.props.moreItemsUrlTemplate,
    this.props.pollItemsUrlTemplate,
    this.props.updateItemsUrlTemplate,
);

<NewsFeedItemWithHandlers
    contents={item.contents}
    urlHelper={this.getUrlHelper()} // new object created with each method call
/>

Since getUrlHelper is computed from props, there's no point in creating more than one instance if we can cache the previous result and re-use that. We used memoize-one to solve this problem:

import memoizeOne from 'memoize-one';

const memoizedUrlHelper = memoizeOne(
    (moreItemsUrlTemplate, pollItemsUrlTemplate, updateItemsUrlTemplate) =>
        new NewsFeedUrlHelper({
            moreItemsUrlTemplate,
            pollItemsUrlTemplate,
            updateItemsUrlTemplate,
        }),
);

// in the component
getUrlHelper = memoizedUrlHelper(
    this.props.moreItemsUrlTemplate,
    this.props.pollItemsUrlTemplate,
    this.props.updateItemsUrlTemplate
);

Now we will create a new url helper only when the dependent props change.

Measuring the difference

The profiler now shows much better results: rendering NewsFeed is now down from ~50ms to ~5ms!

PureComponent may make your performance worse

As with any performance optimization, it's critical to measure the how changes impact performance.

PureComponent is not an optimization that can blindly be applied to all components in your application. It's good for components in a list with deep render trees, which was the case in this example. If you're using arrow functions as props, inline objects, or inline arrays as props with a PureComponent, both shouldComponentUpdate and render will always get called, because new instances of those props will get created each time! Measure the performance of your changes to be sure they are an improvement.

It may be perfectly fine for your team to use inline arrow functions on simple components, such as binding onClick handlers on button elements inside a loop. Prioritize readability of your code first, then measure and add performance optimizations where it makes sense.

Bonus experiment

Since the pattern of creating components just to bind callbacks to props is pretty common in our codebase, we wrote a helper for generating components with pre-bound functions. Check it out on our Github repo.

You can also use windowing libraries, such as react-virtualized to avoid rendering components that aren't in view.

Thanks to Ian Mundy, Patrick Nausha, and Auresa Nyctea for providing feedback on early drafts of this post.

Cover photo from Unsplash: https://unsplash.com/photos/ot-I4_x-1cQ

.NET Core in Docker on a Raspberry Pi

masters.🤔 — Fri, 04 May 2018 03:28:58 +0000

May 20, 2018 Update: This post is now obsolete as of .NET Core 2.1! Please see this blog post for details.

Out of date information below:

dotnet new react by default will give you a project that runs fine on x86/x64 architectures. The RPI, however, runs on arm32v7. We'll need to make a few small changes to support this architecture within Docker.

ARM is supported by ASP.NET Core, so why doesn't it just work in Docker?

New projects by default include the metapackage Microsoft.AspNetCore.All, which makes some assumptions about what libraries are already on the runtime target. For this to work with Docker, this means the runtime image needs to be microsoft/aspnetcore. However, this poses a problem!

There is no ARM package for the microsoft/aspnetcore Docker image. The dockerfile indicates that pre-made binaries for this image are pulled from a CDN, but there don't appear to be any that exist for armv7.

Using a different base image

Fortunately, there is a docker image already for the ARMv7 .NET Core runtime, we are be able to use that as a base image! Now we just have to declare the AspNetCore dependencies explicitly.

Getting started

A working example of this project lives at this GitHub repo

Create a new project with dotnet new react
Remove the Microsoft.AspNetCore.All reference in the project file and replace it with these references:

    <PackageReference Include="Microsoft.AspNetCore" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.SpaServices" Version="2.0.0" />
    <PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.0.0" />

Verify the app still works with dotnet run
Create a Dockerfile that looks something like this:

FROM microsoft/aspnetcore-build:2 AS build-env
WORKDIR /app

# Copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore

# Copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out

# Build runtime image
FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY --from=build-env /app/out ./
ENTRYPOINT ["dotnet", "DpmWebsite.dll"]
EXPOSE 5000

Then, copy this dockerfile to a new file named Dockerfile.arm32. This should be identical, except we're going to change the runtime image to:

FROM microsoft/dotnet:2.0.0-runtime-stretch-arm32v7

This allows the application to boot from the ARM version of the .NET SDK.

Now, ensure a local build works:

docker build -t netcore-local .
docker run -d -p 5000:5000 netcore-local

Once this is confirmed working, build an ARM specific image:

docker build -t yourdockerid/rpi-net-core -f Dockerfile.arm32 .
docker push yourdockerid/rpi-net-core

Finally, pull the image and run it on your Raspberry Pi!

docker pull yourdockerid/rpi-net-core
docker run --restart=always -d -p 5000:5000 yourdockerid/rpi-net-core

If you are having trouble, get the ID of the image, then use docker logs (containerid)

Thanks for reading!

This was a fun exercise. It's so exciting to see the .NET platform become more accessible, hats off to the whole team for making this a reality!

Inspecting application state with the SOS debugging tools

masters.🤔 — Tue, 09 Jan 2018 23:44:10 +0000

This post originally appeared on Faithlife.Codes.

In this post, we'll cover how to use the SOS debugging tools to inspect variables from a process dump of a .NET Framework / .NET Core application.

Required:

Obtaining a memory dump

In this first example, we'll use a running ASP.NET MVC 5 application hosted by IIS, but the steps here can be used on a normal .NET framework Windows application. Let's start by taking a full memory dump of a running application.

Download ProcDump and copy it to the server that runs the application you want to debug. Obtain the process ID from the application you want to profile by using Task Manager, and then pass it as an argument to procdump.

procdump -ma <pid>

You should now have a dump named similar to w3wp_171229_151050.dmp in the working directory.

Note:

If you're running several applications under a single app pool in IIS, it may be easier to debug by changing the app to run under its own application pool, which allows the ASP.NET app to run under a dedicated process.

Inspecting the ASP.NET application state (.NET Framework)

Now that we have a memory dump, it's time to look at the suspended state of the application. Copy the dump file to your workstation, and then open it via File > Open Crash Dump in WinDBG. Your screen should look like this:

Load the SOS debugging extension, which will allow us to inspect the managed threads:

!loadby sos clr

Then, list the stack trace of every thread:

!eestack

Note:

If get an exception when running this command and you are using IIS Express, try the command again. There appears to be a bug that throws an exception only for the first command run from WinDbg, which should not affect the rest of your debugging session.

You should see a lot of threads in the output. To narrow the results down, search for the namespace of your project in the output text.

We can see that there is an external web request being made in Thread 34. Let's look at what external URL is being requested. Switch to the thread, and then run clrstack -p to get some more detailed information about each method call.

~34 s
!clrstack -p

Note:

You may see many arguments that contain the value <no data>. This can be caused by compiler optimizations; inspecting the state of these parameters is beyond the scope of this article.

The controller is present in this call stack, so let's inspect the object instance by clicking on the this instance address, which is a shortcut for the !DumpObj command.

This instance contains a field named _request, which contained a field named requestUri, which has the original URI for this request:

That's it! The commands vary slightly for dumping different field types.

.NET Core application on Linux

Required:

LLDB 3.9
Locally-built copy of the SOS plugin in the CoreCLR repo - instructions

In this next scenario, we'll look at inspecting a core dump from a .NET Core app running on an Ubuntu x64 instance. The instance will have a core dump taken while a request is processing, which we will then inspect.

Take a core dump of the process using the createdump utility. These commands assume you have the coreclr repo checked out to ~/git/coreclr, and that you're running an application built with .NET Core 2.0.

sudo ~/git/coreclr/bin/Product/Linux.x64.Debug/createdump -u (pid)

Load the dump in LLDB. This command also loads the SOS debugging extension.

lldb-3.9 dotnet -c /tmp/coredump.18842 -o "plugin load ~/git/coreclr/bin/Product/Linux.x64.Debug/libsosplugin.so"

After a few moments, a CLI will become available. Run eestack to dump the state of all CLR threads. If you get an empty output or a segmentation fault, verify that you are running the correct version of lldb and are loading libsosplugin from the bin directory, and that you have created the core dump with createdump.

eestack

There is an instance of HomeController in the stack of Thread 17. Switch to it to reveal more information about the current request. This time, we'll inspect the state of an internal .NET Core request frame, since information about the current request isn't as accessible as it was in ASP.NET MVC 5.

thread select 17
sos DumpStackObjects

Look for the address of Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Frame'1[[Microsoft.AspNetCore.Hosting.Internal.HostingApplication+Context, Microsoft.AspNetCore.Hosting]] in the output, and then dump the object. The name of this class might differ slightly based on the version of the framework you're running.

Identify the QueryString field address:

Dumping that field reveals the query part of the URL the browser requested!

Thanks to Kyle Sletten, Justin Brooks, and Bradley Grainger for reviewing early drafts of this post.

Mitigating cross-site scripting with Content Security Policy

masters.🤔 — Thu, 21 Dec 2017 19:18:20 +0000

In this post, we're going to look at using Content Security Policy (CSP) as a defense-in-depth technique to block script injection attacks.

When building website that hosts user-generated content, such as:

Great to be here!
<script>window.location='https://example.com'</script>

It's necessary to encode user-generated content so that browsers don't mistake it for markup, and execute an untrusted script. This is easy to do for plain text, but what if a page needs to render user-generated HTML? Here's an example of HTML that contains inline Javascript, which browsers could execute:

<p>Great to <b>be</b> here!</p>
<img src="" onerror="alert(0)" />
<a href="javascript:alert(0)">Hi</a>
<script>window.location='https://example.com'</script>

This content must be sanitized before rendering. Libraries such as HTMLAgilityPack or DOMPurify provide a way to parse the HTML and strip out elements or attributes known to execute scripts.

Sanitization is important, but what if an attacker has discovered a way around the filter? This is where Content Security Policy comes in.

If the Content-Security-Policy header is present when retrieving the page, and contains a script-src definition, scripts will be blocked unless they match one of the sources specified in the policy. A policy might look something like:

script-src 'self'; object-src 'none'; base-uri 'none';

This policy disallows:

External scripts not hosted on the same domain as the current page.
Inline script elements, such as <script>
Evaluated Javascript, such as <img src="" onerror="alert(0)" />
Base elements, which could break scripts loaded from a relative path
Object elements, which can host interactive content, such as Flash

Whitelisting inline scripts

Sometimes it is necessary to run inline scripts on your page. In these cases, the nonce attribute on script elements can be used to whitelist scripts that you control.

<script nonce="00deadbeef">doSomething()</script>

A matching nonce must be present in the CSP for the script to run. For compatibility with older browsers, unsafe-inline allows scripts to run if the nonce tag is unsupported.

script-src 'self' 'nonce-00deadbeef' 'unsafe-inline'; object-src 'none'; base-uri 'none';

It is critical that this nonce is derived from a cryptographic random number generator so that an attacker can't guess a future nonce. In .NET, RNGCryptoServiceProvider.GetBytes can be used to fill a 16 byte array:

using (var random = new RNGCryptoServiceProvider())
{
    byte[] nonce = new byte[16];
    random.GetBytes(nonce);
    return Convert.ToBase64String(nonce);
}

Whitelisting external scripts

strict-dynamic can be used to allow scripts hosted on a third-party domain to be loaded by scripts that you control. However, at the time of writing, this isn't supported by all major browsers, so a host whitelist should be used as well as a fallback until it has broad support.

script-src 'self' 'nonce-00deadbeef' 'unsafe-inline' 'strict-dynamic' https://example.com; object-src 'none'; base-uri 'none';

When using strict-dynamic, you will also need to add a nonce to any external scripts that are referenced.

<script nonce="00deadbeef" src="https://example.com/analytics.js" />

Note:

Be careful what sources you whitelist. If any endpoints return JSONP and fail to sanitize the callback, it is possible to inject code. For example:
<script src="https://example.com/getuser?callback=window.location='http://google.com';test"></script>
Might return window.location='http://google.com';test({}) in the JSONP response, which would cause arbitrary code to be executed!

There are other policies that you can define to strengthen your site's security, such as restricting where stylesheets are loaded from. This post only focuses on mitigating cross-site scripting attacks.

DEV Community: masters.🤔

Verifying Assembly Redirects Before Runtime

The case for Embeddable Ember

React component

Ember component, invoked from React

Hard-coded selector for root node

Missing API to mount / unmount Ember components

Building Ember components for external use

Components without the services

Prior art

Thanks for reading!

EmberJS2019

Build hacks - Faster Ember builds with Docker on Windows

Just show me the code!

Why are builds so slow?

What we needed

Configuring the container

Notifying the container of updates

Making the developer experience even better

Rough edges

How fast is this, really

Bonus: Containers for continuous integration builds

Thanks for reading!

Making renders faster with the React 16.5 profiler

First roadblock: Use of children props.

Second roadblock: Inline object created during render

Measuring the difference

PureComponent may make your performance worse

Bonus experiment

.NET Core in Docker on a Raspberry Pi

May 20, 2018 Update: This post is now obsolete as of .NET Core 2.1! Please see this blog post for details.

Out of date information below:

ARM is supported by ASP.NET Core, so why doesn't it just work in Docker?

Using a different base image

Getting started

Thanks for reading!

Inspecting application state with the SOS debugging tools

Obtaining a memory dump

Inspecting the ASP.NET application state (.NET Framework)

.NET Core application on Linux

Mitigating cross-site scripting with Content Security Policy

Whitelisting inline scripts

Whitelisting external scripts

Further Reading