In this post, I’ll describe a little trick I used while building a Rider plugin for XAML Styler, which is referencing a specific assembly from a NuGet package.
Let’s start with some background on why I needed this, followed by how to reference a specific assembly from a NuGet package. If you don’t care about the background, feel free to skip the first section.
Another nerd snipe… A friend of mine asked me how hard it would be to build a Rider plugin for XAML Styler, so I got to work. The plugin will add an intention to the IDE, which will let you reformat XAML documents in a project or solution using XAML Styler.
This is the idea (recorded with the plugin that is in the works):
Getting the plugin project setup correctly is relatively straightforward, thanks to a Rider and ReSharper plugin template.
Interesting to note is that right now, even though Rider is powered by .NET Core on macOS and Linux, plugins that run in the ReSharper-powered backend (architecture), have to target .NET Framework 4.6.1.
The formatting itself can be done using the XamlStyler.Core assembly. It’s a netstandard2.0 assembly, which is also part of the XamlStyler.Console package.
Hooking up the plugin, which targets .NET Framework 4.6.1, and the XamlStyler.Core assembly, which targets netstandard2.0, should be easy, as .NET 4.6.1 supports .NET Standard 2.0.
The problem for me as a plugin writer, is that there is no XamlStyler.Core NuGet package. There is XamlStyler.Console, which contains the assembly, but the XamlStyler.Console package targets netcoreapp3.1. When adding a package reference to it, you’ll be greeted with the following message on build:
Package XamlStyler.Console 3.2003.9 supports: netcoreapp3.1 (.NETCoreApp,Version=v3.1) / any [Plugin.sln]
Plugin.csproj : error NU1212: Invalid project-package combination for XamlStyler.Console 3.2003.9. DotnetToolReference project style can only contain references of the DotnetTool type [Plugin.sln]
Restore failed in 572,8 ms for Plugin.csproj.
Note that XamlStyler.Console is also a “tools package” (for command line use), so we can’t reference it directly. However, let’s ignore that fact for now.
Looking at the package using NuGet Package Explorer, we can see the XamlStyler.Core assembly is there, and it has the correct target framework.
Can we reference just that assembly? Turns out we can!
How to Reference a Specific Assembly from a NuGet Package
There’s an interesting section in the NuGet documentation on PackageReference:
Sometimes it is desirable to reference files in a package from an MSBuild target. In packages.config based projects, the packages are installed in a folder relative to the project file. However in PackageReference, the packages are consumed from the global-packages folder, which can vary from machine to machine.
To bridge that gap, NuGet introduced a property that points to the location from which the package will be consumed.
In other words, if we add the GeneratePathProperty=”true” attribute to the PackageReference element in our .csproj file, we can then access the path to that package reference using a $(PkgPackage_Id) variable (where Package_Id is the package id, where dots are replaced with underscores).
Additionally, we can tweak what has to happen with our pakage on restore. We can control the asset behaviour, and essentially tell NuGet to restore the package, but not reference it at all. Adding these attributes to our PackageReference element will do just that: ensure the package is downloaded, and not referenced:
Almost there We now have the path to our NuGet package on disk, and we’re not adding any package references. An assembly reference is the final thing to add into the mix, adding a reference to just the XamlStyler.Core assembly:
By setting the assembly hint path to $(PkgXamlStyler_Console), followed by the path in to our assembly file in the NuGet package, we can reference the assembly directly!
For those who landed here and want a full snippet that can be added to a .csproj file: here you go!
XAML Styler Console package targets netcoreapp3.x – we can’t reference it, but we can download it 🙂
GeneratePathProperty will make the path to the package available in $(PkgXamlStyler_Console), and we can then add an assembly reference…
<PackageReference Include=“XamlStyler.Console” Version=“3.2003.9” IncludeAssets=“None” ExcludeAssets=“All” PrivateAssets=“None” GeneratePathProperty=“true” />
<Reference Include=“XamlStyler.Core, Version=22.214.171.124, Culture=neutral, PublicKeyToken=0b11ff60a8153268”>
Use it with caution, as this trick probably sits on the edge of what is proper NuGet usage, but in case you ever need to reference an assembly from a NuGet package directly, ignoring other assemblies, this is a solution that works well.
Another one you may look into is Paket, which has several options for referencing packages, assemblies, and files from GitHub.
Permanent link to this post here