Error NETSDK1004 occurs when building any C++/CLI project.

walterlv commented 1 year ago

Describe the bug

When building any C++ project using the CLR Class Library (.NET) template, the project cannot be successfully built with the MSBuild command line. Instead, it can only be successfully built using Visual Studio 2022. An error, NETSDK1004, occurs when attempting to build the project with MSBuild.

error NETSDK1004: Assets file 'obj\project.ass
ets.json' not found. Run a NuGet package restore to generate this file.

To Reproduce

Open Visual Studio 2022 (17.5.3, or 17.6.0 Preview 2.0)
Create a new C++ project using the CLR Class Library (.NET) template
Create Git Repository for this solution with default .gitignore template
Close the Visual Studio instance
‼️important‼️ Use git clean -xdf to clean the entire repo, excluding the project files
Open the Terminal and use msbuild -restore to build the solution

Here is a repository containing only the newly created project.

https://github.com/walterlv/Walterlv.IssueDemo.MSBuildNETSDK1004

Exceptions

Here's the output:

  C:\Program Files\dotnet\sdk\7.0.300-preview.23122.5\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolut
ion.targets(266,5): error NETSDK1004: Assets file 'D:\WIP\Desktop\Walterlv.IssueDemo\Walterlv.IssueDemo\obj\project.ass
ets.json' not found. Run a NuGet package restore to generate this file. [D:\WIP\Desktop\Walterlv.IssueDemo\Walterlv.Iss
ueDemo\Walterlv.IssueDemo.vcxproj]

    0 Warning(s)
    1 Error(s)

If you want more detail output, I'll post it here.

Known Workarounds

If we open the solution with Visual Studio 2022, simply opening it will ensure that the MSBuild command line works correctly. Opening the project using Visual Studio will create some files within the project, and even after Visual Studio is closed, the MSBuild command line will still function properly.
When building a C++ project using the CLR Class Library (.NET Framework) template, the MSBuild command line works as expected.

By referring to the official documentation, we can find a workaround by using this command line: devenv SolutionName.sln /Build.

Further technical details

I've tested this issue in two Windows machines and both failed:

.NET SDK 7.0.202 + Visual Studio 2022 (17.5.3)
.NET SDK 7.0.300-preview.23122.5 + Visual Studio 2022 (17.6.0 Preview 2.0)

Here is an info of the 7.0.202 one:

$ dotnet --info
.NET SDK:
 Version:   7.0.202
 Commit:    6c74320bc3

运行时环境:
 OS Name:     Windows
 OS Version:  10.0.22621
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\7.0.202\

Host:
  Version:      7.0.4
  Architecture: x64
  Commit:       0a396acafe

.NET SDKs installed:
  5.0.400 [C:\Program Files\dotnet\sdk]
  6.0.102 [C:\Program Files\dotnet\sdk]
  8.0.202 [C:\Program Files\dotnet\sdk]

dotnet-issue-labeler[bot] commented 1 year ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

gureedo commented 1 year ago

Temporary workaround: remove <EnableManagedPackageReferenceSupport>true</EnableManagedPackageReferenceSupport> from your project.

marcpopMSFT commented 1 year ago

@olgaark @nkolev92 as this looks related to package reference support in cppcli projects. Does msbuild -restore not correctly call nuget?

marcpopMSFT commented 1 year ago

Got more details from @lukka offline. Specifying the individual project (msbuild /t:restore project.vcxproj) or disabling package reference support should work around this for now. Full support should be coming in 17.7.

GitDaBytes commented 1 year ago

FYI - this is also affecting any .NET 6 C++ / CLR projects. All of the above hold true. setting false stops the project compiling in VS2022, but does allow the build to work in our DevOps Build Pipeline.

the error from VS2022 is error : Your project does not reference ".NETCoreApp,Version=v6.0" framework. Add a reference to ".NETCoreApp,Version=v6.0" in the "TargetFrameworks" property of your project file and then re-run NuGet restore.

Attempting the other workaround msbuild /t:restore project.vcxproj appears to only restore pure csharp projects referenced by my C++ dll, and does not generate an assets file for the C++ project.

bharath-brat commented 1 year ago

Facing the same issue Build pipelines are failing error NETSDK1004: Assets file 'C:\Projects\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.

For C++/CLR with .Net core 7.0

msbuild /t:restore project.vcxproj will only restore the .Net project referenced by CLR

But building the project in visual studio restores both CLR and .Net project

lukka commented 1 year ago

