-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
NullReferenceException in Microsoft.NET.Build.Tasks.ProjectContext after broken restore #39316
Comments
Thanks for creating this issue! We believe this issue is related to NuGet tooling, which is maintained by the NuGet team. Thus, we closed this one and encourage you to raise this issue in the NuGet repository instead. Don’t forget to check out NuGet’s contributing guide before submitting an issue! If you believe this issue was closed out of error, please comment to let us know. Happy Coding! |
reopening and retagging - this should be kept open until we can prove a problem on the NuGet side. |
I have this problem with a .NET MAUI project after updating to
Operating system is Windows 11 23H2, build 22631.3447
|
I'm hitting this again now. I've pushed the state that repros it to: https://github.com/drewnoakes/project-system/tree/dotnet-sdk-issue-39316-repro Project: |
I'm hitting this as well. I get it even from the command-line, e.g. doing a
|
I'm also hitting the same issue when trying to setup Aspire to work with a monolith. Is there a workaround?
|
As @hansmbakker suggested, using the dotnet cli is one workaround. Once compiled then VS seems to work. Another option is to copy the AndroidManifest.xml file from the Platforms/Android folder to the same location as the Maui project file. |
I've been hitting this every few days, usually following a branch switch that changes what packages/versions the solution has. |
I am also hitting this issue (seems consistent for now locally). |
+1 unable to build the project using visual studio, but able to build via developer command prompt using msbuild |
Is everyone who hits this using central package versioning? (Or is anyone seeing this without using CPM?) |
I am using CPM yes |
I'm also using CPM indeed. |
Me as well. |
CPM as well |
Did anyone recently update their targeting framework to .net8.0? For me I am suspecting this is due to that. |
I'm also hitting this issue. I have a 2nd Directory.Packages.props in a test folder to add GlobalPackageReferences for test dependencies and while I have this file present, I'm getting the same error as the others. If I remove that file, the error disappears. Possibly related? |
Same issue. CPM, net8-android, Directory.Packages.props - all ingredients are here. |
I encountered this issue when I was uninstalling a particular package. I removed the PackageVersion entry for the library from my Directory.Packages.props but still had the PackageReference for that library in the project. In that state, I received this error. After I removed the PackageReference tag from the projects, the error went away. In the past, when this situation occurred there was a different error message, but I can't quite recall what it used to say. Something about a missing package version I thought, but not positive. |
I have two of the issues described above. First I had some missing package versions, which results in the exception instead of a proper error message. Once I fixed those I was left with one project that I couldn't fix, a .NET MAUI project. This one keeps throwing the exception despite fixing the versioning. Building it from the command line did work however, and after doing that once I can build it from visual studio as well. The tools need to be made more resilient and should be able to properly report edge errors instead of crash. And the issue with android is just a bug in itself. |
Getting this error but it was due to a package that was missing from my
|
Finding a similar issue. Building the project from the CLI with
I notice that my stack trace is slightly different than the one in the main comment as, among other things, it does not mention a |
I'm getting this attempting to compile roslyn on command-line for about 9 of the projects:
Edit: I've saved the state of the VM as a snapshot, so theoretically I should be able to load up that version and repro it later if needed. |
any plans here? I face it constantly, a lot of times every day... This is something very painful. |
@lsoft what version of VS and the SDK are you using? We think this should be resolved in more recent versions of the SDK. |
I hit the issue when was migrating an .msbuildproject to CPM:
|
Microsoft Visual Studio Enterprise 2022 (64-bit) - Current
csproj:
minimal build log:
|
This is ridiculous. |
I see the same issue with the latest SDK
as I posted above, I politely ask about plans here? |
Because I see the error constantly, how can I reproduce this with the sources of SDK inside a Visual Studio? |
after digging a bit, I can confirm that the root of problem is in restoring nuget packages. if I run but if I delete Looks like building inside VS (via msbuild?) do not see the versions from ADDITIONAL NOTE: I have a few nuget packages deploed in my |
so, is there a way to get rid of the error? I did "something" to get this error, but now it won't go away anymore edit; ok never mind, in my case it was caused by a package reference for which no version was specified in my Directory.Packages.Props file |
This just occured on the up to date Microsoft Visual Studio Enterprise 2022 (64-bit) - Current Version 17.11.5. |
Thank you @PaulVrugt. This was helpful! Doing the restore in the command line reported which package it was. Not sure why in VS the restore is crashing. |
@jeffkl did NuGet end up looking into providing a better error experience here or should we? I believe this is a case of null values in the project.assets.json most commonly when onboarding to CPM and not setting a version for everything. |
I believe we fixed NuGet so it won't write |
This was indeed caused by a null in project.assets.json. The null was caused, presumably, by a removed PackageVersion in a central package management Directory.Packages.props but having a PackageReference still looking for it at the .csproj level. It seems like this can happen easily with multiple solutions and dependants on central package management. This could absolutely use a better error message. |
I was trying to update some packages and got into a funky state. The following exception appeared in the VS Error List.
I don't have clear repro steps unfortunately.
The exception appears to be within this block of code:
sdk/src/Tasks/Microsoft.NET.Build.Tasks/ProjectContext.cs
Lines 197 to 210 in 383d2f8
At a glance it seems like either
projectFileDependency
would be the most likely null, meaning a dependency group contains a null dependency, which seems problematic. It might be a bug on the NuGet side. If I see this again, I'll grab a copy of the assets file.The text was updated successfully, but these errors were encountered: