Predefined type 'System.Void' is not defined or imported during Visual Studio Online build of ASP.NET 5

Question

I get this error when I try to build the project in Visual Studio Online:

…\Frontend\Startup.cs(65,49): Error CS0518: Predefined type 'System.Void' is not defined or imported
…\Frontend\Startup.cs(65,49): DNXCore,Version=v5.0 error CS0518: Predefined type 'System.Void' is not defined or imported [C:\a\1\s\Frontend\src\Frontend\Frontend.xproj]

It seems that the error happens in the place where I reference another library (package class library).

P.S. I had some conversation about this here: Easy way to build and deploy (to Azure) ASP.NET 5 in Visual Studio Team Services, but there was no answer after all, so I still cannot build it...

Web project.json:

"dependencies": {
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
    "Web.Common": "1.0.0-*"
},

"frameworks": {
    "dnx451": { },
    "dnxcore50": { }
},

Library project.json

"frameworks": {
    "dnx451": { },
    "dnxcore50": {
        "dependencies": {
            "Microsoft.CSharp": "4.0.1-beta-23516",
            "System.Collections": "4.0.11-beta-23516",
            "System.Linq": "4.0.1-beta-23516",
            "System.Runtime": "4.0.21-beta-23516",
            "System.Threading": "4.0.11-beta-23516"
      }
    }
  },
"dependencies": {
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final"
  }

Update (problem and solution):

The problem was in the fact that my library reference was not in the same folder and the script by default does not run dnu-restore there, so I had to go one level up and start finding project.json recursively there

$SourceRoot = Split-Path -Path $PSScriptRoot -Parent

# run DNU restore on all project.json files in the src folder including 2>1 to redirect stderr to stdout for badly behaved tools
Get-ChildItem -Path $SourceRoot -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 }

Thanks Eddie - MSFT for help!

Braud

I think you are missing a dependency on the "System.Runtime" package. – Cathleencathlene

Where should I have this dependency? It's not by default in project.json in web project and it exist for coreclr, but not for clr in the library. P.S. Everything builds locally in VS by the way – Braud

Can you share the "dependencies" and "frameworks" section in project.json file? – Scalawag

I have added it to the post, I have changed the library target framework to match the web one because of R# issues (it does not find them as the same otherwise), but I have tried changing it back and it did not help either. I guess it should work properly with these web targets anyway as they are only more restrictive as far as I understood. – Braud

Answer 1

I just reproduced this issue after updating the code in "PreBuild.ps1" script to only restore the "project.json" file for web project.

Original Code (Build Success):

Get-ChildItem -Path $PSScriptRoot\src -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 }

Updated Code (Build fail with: Predefined type 'System.Void' is not defined or imported):

Get-ChildItem -Path $PSScriptRoot\src\WebProjectName -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 }

So you need to check the PreBuild.ps1 script and the build logs for PowerShell step to check if the project.json files for Web project and Library project are both restored.

Scalawag

I am afraid I have the full \src in the Prebuild.ps1: Get-ChildItem -Path $PSScriptRoot\src -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 } – Braud

@IlyaChernomordik Then check the build logs to see if the project.json file for Library project is been restored. – Scalawag

Let me check, can it happen that my project structure causes it? I have one project in \Frontend, the other (library) is not in the same folder but in \Common\Library – Braud

@IlyaChernomordik Yes. By default, the web project and library project are both placed under "src" folder. So the PreBuild.ps1 script can restore the project.json for both of them by default. If the library project is placed in other location, the project.json file won't be restored with that script by default. – Scalawag

I guess that is the problem then... The manual on how to do that did not really mention these details... I did put it in a common folder because it's a library that is going to be reused between different solutions so it's not quite correct... In the logs I have that: "Restoring packages for C:\a\1\s\Frontend\src\Frontend\project.json", but not for the other one, I suppose I'll have to amend the script a bit – Braud

It is really strange that this dnu restore does not work on references properly and you have to think about it yourself... Like in the old build you just reference a project and then it is built if your's depend on it this way – Braud

