Basic.Reference.Assemblies.NetStandard20
1.7.9
Prefix Reserved
dotnet add package Basic.Reference.Assemblies.NetStandard20 --version 1.7.9
NuGet\Install-Package Basic.Reference.Assemblies.NetStandard20 -Version 1.7.9
<PackageReference Include="Basic.Reference.Assemblies.NetStandard20" Version="1.7.9" />
paket add Basic.Reference.Assemblies.NetStandard20 --version 1.7.9
#r "nuget: Basic.Reference.Assemblies.NetStandard20, 1.7.9"
// Install Basic.Reference.Assemblies.NetStandard20 as a Cake Addin #addin nuget:?package=Basic.Reference.Assemblies.NetStandard20&version=1.7.9 // Install Basic.Reference.Assemblies.NetStandard20 as a Cake Tool #tool nuget:?package=Basic.Reference.Assemblies.NetStandard20&version=1.7.9
Easy in-memory compilations for Roslyn
Roslyn is a powerful API for C# and Visual Basic compilations. Provide it code, a few options, and a set of references and it will provide an API to inspect the syntax, semantic model, diagnostics and even generate DLLs / EXEs.
Getting reference assemblies to use with a Compilation
is challenging because they are only shipped with development tools. In order to use them in a library, the developer must do the heavy lifting of packaging them up as resources in their library and unpacking them at runtime.
The Basic.Reference.Assemblies library takes care of this heavy lifting and provides reference assemblies for net8.0
, netstandard2.0
and net472
target frameworks. These can be easily integrated into the existing Roslyn APIs.
Usage Examples
using Microsoft.CodeAnalysis.CSharp;
using Basic.Reference.Assemblies;
using System.IO;
using System.Reflection;
var code = @"
using System;
public static class Example
{
public static void Main()
{
var tuple = (Part1: ""hello"", Part2: ""world"");
Console.WriteLine($""{tuple.Part1} {tuple.Part2}"");
}
}
";
var compilation = CSharpCompilation
.Create(
"HelloWorld.dll",
new[] { CSharpSyntaxTree.ParseText(code) },
references: ReferenceAssemblies.Net80);
using var stream = new MemoryStream();
var emitResults = compilation.Emit(stream);
stream.Position = 0;
var assembly = Assembly.Load(stream.ToArray());
var method = assembly.GetType("Example").GetMethod("Main");
method.Invoke(null, null); // Prints "Hello World"
This package also adds extensions methods for easily retargeting Compilation
instances to different target frameworks.
CSharpCompilation compilation = ...;
compilation = compilation.WithReferenceAssemblies(ReferenceAssemblyKind.Net80);
The expectation is that most developers will use Basic.Reference.Assemblies. This package has reference assemblies for the latest supported target frameworks and provides APIs to easily switch between them in Compilation
instances.
FAQ
What if I only need a single target framework?
Developers who only need a single target framework and are extremely size conscious can grab the target framework specific package:
- Basic.Reference.Assemblies.Net80
- Basic.Reference.Assemblies.NetStandard20
- Basic.Reference.Assemblies.Net472
Packages for older target frameworks are also available:
- Basic.Reference.Assemblies.Net70
- Basic.Reference.Assemblies.Net60
- Basic.Reference.Assemblies.Net60Windows
- Basic.Reference.Assemblies.Net50
- Basic.Reference.Assemblies.NetCoreApp31
- Basic.Reference.Assemblies.NetStandard13
- Basic.Reference.Assemblies.Net461
What is wrong with using typeof(Enumerable).Assembly
?
Developers working on .NET Framework will often end up with the following pattern for creating Compilation
instances:
Assembly systemCoreAssembly = typeof(System.Linq.Enumerable).Assembly;
string systemCorePath = systemCoreAssembly.Location;
MetadataReference systemCoreRef = AssemblyMetadata.CreateFromFile(path).GetReference();
This pattern will often work on .NET Framework but will fail when running on .NET Core. The reason for this is due to the differences in reference and implementation assemblies. Reference assemblies are designed for use at build time, while implementation assemblies are used at runtime. A particular type for a given target framework doesn't necessarily live in the same reference and implementation assembly. Also, the set of implementation assemblies can be larger than the reference assemblies for the same target framework.
The reason the above tends to work on .NET Framework is that the split between reference and implementation assemblies is not as pronounced. In most cases, there is a 1:1 relationship. On .NET Core, the split is much more pronounced, and it often requires probing for implementation assemblies to get a set which will work for building. This is a fragile process, though, and developers are much better off using the reference assemblies as intended by the .NET team.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net5.0 was computed. net5.0-windows was computed. net6.0 was computed. net6.0-android was computed. net6.0-ios was computed. net6.0-maccatalyst was computed. net6.0-macos was computed. net6.0-tvos was computed. net6.0-windows was computed. net7.0 was computed. net7.0-android was computed. net7.0-ios was computed. net7.0-maccatalyst was computed. net7.0-macos was computed. net7.0-tvos was computed. net7.0-windows was computed. net8.0 was computed. net8.0-android was computed. net8.0-browser was computed. net8.0-ios was computed. net8.0-maccatalyst was computed. net8.0-macos was computed. net8.0-tvos was computed. net8.0-windows was computed. |
.NET Core | netcoreapp2.0 was computed. netcoreapp2.1 was computed. netcoreapp2.2 was computed. netcoreapp3.0 was computed. netcoreapp3.1 was computed. |
.NET Standard | netstandard2.0 is compatible. netstandard2.1 was computed. |
.NET Framework | net461 was computed. net462 was computed. net463 was computed. net47 was computed. net471 was computed. net472 was computed. net48 was computed. net481 was computed. |
MonoAndroid | monoandroid was computed. |
MonoMac | monomac was computed. |
MonoTouch | monotouch was computed. |
Tizen | tizen40 was computed. tizen60 was computed. |
Xamarin.iOS | xamarinios was computed. |
Xamarin.Mac | xamarinmac was computed. |
Xamarin.TVOS | xamarintvos was computed. |
Xamarin.WatchOS | xamarinwatchos was computed. |
-
.NETStandard 2.0
- Microsoft.CodeAnalysis.Common (>= 4.11.0)
NuGet packages (2)
Showing the top 2 NuGet packages that depend on Basic.Reference.Assemblies.NetStandard20:
Package | Downloads |
---|---|
NTypewriter.Runtime
App-independent engine used to run NTypewriter from UI |
|
SourceGeneratorTestHelpers
Test helpers and extension methods to simplify testing of .NET source generators. |
GitHub repositories (6)
Showing the top 5 popular GitHub repositories that depend on Basic.Reference.Assemblies.NetStandard20:
Repository | Stars |
---|---|
dotnet/roslyn
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
|
|
nuke-build/nuke
🏗 The AKEless Build System for C#/.NET
|
|
dotnet/dotnet
Home of .NET's Virtual Monolithic Repository which includes all the code needed to build the .NET SDK from source
|
|
NeVeSpl/NTypewriter
File/code generator using Scriban text templates populated with C# code metadata from Roslyn API.
|
|
jxnkwlp/abp-elsa-module
Elsa abp module and workflow app
|
Version | Downloads | Last updated |
---|---|---|
1.7.9 | 688 | 9/19/2024 |
1.7.8 | 344 | 8/28/2024 |
1.7.7 | 132 | 8/23/2024 |
1.7.6 | 121 | 8/23/2024 |
1.7.5 | 144 | 8/21/2024 |
1.7.4 | 370 | 8/16/2024 |
1.7.3 | 201 | 8/15/2024 |
1.7.2 | 3,577 | 5/7/2024 |
1.7.1 | 142 | 5/1/2024 |
1.7.0 | 92 | 5/1/2024 |
1.6.0 | 984 | 4/12/2024 |
1.5.0 | 1,388 | 3/1/2024 |
1.4.5 | 20,805 | 8/22/2023 |
1.4.4 | 195 | 8/18/2023 |
1.4.2 | 3,625 | 5/12/2023 |
1.4.1 | 13,604 | 11/3/2022 |
1.4.0 | 437 | 10/23/2022 |
1.3.0 | 668 | 10/3/2022 |
1.2.4 | 18,984 | 9/7/2021 |
1.2.3 | 309 | 9/2/2021 |
1.2.2 | 333 | 8/30/2021 |
1.2.1 | 315 | 8/26/2021 |
1.2.0 | 308 | 8/25/2021 |
1.1.2 | 5,840 | 4/8/2021 |
1.1.1 | 947 | 2/23/2021 |
1.1.0 | 355 | 2/23/2021 |
1.0.0 | 338 | 1/31/2021 |
0.1.9 | 344 | 1/31/2021 |
0.1.8 | 366 | 1/30/2021 |
0.1.7 | 318 | 1/30/2021 |
0.1.6 | 358 | 1/30/2021 |
0.1.5 | 320 | 1/29/2021 |
0.1.0 | 836 | 1/29/2021 |