Embedding Resources in NuGet Packages While Tracking Coverage With AxoCover

Packaging .NET libraries for distribution is one of those jobs that feels straightforward until the first request lands for a localised string, an icon, or a template file that must ship inside the assembly. For developers attending sessions at the C# Corner Annual Conference 2020, this scenario is more than theoretical. Many of the teams represented at the event build shared components that get reused across cloud services hosted in Azure's Sydney and Melbourne regions, and they regularly need to bundle binaries, satellite files, and content alongside compiled code.

NuGet already handles the heavy lifting of dependency resolution, versioning, and feed distribution, but embedding resources requires a few extra touches inside the project file. Pairing that workflow with AxoCover, a Visual Studio extension that runs unit tests and surfaces code coverage in a single pane, gives Australian teams a complete loop from authoring through verification. The combination works well whether the shop is in Brisbane, Perth, or Adelaide, because the tooling runs entirely on a developer's workstation before anything touches a build server.

This walkthrough covers creating a class library that ships embedded resources, packaging it as a NuGet, then configuring AxoCover so coverage reports show exactly which lines of packaged code were exercised. Along the way, the same script-based approach can be slotted into a continuous integration pipeline running in Azure Australia East, where latency to a developer's machine in Parramatta or North Sydney stays under thirty milliseconds.

By the end, a small team should have everything it needs to publish a private feed, consume it from another solution, and watch AxoCover highlight the branches that need more test attention, all without leaving Visual Studio.

Setting up a class library with embedded resources

The starting point is a class library targeting netstandard2.0, which remains the safest target for libraries consumed by both legacy .NET Framework apps and modern .NET workloads. After the project is created, any file that should travel inside the assembly is added through the Build Action dropdown in Visual Studio's Solution Explorer and set to Embedded Resource. The compiler then records that file in the assembly's resource manifest, where it can be reached at runtime through Assembly.GetManifestResourceStream.

For Australian teams working across distributed time zones, this pattern is handy for shipping region-specific templates. A library consumed by branches in AEST and AEDT can carry separate resource files for each locale, and the consumer code reads the right one based on CultureInfo.CurrentUICulture. Setting the build action is only half the work, however, because the default LogicalName follows the pattern <RootNamespace>.<Folder>.<File>, which is rarely what a public package should expose.

To rename the resource so callers can predict it, the .csproj file is edited directly. A <EmbeddedResource> element with an explicit LogicalName attribute makes the entry appear as something tidy like Acme.Templates.Welcome.txt rather than MyCompany.MyProject.Properties.Resources.Welcome.txt. That change is the difference between a clean public API and a maintenance headache, and it costs about thirty seconds in the editor.

Once the resource is wired in, a quick smoke test loads it through reflection and writes the contents to the debug output window. If the bytes appear, the assembly is ready to be packaged. From a desk in Melbourne's Docklands, this often takes a coffee break and a quick yarn with a colleague in the next pod about the arvo's standup.

Authoring the .nuspec and packing the NuGet

Most modern projects use the SDK-style project format, which generates a .nuspec automatically when dotnet pack runs. For embedded resources, however, manual control of the package sometimes pays off, especially when the library needs to declare content files or dependencies that the SDK cannot infer. In that case, a .nuspec file is hand-written and pointed to through the <NuspecFile> property in the project file.

Inside the .nuspec, the <metadata> block lists id, version, authors, and description. A useful touch for Australian consumers is filling the iconUrl with a hosted PNG and adding tags such as templates, embedded-resources, and australia so the package can be discovered on nuget.org. The <files> section explicitly enumerates the resources that should land under the lib folder, which prevents the SDK from guessing incorrectly.

Running nuget pack from the Package Manager Console produces a .nupkg that can be inspected with NuGet Package Explorer. That tool, which is itself a small .NET application, lets a developer open the package and confirm that Acme.Templates.Welcome.txt sits inside the assembly's resource manifest rather than as a loose file at the package root. Catching this mistake before the package reaches a feed in Azure Australia East saves a round trip with downstream consumers in Sydney or Canberra.

Versioning deserves a paragraph of its own. The standard practice is to align the assembly's AssemblyVersion with the NuGet version, while keeping AssemblyFileVersion slightly ahead so file properties in Windows Explorer show a useful build number. For teams in Perth who watch the working day slip into the evening, automating the version bump through a small MSBuild target tied to the date keeps the metadata honest without anyone remembering to edit a file.

Wiring up AxoCover for coverage reporting

AxoCover lives inside Visual Studio as an extension and acts as a friendly front end over test runners such as NUnit, MSTest, and xUnit. After installing it from the Visual Studio Marketplace, a new Test menu entry appears, and clicking it opens a panel that lists every test in the active solution. Running tests through AxoCover, rather than the stock Test Explorer, is what enables the coverage overlay that highlights executed and missed lines in the editor.

Configuration is stored in a small JSON file that AxoCover creates on first launch. The relevant settings include the runner type, the assemblies to instrument, and the output directory for the coverage report. For a solution that consumes the freshly built NuGet, the consuming test project is added to AxoCover's run list, and the library project itself is flagged for coverage so the test results reveal exactly which methods were reached.

Australian teams often find this layer particularly valuable during a refactor. A developer in Adelaide updating the public API of the packaged library can immediately see whether the existing unit tests still touch every branch, and the highlighted gaps show up in red on the screen. Combined with the embedded resources from earlier, it becomes possible to test the localisation code path that reads each resource without spinning up a full integration environment.

If a team prefers running tests from the command line, AxoCover also ships a small CLI called AxoCoverCmd. That binary accepts the same JSON configuration and emits a coverage report in Cobertura or XML format, which is perfect for a build pipeline that needs to fail when coverage drops below a threshold. From an office in Brisbane, the same report can be uploaded to Azure Pipelines as a build artefact and reviewed during the morning arvo coffee.

Publishing to a local feed or nuget.org

Before pushing a package publicly, most teams stand up a private feed to share the artefact with colleagues. Azure Artifacts offers a free tier for small groups and hosts feeds in the same region as the rest of the Azure estate, which for Australian customers usually means Sydney. Publishing is a single nuget push command, provided a personal access token is supplied, and the package becomes consumable by anyone in the organisation within a few seconds.

For external release, nuget.org remains the canonical home. The same push command works once a NuGet account is set up and an API key is generated. Australian maintainers should be aware that moderation queues for new publishers occasionally add a wait of several minutes to a few hours, so the first push of the day is best done before lunch rather than right before a release window. The team can keep moving with the local Azure Artifacts feed in the meantime, so no-one is blocked.

Integrating the build into CI and comparing tools

A short PowerShell or Bash script ties the steps together: restore, build, run AxoCoverCmd, pack, and push. Running the same script on a hosted agent in Azure Australia East produces a coverage report that matches what a developer saw on their machine, because AxoCover's CLI runs identically in both environments. The script can be wrapped in an Azure DevOps pipeline YAML file and triggered on every commit, with a gate that fails the build when coverage falls under a set percentage.

The table below compares AxoCover with two other popular coverage options for .NET, which helps decide which tool fits a particular team's habits and platform mix.

Once the pipeline is green and the package is in the feed, the same library that ships embedded resources can be referenced from another solution, consumed by Atlassian-style plugins running on Bamboo, or dropped into a small internal app at a Perth mining firm that needs templated reports. The combination of a clean .nuspec, a verified resource manifest, and an AxoCover coverage report makes the package trustworthy from the moment it lands in the feed, and the workflow scales from a single developer in a Surry Hills coworking space to a distributed team working across the country.