Thanks a lot for the help! This fixed the issue with the void problem, so the build passes, got dozen errors with npm on prebulish step now though :( – Braud

Answer 2

Restart visual studio it will resolve the problem. It was the case for me.

Weinert

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Reamy

For what it's worth, @YanSklyarenko, it gave me the idea of restarting VS and my "system.void is not defined" error went away. So, thank you, Jean BIDI – Ogata

@YanSklyarenko - great answer for me as well. – Leelah

Answer 3

In my own issue, I rebuilt the entire solution and the errors just disappeared.

Edit:

This is most likely due to NuGet package restored.

Ambi

To be fair, I experienced the same problem just now (only difference being that I was using the desktop edition of visual studio) and rebuilding the whole solution did indeed fix the "error". This suggestion somehow actually make sense... I fear the problem is just caused by some bug VS has with the "error cache?" – Hudspeth

For me worked Clean, Rebuild, and then restart Visual Studio – Cheshire

I also had to update some nuget packages to get it fixed. – Clerical

Answer 4

Simply running dotnet restore in your terminal should solve the issue.

Affected

Simple and helpful solution! – Diatonic

Worked for me. Still not sure what and where the problem was. – Godly

Best solution for me – Osber

Answer 5

In my experience, I deleted the bin and obj folder and it worked. Try closing the visual studio as well (if bin and obj folders are locked). However, for my colleague he deleted the entire solution folder and got the latest from TFS. He then compiled and rebuilt the solution and it worked.

Chromatography

That helped me with Visual Studio 2022 – Gretagretal

Answer 6

I just experienced this issue in a Asp.NET Core 6 solution with several .NET Core 6 libraries.

Restarting VS 2022 didn't clear up the issue.

What did fix it? Deleting the contents of the main project's Bin and Obj directories. Then restarting Visual Studio.

Mojica

Deleting folders didn't clear up the issue. – Weissman

It definitely did for me. I suspect, based on the range of answers here, that there are several different root causes that can result in this same error. So if deleting the contents of the Bin and Obj folders didn't fix it for you then perhaps one of the other solutions will work for you. – Mojica

work for me! My issue happened after VS 2022 updated. – Camphene

Answer 7

I had this problem after upgrading my VS2022, and my solution is:

1. close visual studio
2. delete the .vs folder
3. restart the visual studio
4. launch projects from the .sln file

Everything should then work fine.

Wulfe

Answer 8

Please remove bin and obj folders and rebuild.

Hunan

Answer 9

Updating the NuGet Packges fixed the issue for me. Project > Manage NuGet Packages > Updates > Update All

Paddle

Answer 10

I'm adding my own experience with that bug/issue.

Form my part I had to remove "System.Xml.XDocument": "4.0.10" from project.json to resolve the problem

Boring

Answer 11

My issue was being too trigger happy with the resharper import recommendations which had resulted in mscorlib.dll being manually referenced in the project. Removing it cleared everything up.

Cellule

When I pass away, I want it inscribed on my tombstone that 'His cause of death was deleting the bin and obj folders and then cleaning and rebuilding the solution an infinite number of times' ... Please come back Digital and OpenVMS - all is forgiven ... – Unbiased

Answer 12

I had this error after GIT-Extensions Pull command.

After remove all write-protect attributes in the solution, the problem is solved.

Ferrand

Answer 13

In my case, the problem seemed to be that the dotnet sdk was not being found. On my Mac the sdks are in

/usr/local/share/dotnet/sdk

and I have version 7.0.102 there.

I adjusted the OmniSharp settings:

1. Enable OmniSharp: Use Modern Net
2. Specify the dotnet version in Omnisharp: SDK version, I specified 7.0.102

It's easier to find these two options if you specify "modern" in the settings search bar.

When I made those changes I was prompted to restart OmniSharp and immediately all the red warnings went away.

I have not experimented with variations of those settings, clearly it's not ideal to specify a specific dotnet version.

Comitia

Answer 14

Restarting Visual Studio worked for me, I haven´t gotten that problem since.

Sextillion

Answer 15

In my case I was pointing to the wrong SDK version

Handmade