Closed mattjohnsonpint closed 2 years ago
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.
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.
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 :heart:! 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.
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
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.
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.
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!
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 😉)!
After installing the .NET 6.0.300 SDK, doing
dotnet build --no-incremental
on a project using this library gives errors such as:Minimal Reproduction
MyApp.csproj
Program.cs
Compile with
dotnet build --no-incremental
:Workaround
Install the previous 6.0.203 SDK, and force the project to use it by adding a
global.json
file with the following: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.