@gureedo @walterlv @GitDaBytes @bharath-brat thanks for reporting the issue! FYI in Visual Studio 2022 17.7 Preview 2 (released today) there are fixes for CLR .NET projects (aka C++/CLI projects), in particular the projects participating in NuGet's PackageReference (that is <EnableManagedPackageReferenceSupport>true</>), are now nuget-restored correctly (not skipped anymore), and also they follow correctly the compatibility rules for the TargetPlatformMoniker (identifier and version).

Let us know if you can try it out and report any feedback, thank you.

Sai-gitacc commented 1 year ago

@lukka Installed Visual Studio 2022 17.7 Preview 4. I still see there is a dependency with the json file even though this (EnableManagedPackageReferenceSupport - true) available in vcxproj. So the issue doesn't seem to be resolved. Or am I missing something? Can you please let me know.

lukka commented 1 year ago

@Sai-gitacc thank you for reaching out! Could you please create and provide a minimal repro of the problem, with a description of what problem are you hitting? Usually the easier way for doing it is to attach your repro project to a new ticket you can create on Visual Studio's Developer Community. Usually we need to see what is your expectation, what is the actual behavior which differs from the expectation, and the steps to follow to reproduce the issue. Let me know, thank you.

walterlv commented 1 year ago

I've performed tests on this repository with the 17.7.0 Preview 4.0 version and I am pleased to report that the issue has been addressed successfully. Thank you for your diligent efforts in resolving this.

ryanbinnsrv commented 1 year ago

Not exactly the same, but related. If you set EnableManagedPackageReferenceSupport in an older project targeting .NET Framework (ours was targeting v4.7.2), you get a very cryptic error message:

NU1201: Project Imaging is not compatible with net472 (.NETFramework,Version=v4.7.2). Project Imaging supports: native (native,Version=v0.0)

Removing this setting also fixed that. It's not supported on projects targeting .NET Framework, but is enabled by default by VS. Previous versions of VS ignored this setting, but v17.7.0 raises an error.

lukka commented 1 year ago

@ryanbinnsrv thank you for the heads up! Would you be able to provide a sample project which reproduces the problem? I see that the <EnableManagedPackageReferenceSupport> property is inappropriately set to true for .NET Framework CLR projects, but that should not trigger a build failure.

ryanbinnsrv commented 1 year ago

@lukka Attached is a minimal set of two projects that reproduces the issue. Both projects target .NET Framework 4.7.2, but the .vcxproj has the <EnableManagedPackageReferenceSupport> property set to true. If you run nuget restore Solution.sln from the command line, you'll see the error. Note that the projects won't actually build because they have no files in them, but they should get past the nuget restore stage.

If I remove the <EnableManagedPackageReferenceSupport> property, the nuget restore succeeds. Test.zip

lukka commented 1 year ago

@ryanbinnsrv thank you, the problem will be fixed in VS 17.8. In order to allow the community to raise the importance of this issue, I created a Feedback Ticket at https://developercommunity.visualstudio.com/t/VS-attempts-to-nuget-restore-a-newly-c/10444084 which is used to ponder whether backport to VS 17.7.

lukka commented 11 months ago

@ryanbinnsrv @walterlv and all: let me know if you are experiencing any problem with CLR .NET projects that leverage NuGet's <PackageReference>. The problems reported in this issue should all be solved in upcoming VS 17.8 (not GA yet as of today). You may try and verify on VS 17.8 Preview.

@marcpopMSFT this issue may be closed if we have positive reaction to this message.

ryanbinnsrv commented 11 months ago

@ryanbinnsrv @walterlv and all: let me know if you are experiencing any problem with CLR .NET projects that leverage NuGet's <PackageReference>. The problems reported in this issue should all be solved in upcoming VS 17.8 (not GA yet as of today). You may try and verify on VS 17.8 Preview.

@marcpopMSFT this issue may be closed if we have positive reaction to this message.

We fixed this issue by removing the <EnableManagedPackageReferenceSupport> property from our .vcxproj projects. We have no need for it, so probably won't see any difference. If I get chance, I'll checkout the code revision that had the problem and see if it compiles successfully now.

mcr222 commented 1 month ago

This problem still happens in Azure Pipelines with a Hosted Agent, using windows-2022 (latest). I am seeing this when the is set to true (when false I do not see the error but then I am missing libraries I need for my C++/CLI projects.

mcr222 commented 1 month ago

It seems related to the NuGet pipeline restore... I reported it here https://developercommunity.visualstudio.com/t/NuGet-Command-not-restoring-CCLI-vcx/10734595

dotnet / sdk