Using NuGet.exe 5.5.1.6542 on a PC with Visual Studio 2019 and Visual Studio Build Tools 2019 (2) installed on a German Windows 10 64-bit PC.
Having the following command line call:
"c:\P\KM\_Build\NuGet.exe" Update "c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj"
First brings this output:
MSBuild auto-detection: using msbuild version '16.5.0.12403' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin'.
Then, it runs fine on one PC and brings the following (German) error on another PC:
Die Toolsversion "Current" ist unbekannt. Verf眉gbare Toolversionen sind "2.0", "3.5", "4.0". c:\PKM\BaseLibrarySource\BaseLibrary\BaseLibrary.csproj
Translated manually to English, this reads:
The tools version "Current" ist unknown. Available tool versions are "2.0", "3.5", "4.0". c:\PKM\BaseLibrarySource\BaseLibrary\BaseLibrary.csproj
The CSPROJ that generates the error is a .NET Framework 4.7.2 class library that builds successfully in Visual Studio 2019 on both PCs.
The verbose log looks like this:
C:\P\KM\_Build>"c:\P\KM\_Build\NuGet.exe" Update "c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj" -verbosity detailed
NuGet Version: 5.5.1.6542
MSBuild auto-detection: using msbuild version '16.5.0.12403' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\bin'. Use option -MSBuildVersion to force nuget to use a specific version of MSBuild.
Die Toolsversion "Current" ist unbekannt. Verf眉gbare Toolversionen sind "2.0", "3.5", "4.0". c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj
Microsoft.Build.Exceptions.InvalidProjectFileException: Die Toolsversion "Current" ist unbekannt. Verf眉gbare Toolversionen sind "2.0", "3.5", "4.0". c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj
bei Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
bei Microsoft.Build.Evaluation.Project.Data.InitializeForEvaluation(IToolsetProvider toolsetProvider, IFileSystem fileSystem)
bei Microsoft.Build.Evaluation.Evaluator`4..ctor(IEvaluatorData`4 data, ProjectRootElement projectRootElement, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean profileEvaluation, Boolean interactive)
bei Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project..ctor(String projectFile)
I tried to reproduce this issue in my machine on English and Germany cultures and also on a new VM with Germany culture with VS 2019 IDE and VS 2019 build tools installed. My tests so far did not report the exception that is mentioned above.
MSBuild auto-detection: using msbuild version '16.5.0.12403' from 'C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\MSBuild\Current\Bin'.
Feeds used:
https://api.nuget.org/v3/index.json
Please try VS repair operation on the PC where you are experiencing this issue and let us know the result.
Thank you very much for your efforts, @kartheekp-ms.
I've just tried to repair both installations:

I did a reboot after each repair.
Unfortunately, the error persists.
I would even go with a complete new install of the Windows machine, I just fear that the error would be there, again, if I don't know the actual cause.
What is confusing to me is that in your output it states:
...Feeds used: https://api.nuget.org/v3/index.json
Whereas in my scenario this is omitted.
Can you think of a reason why this is the case?
In any case, if this helps, when calling this:
"c:\P\KM\_Build\NuGet.exe" Sources
it outputs these sources:
Registered Sources:
1. nuget.org [Enabled]
https://api.nuget.org/v3/index.json
2. Zeta [Enabled]
http://nuget.zeta-sw.com:81/nuget
3. CliFallbackFolder [Enabled]
C:\Users\ukeim\.dotnet\NuGetFallbackFolder
4. DevExtreme [Enabled]
https://nuget.devexpress.com/L432xFO6Jil59NpbDI9RU4KstOBVaRwjphgz5kZer1ttOBn7no/api
5. DevExpress 18.2 Local [Disabled]
C:\Program Files (x86)\DevExpress 18.2\Components\System\Components\Packages
6. Microsoft Visual Studio Offline Packages [Enabled]
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\
7. DevExpress 19.1 Local [Enabled]
C:\Program Files (x86)\DevExpress 19.1\Components\System\Components\Packages
8. Telerik [Disabled]
https://nuget.telerik.com/nuget
9. DevExpress 19.2 Local [Enabled]
C:\Program Files (x86)\DevExpress 19.2\Components\System\Components\Packages
10. VistaDB 6 [Enabled]
C:\Program Files (x86)\Gibraltar Software\VistaDB 6\Packages\
Could it be that the sources are a cause of this issue?
Are there any other global/local NuGet settings that might be the cause of my issue?
It seems to me that the config command cannot be used to show the currently configured value.
@rainersigwald - I really appreciate your feedback regarding this issue.
@UweKeim - As per my current understanding, nuget update command writes feeds used to the console after MSBuild logic executed successfully. Please try running the nuget update command by passing additional parameter MSBuildPath referring to the msbuild.exe from VS 2019 installation directory.
For e.g. in your case the nuget update command can be as follows.
C:\P\KM\_Build>"c:\P\KM\_Build\NuGet.exe" Update "c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj"
-MSBuildPath "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin" -verbosity detailed
Thank you, @karann-msft
This is the whole output:
c:\P\KM\_Build>"c:\P\KM\_Build\NuGet.exe" Update "c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj" -MSBuildPath "c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin" -verbosity detailed
NuGet Version: 5.5.1.6542
Using Msbuild from 'c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin'.
Die Toolsversion "Current" ist unbekannt. Verf眉gbare Toolversionen sind "2.0", "3.5", "4.0". c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj
Microsoft.Build.Exceptions.InvalidProjectFileException: Die Toolsversion "Current" ist unbekannt. Verf眉gbare Toolversionen sind "2.0", "3.5", "4.0". c:\P\KM\BaseLibrary\Source\BaseLibrary\BaseLibrary.csproj
bei Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
bei Microsoft.Build.Evaluation.Project.Data.InitializeForEvaluation(IToolsetProvider toolsetProvider, IFileSystem fileSystem)
bei Microsoft.Build.Evaluation.Evaluator`4..ctor(IEvaluatorData`4 data, ProjectRootElement projectRootElement, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean profileEvaluation, Boolean interactive)
bei Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCacheBase projectRootElementCache, BuildEventContext buildEventContext, ISdkResolverService sdkResolverService, Int32 submissionId, EvaluationContext evaluationContext, Boolean interactive)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.Reevaluate(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.ReevaluateIfNecessary(EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project.ProjectImpl.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings, EvaluationContext evaluationContext)
bei Microsoft.Build.Evaluation.Project..ctor(String projectFile)
(I'm using Community edition on both PCs, the one where it is working, as well as the one where it is not working).
I have to add that I have tons of other CSPROJ files in other VS solutions that work successfully. It is just this one CSPROJ in the above ZIP file attachment that generates the error on my machine.
Very interesting/confusing/surprising, especially if it's just for one specific project. This is an error that I'd expect to see if NuGet tried to use MSBuild 4.0 from the .NET Framework, instead of the newer one from Visual Studio. But of course the logging indicates that it is using MSBuild from VS.
@UweKeim can you download and run https://github.com/microsoft/msbuild/blob/master/scripts/EnumerateMSBuild.ps1 and share the results?
I'm also curious if the right MSBuild is really being loaded. Not sure the best way to find that out, we may have to resort to a procmon or fusion log trace.
Thanks, @rainersigwald .
I just ran the script as Administrator with this command line:
PS C:\WINDOWS\system32> C:\Ablage\EnumerateMSBuild.ps1
Using vswhere from C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe
Found VS Instance: VisualStudio/16.5.4+30011.22
Looking for legacy MSBuild versions: C:\Program Files (x86)\MSBuild\
Looking for MSBuild in the GAC: C:\WINDOWS\Microsoft.NET\assembly
Looking for MSBuild in the GAC: C:\WINDOWS\assembly
Output saved to C:\WINDOWS\system32\msbuild_versions.txt
PS C:\WINDOWS\system32>
This is the result file: msbuild_versions.txt
I'll now try Process Monitor and will post the results if I can catch the MSBuild process being started.
OMFG! I found the cause!
Someone (not me!) put a file "Microsoft.Build.dll" (file version 16.4.0.56107) in the very same folder as the "NuGet.exe" ("c:\PKM_Build\NuGet.exe").
When deleting this "Microsoft.Build.dll", the initial NuGet update call runs successfully.
This is so embarassing to me that I wasted your time on something that is completely my/our fault. Please take my deepest apologies for that.
I'm now going the find the guy that did that and have a talk with him 馃拃.
Someone (not me!) put a file "Microsoft.Build.dll" (file version 16.4.0.56107) in the very same folder as the "NuGet.exe" ("c:\PKM_Build\NuGet.exe").
When deleting this "Microsoft.Build.dll", the initial NuGet update call runs successfully.
This is so embarassing to me that I wasted your time on something that is completely my/our fault. Please take my deepest apologies for that.
Nice work! I don't think I've seen this problem before but it makes total sense . . . _after_ it's been found and explained.
I'm now going the find the guy that did that and have a talk with him 馃拃.
Go easy :)
Thanks again, Rainer and Kartheek for your awesome help!
Most helpful comment
Nice work! I don't think I've seen this problem before but it makes total sense . . . _after_ it's been found and explained.
Go easy :)