We Keep Coding

C# Source Generator - warning CS8032: An instance of analyzer cannot be created

I'm trying to build a Source Generator. Right now, just the most basic static method that returns "Hello World".
The generator project builds, but the generated code is not available, the debugger never starts, and the build output shows
CSC : warning CS8032: An instance of analyzer Generator.StaticPropertyEnum.helloWorld cannot be created from ...\bin\Debug\net5.0\Generator.StaticPropertyEnum.dll : Could not load file or assembly 'System.Runtime, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified..
Examples I'm referencing
Roslyn Team Generator Sample Project
Roslyn Team Generator Cookbook
Generator.Equals Project
How To Debug C# 9 Source Generators
I've tried
changing the TargetFramework and LanguageVersion of both the generator and test projects
referencing many version of the analyzer libraries Microsoft.CodeAnalysis.CSharp and Microsoft.CodeAnalysis.Analyzers
referencing an explicit version of Microsoft.Net.Compilers.Toolset
Adding an explicit reference to the NetStandard library
starting from scratch with an analyzer project template
looking for a generator project template (but didn't find one)
Versions
Visual Studio: version 16.8.3
.NET SDK: 5.0.101
Code
Generator.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.CodeAnalysis.CSharp" Version="3.9.0-2.final" PrivateAssets="all" />
<PackageReference Include="Microsoft.CodeAnalysis.Analyzers" Version="3.0.0" PrivateAssets="all" />
</ItemGroup>
</Project>
Test csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.7.1" />
<PackageReference Include="xunit" Version="2.4.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.4.3">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
<PackageReference Include="coverlet.collector" Version="1.3.0">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Generator.StaticPropertyEnum\Generator.StaticPropertyEnum.csproj" OutputItemType="Analyzer" ReferenceOutputAssembly="false"/>
</ItemGroup>
</Project>
Generator
[Generator]
public class helloWorld : ISourceGenerator
{
public void Execute(GeneratorExecutionContext context)
{
context.AddSource("HelloWorld-generated.cs", #"
using System;
namespace HelloWorld
{
public static class Hello
{
public static string SayHello() {
return ""HelloWorld"";
}
}
}");
}
public void Initialize(GeneratorInitializationContext context)
{
#if DEBUG
if(!Debugger.IsAttached) Debugger.Launch();
#endif
}
}

Source Generators must be .NET Standard 2.0 to run in Visual Studio 2019+ or .NET Standard 1.x to run in Visual Studio 2017+.

I have source generator that targets netstandard2.0 and net5.0 for nullability support.
<TargetFrameworks>net5.0;netstandard2.0</TargetFrameworks>
<Nullable>enable</Nullable>
and sample library that targets same frameworks.
It crashes when project is being built within Visual Studio, but builds ok from the terminal.
To solve this, I've changed target framework when referencing it as a generator with SetTagetFramework and now it compiles without any warnings or errors.
<ItemGroup>
<ProjectReference Include="..\MyGenerator\MyGenerator.csproj"
OutputItemType="Analyzer" ReferenceOutputAssembly="false"
SetTargetFramework="TargetFramework=netstandard2.0" />
</ItemGroup>

as #Yair-Halberstadt mentioned in a different answer, the specific error listed is due to the fact that currently source generator projects need to target netstandard2.0.
However if you get the CS8032 error with a different assembly (for example Microsoft.CodeAnalysis, Version=3.0.x ...) your problem is probably caused by a SDK version mismatch.
For example on my computer I have SDK 5.0.302 which has version 3.10.0 of Microsoft.CodeAnalysis and Microsoft.CodeAnalysis.CSharp.
While the Generator project uses nuget to get these packages, the build of the project referencing the generator resolves these files from the SDK.
This is why reverting to 3.8.0 has worked for some commentators, the SDK version they have installed contains 3.8.0 of these references.

As crazy as it is
Close and reopen Visual Studio (2019, 2022)
If step 1 did NOT work, delete .vs folder
That solved my problem

I had to downgrade from 4.0.0 to 3.9 CodeAnalysis Sharp and Analyzers.

Removing my nuget package and adding the LAST stable version fixed that issue for me.

I could solve the same problem with
git clean -xdf
and then rebuilding the entire solution.

Warning CS8032
In my case I got this warning CS8032 in Visual Studio 2022:
##[warning]CSC(0,0): Warning CS8032: An instance of analyzer Microsoft.EntityFrameworkCore.InternalUsageDiagnosticAnalyzer cannot
be created from
C:\Windows\ServiceProfiles\NetworkService.nuget\packages\microsoft.entityframeworkcore.analyzers\7.0.2\analyzers\dotnet\cs\Microsoft.EntityFrameworkCore.Analyzers.dll
: Could not load file or assembly 'Microsoft.CodeAnalysis,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The system cannot find the file specified..
The issue
In my project, I have had 2 packages from Microsoft.EntityFrameworkCore.SqlServer and Microsoft.EntityFrameworkCore.InMemory installed with the latest version 7.0.2, but my TargetFramework for the project was net6.0.
The solution
Target Framework and Package versions must be identical. So I have chosen to downgrade my packages to 6.0.x and the warning CS8032 disappeared.
Note
The same solution applies to Target Framework counterpart Installed Packages.

Running MS Fakes before build properly while using the new NetSDK project format

I am trying to get Microsoft Fakes to work properly with my unit test project (net47) wherein my project file format is using the new NetSDK format.
With Visual Studio 2019, I can add a Fakes Assembly and things seem to work fine, until we try to build/run the tests on our build agent. It seems as though when you compile/build a project the fakes assemblies are generated, but they are done either in parallel or after the build (I'm not sure). This same problem happens on my development machine running Visual Studio 2019 Enterprise.
I noticed that if no FakesAssemblies folder exists, one is created during the build, but the compilation fails because none of the *.Fakes namespaces were discovered. A second compilation/build works because now the FakesAssemblies folder is populated. One thing to note is that I took the dll file for Microsoft Fakes and put it in a NuGet package in our companies private feed, that way I can pull it down as a NuGet package instead of a reference.
SampleUnitTests.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net47</TargetFramework>
<IsPackable>false</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.1.0" />
<PackageReference Include="Microsoft.QualityTools.Testing.Fakes" Version="16.0.28621.142" />
<PackageReference Include="MSTest.TestAdapter" Version="1.4.0" />
<PackageReference Include="MSTest.TestFramework" Version="1.4.0" />
</ItemGroup>
<ItemGroup>
<Fakes Include="Fakes\*.fakes" />
<Reference Include="FakesAssemblies\*.dll" />
</ItemGroup>
</Project>

Error when building System.ValueTuple in .NetStandard 2.0 project

I have a .NetStandard project that uses System.ValueTuple.
It builds fine in visual studio whether or not I include the System.ValueTuple nuget package.
However it fails either way when I build it on team-city with the error:
error CS8137: Cannot define a class or member that utilizes tuples because the compiler required type 'System.Runtime.CompilerServices.TupleElementNamesAttribute' cannot be found. Are you missing a reference?
Teamcity is hosted on an environment with both the latest .Net Core SDK and the latest .NetFramework SDK.
When I change the target framework to .NetCoreApp2.0 it builds fine.
Any ideas as to what could be going on?
For Reference, here is my csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFrameworks>netstandard2.0</TargetFrameworks>
<Version>$(VersionSuffix)</Version>
<Authors>**********</Authors>
<Product>**********</Product>
<Description>**********</Description>
<PackageTags>**********</PackageTags>
<GeneratePackageOnBuild>false</GeneratePackageOnBuild>
<Copyright>**********</Copyright>
<PackageProjectUrl>http://**********</PackageProjectUrl>
<PackageLicenseUrl>http://**********</PackageLicenseUrl>
<PackageIconUrl>http://**********</PackageIconUrl>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Google.Protobuf" Version="3.4.1" />
<PackageReference Include="RabbitMQ.Client" Version="5.0.1" />
</ItemGroup>
<ItemGroup>
<Folder Include="**********" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\**********" />
</ItemGroup>

The error went away when I started using DotNet Restore instead of Nuget Restore.
I have no idea why.

You most probably need to add a reference to System.ValueTuple.dll. You can do this by installing the System.ValueTuple package from nuget.

Building .net standard application that references Xamarin.Forms

I am trying to port a Windows.Forms application to .Net Standard 2.0 using Visual Studio Code. Based on responses to an earlier question (thank you guys), my plan is to try to use Xamarin.Forms to replace System.Windows.Forms. So, I add the Xamarin.Forms package to my project. When I try to run dotnet build, then I see the following error:
C:\Users\<user>\.nuget\packages\xamarin.forms\2.4.0.38779\build\netstandard1.0\Xamarin.Forms.targets(51,3): error MSB4062: The "Xamarin.Forms.Build.Tasks.FixedCreateCSharpManifestResourceName" task could not be loaded from the assembly C:\Users\<user>\.nuget\packages\xamarin.forms\2.4.0.38779\build\netstandard1.0\Xamarin.Forms.Build.Tasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
I have tried to add various other Microsoft.Build packages but nothing seems to work. Is there a way forward here? Here's my current csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="log4net" Version="2.0.8" />
<PackageReference Include="Microsoft.Build" Version="15.3.409" />
<PackageReference Include="Microsoft.Build.Framework" Version="15.3.409" />
<PackageReference Include="Microsoft.Build.Tasks.Core" Version="15.3.409" />
<PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.3.409" />
<PackageReference Include="NUnit" Version="3.8.1" />
<PackageReference Include="System.Configuration" Version="2.0.5" />
<PackageReference Include="System.Configuration.ConfigurationManager" Version="4.4.0" />
<PackageReference Include="System.ServiceModel" Version="1.0.0" />
<PackageReference Include="Xamarin.Forms" Version="2.4.0.38779" />
</ItemGroup>
</Project>
I think that I may be asking the same question as here: Where is the difference of dotnet build on cmd vs VS2017? but am not sure.

I'm working on a Xamarin.Forms application and I'm migrating my libraries from PCL to NetStandard.
It seems that you can build the project with MsBuild.exe (I used C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe).
I found it mentioned in this blog post: https://oren.codes/2017/04/23/using-xamarin-forms-with-net-standard-vs-2017-edition/
You will need to use MSBuild.exe to build this, either on Windows with a VS 2017 command prompt or a Mac with Visual Studio for Mac. You cannot use dotnet build for these projects types. dotnet build only supports .NET Standard, .NET Core and .NET Framework project types. It is not able to build the Xamarin projects and the custom tasks in Xamarin Forms have not yet been updated to support .NET Core.
An additional note: I had to delete AssemblyInfo.cs, otherwise MsBuild complained about duplicate properties.

How to include a library in .NET Core 2.0

I don't know much about .NET yet, so I guess I'm missing something obvious.
I created a library (targeted as a DLL file, set for .NET standard 2.0), packaged it both as a DLL file and as a NuGet package. Now I want to use the library in another project, on ASP.NET Core 2.0. How should I do it?
I am currently on a Linux VM, so I use Visual Studio Code, and therefore I would prefer some solution without using the full Visual Studio. I tried some solutions using the full Visual Studio, but that didn't work for me, because I haven't found a reference explorer anywhere.

You would have to reference your library in the .csproj file:
An empty .csproj file would look like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
</Project>
Now, you can have two types of references:
Project Reference - You have a project that serves as a class library in your solution and you want to reference it directly:
<ProjectReference Include="..\..\src\mylib.csproj" />
Package Reference - You have a link to a NuGet package:
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
Inside your .csproj file, the references should be inside an "ItemGroup" block, and each reference type should have its own "ItemGroup".
Here's an example of a .csproj file with some package references and some project references:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.1.0" />
<PackageReference Include="Microsoft.AspNetCore" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.2" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.InMemory" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Sqlite" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="1.1.2" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.1" />
<PackageReference Include="xunit" Version="2.2.0" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.2.0" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\..\src\mylib.csproj" />
<ProjectReference Include="..\..\src\mylib2.csproj" />
</ItemGroup>
</Project>

A lot of people recommend one of two solutions:
Copy the library into your solution folder.
cp -r foo/foo ./foo
dotnet sln add foo/foo.csproj
cd bar
dotnet add reference ../foo/foo.csproj
This is a terrible solution.
Don't do this (i.e., copy and paste your library code every time you want to use it. It is bad for obvious reasons).
Setup a local NuGet repository, copy your library into the local repository, and then add it.
nuget add -name "Local" -source /home/doug/packages
nuget add ~/foo/foo.nupkg -source /home/doug/packages
Then install the package:
cd bar
dotnet add package foo
This is an acceptable solution, but the workflow is quite irritating if you are actively working on your library (foo), because the -source path must be absolute.
--
I recommend you look at dotnet add package with local package file, which explains how you can have a local cache of any custom .nupkg files you want to work with.
Basically, just drop this into your solution folder:
File NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="local" value="./packages" />
</packageSources>
</configuration>
(Notice that ./packages is a relative path, that will work even when you check your project out on an entirely different machine or OS.)
Now if you call dotnet add package X it will also look for any file called x.nupkg in your ./packages/ folder.
Now if you want to use any custom local library, all you need to do is:
cp ~/foo/foo.nupkg ./packages
cd bar
dotnet add package foo
(Note: by default NuGet caches your .nupkg files in ~/.nuget and will restore packages from that folder if you call dotnet add package X, even if you have a different X.nupkg in your local ./packages folder. You may find the command dotnet nuget locals all --clear useful if you encounter strange behaviour to ensure you're getting the exact version of the .nupkg file you want, not some arbitrary cached version)

Another way to reference the local package in the .csproj file:
<ItemGroup>
<Reference Include="MyAssembly">
<HintPath>path\to\MyAssembly.dll</HintPath>
</Reference>
</ItemGroup>

Given that the DLL file you want to reference in the new ASP.NET Core 2.0 project is relatively fresh, I suspect you will need to make changes to this original DLL file as you develop the ASP.NET project.
In this situation I would add the original DLL project as part of the ASP.NET solution so you can work on both sets of source code, including setting of breakpoints within the same solution workspace.
NuGet packaging of the original DLL project can be delayed until the first release of your whole combined solution has stabilised and you want to make that DLL file available to a larger developer audience beyond the scope of your ASP.NET application.

A good solution will be to add the library (.dll file) that you want to use to the Project's References of your project in which you want to use the library:
Right Click on the project → Add → Reference → Project → Browse → Path_to_your_generated_library (.dll)
This will automatically generate the following node in the .csproj file:
<ItemGroup>
<Reference Include="DotNetCoreClassLibraryCodeParser">
<HintPath>..\..\DotNetCoreClassLibrary\DotNetCoreClassLibrary\bin\Debug\netcoreapp2.1\DotNetCoreClassLibrary.dll</HintPath>
</Reference>
</ItemGroup>