Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CS0246 build errors on .NET 6.0.300 SDK #24

Closed
mattjohnsonpint opened this issue May 23, 2022 · 8 comments
Closed

CS0246 build errors on .NET 6.0.300 SDK #24

mattjohnsonpint opened this issue May 23, 2022 · 8 comments
Labels
help wanted Extra attention is needed

Comments

@mattjohnsonpint
Copy link

mattjohnsonpint commented May 23, 2022

After installing the .NET 6.0.300 SDK, doing dotnet build --no-incremental on a project using this library gives errors such as:

error CS0246: The type or namespace name 'NotNullWhen' could not be found

Minimal Reproduction

MyApp.csproj

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <LangVersion>8</LangVersion>
    <Nullable>annotations</Nullable>
    <TargetFrameworks>net6.0;net48</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Nullable" Version="1.3.0" PrivateAssets="all" />
  </ItemGroup>

</Project>

Program.cs

using System;
using System.Diagnostics.CodeAnalysis;

namespace MyApp
{
    class Program
    {
        static void Main(string[] args)
        {
            if (Test(out var value))
            {
                Console.WriteLine(value);
            }
        }

        private static bool Test([NotNullWhen(true)] out string? value)
        {
            value = "Hello World!";
            return true;
        }
    }
}

Compile with dotnet build --no-incremental:

C:\Users\mattj\Code\MyApp>dotnet build --no-incremental
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhenAttribute' could not be found (are you m
issing a using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
C:\Users\mattj\Code\MyApp\Program.cs(16,35): error CS0246: The type or namespace name 'NotNullWhen' could not be found (are you missing a 
using directive or an assembly reference?) [C:\Users\mattj\Code\MyApp\MyApp.csproj]
  MyApp -> C:\Users\mattj\Code\MyApp\bin\Debug\net6.0\MyApp.dll

Build FAILED.

Workaround

Install the previous 6.0.203 SDK, and force the project to use it by adding a global.json file with the following:

{
  "sdk": {
    "version": "6.0.203"
  }
}

Then the project builds just fine with dotnet build --no-incremental.

This might be an upstream problem with .NET, but I haven't dug deep enough to figure out what it might be.

@mattjohnsonpint
Copy link
Author

I also find it interesting that it only occurs with --no-incremental, even if this is the first build (no bin or obj folders). Maybe that will help your investigation.

@shuebner
Copy link

shuebner commented Jun 1, 2022

I just tried using this and IsExternalInit instead of importing the cs files myself and have the same problem.

For me it works with neither SDK 6.0.100 nor 6.0.202 nor 6.0.300.

Occasionally the CLI build will work, but VS 2022 is never able to build.
I suspect a race condition in the nuget source transformation, because I did not have this problem when I imported my own cs files into all my projects to gain support for nullability and record types.

@manuelroemer
Copy link
Owner

Hey, I unfortunately had nowhere near enough time yet to thoroughly look into this, but I could also reproduce the error. The issue I'm having is that, from my point of view, the package itself is sound, i.e. the nuspec which is used to inject the files is, unless I'm missing something, looking the way it's supposed to.
My guess is that the .NET tooling/Nuget/VS/... has some kind of regression somewhere such that it doesn't handle source code provided by packages well. I cannot prove it though, this is just a hunch on my side. If that does turn out to be true, there is unfortunately not much I could do on my side. The issue would have to be fixed at the root (and up until this point, everything did work properly, so something on the outside must have changed).

In any case, any help here investigating the issue is much appreciated ❤️! Maybe the issue is in this package/nuspec (in that case, any pointers as to what's wrong with the format will be very helpful). Or if you guys also believe that the issue is located on the outside, you might know where to raise an issue.

@manuelroemer manuelroemer added the help wanted Extra attention is needed label Jun 1, 2022
@mattjohnsonpint
Copy link
Author

I agree, it's most likely something in the tooling. Once we figure out what that is, most likely the best repo to report it to Microsoft on would be here https://github.com/dotnet/sdk

@mattjohnsonpint
Copy link
Author

Experimenting a bit. Turns out that it only fails when using <TargetFrameworks> instead of <TargetFramework>, unless you specify a framework on the command line with -f. I think for whatever reason, the build isn't passing along the <contentFiles> when it loops over <TargetFrameworks> to dispatch for each framework.

I'll open an issue on the SDK repo and link here.

@shuebner
Copy link

shuebner commented Jun 1, 2022

I observed the failure in another smaller and simpler repo.
It built with 6.0.100, but not with 6.0.300.
The projects were NOT multitargeting, but targeting netstandard2.0.

Also, only when using --no-incremental did the build fail. It was fine in both SDKs with the default command.

@manuelroemer
Copy link
Owner

Hey @mattjohnsonpint, I just want to quickly thank you for opening the issue on the .NET SDK repo and all the others for helping to provide additional information on this issue. I appreciate you guys a lot!
Let's see what the outcome will be!

@manuelroemer
Copy link
Owner

I just merged #26 by @gtbuchanan and published the new package version 1.3.1 on NuGet. During my local tests the issue indeed seemed to be fixed (using .NET SDK 6.0.300). I will preemptively close this issue, but if someone still has any problems in this area even with the newer version, feel free to message me or simply reopen this issue.
Many thanks to all people involved (so far 😉)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants