I'm getting
Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'.
in VSTS build using Hosted2017 build agent after I upgraded my aspnetcore app to netcoreapp2.0 and my libraries to use netstandard2.0.
Works fine locally.
I've edited my build definition to use .net core build task v2.* preview:
here is the build log:
Current agent version: '2.120.2'
Download all required tasks.
Downloading task: DotNetCoreCLI
Starting: Get Sources
Syncing repository: Liero/vyvojari-sk (GitHub)
...details ommited
HEAD is now at e448a25... Upgraded to .NET Core 2.0
Finishing: Get Sources
Starting: Restore
==============================================================================
Task : .NET Core
Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command. For package commands, supports NuGet.org and authenticated feeds like Package Management and MyGet.
Version : 2.0.5
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?linkid=832194)
==============================================================================
SYSTEMVSSCONNECTION exists true
Downloading: https://dist.nuget.org/win-x86-commandline/v4.0.0/nuget.exe
Caching tool: NuGet 4.0.0 x64
Using version: 4.0.0
Found tool in cache: NuGet 4.0.0 x64
Saving NuGet.config to a temporary config file.
Can\'t find loc string for key: NGCommon_NoSourcesFoundInConfig
NGCommon_NoSourcesFoundInConfig d:\a\1\Nuget\tempNuGet_734.config
"C:\Program Files\dotnet\dotnet.exe" restore d:\a\1\s\src\CommandStack\CommandStack.csproj --configfile d:\a\1\Nuget\tempNuGet_734.config --verbosity Detailed
Restoring packages for d:\a\1\s\src\CommandStack\CommandStack.csproj...
C:\Program Files\dotnet\sdk\1.0.4\NuGet.targets(97,5): error : Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'. [d:\a\1\s\src\CommandStack\CommandStack.csproj]
Generating MSBuild file d:\a\1\s\src\CommandStack\obj\CommandStack.csproj.nuget.g.props.
Generating MSBuild file d:\a\1\s\src\CommandStack\obj\CommandStack.csproj.nuget.g.targets.
Writing lock file to disk. Path: d:\a\1\s\src\CommandStack\obj\project.assets.json
Restore failed in 115.64 ms for d:\a\1\s\src\CommandStack\CommandStack.csproj.
Errors in d:\a\1\s\src\CommandStack\CommandStack.csproj
Unable to resolve 'NETStandard.Library (>= 1.6.1)' for '.NETStandard,Version=v2.0'.
NuGet Config files used:
d:\a\1\Nuget\tempNuGet_734.config
Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
Packages failed to restore
******************************************************************************
Finishing: Restore
******************************************************************************
and here is the source code: https://github.com/Liero/vyvojari-sk/tree/e448a25fb8c481704e9102aaaeb8b84b9aee7b02
Update 18/09/2017
Step 2 is no longer needed. I've left it in the solution though as it may still help some people. Thanks, #Liero for point this out.
Original Answer
I've just experienced this problem too and solved it by doing three things:
Use the .NET Core SDK(! - not runtime!) version 2.0.0:
Use the latest NuGet feed (4.3.0):
Restore your packages:
Update
It's worth mentioning here that you should specify where you get your NuGet packages from. Most applications will probably just use the NuGet.org feed, as per the screenshot (see small checkbox), but you may have your custom feeds specified in a NuGet.config file. In that case, tick 'Feeds in my NuGet.config' and then specify the path to that file.
To illustrate the order, this is my working queue:
I hope this helps you and anyone else who has come up against this problem. If you have any questions, let me know. :)
You should select Feed(s) I select here for Feeds to use option. If you leave Use packages from this VSTS/TFS feed empty, packages will be downloaded from https://dist.nuget.org/.
Else, if you want to use Feeds in my NuGet.config as Feeds to use, you should specify the path for your NuGet.config file.
I have received a similar error after generating a project using dotnet new angular which created a project relying on netcoreapp2.0. Inspection of project properties revealed that version 2.0 was not properly recognized (did not appear in the installed framework list).
Solution was to update Visual Studio 2017, as the minimum version required to support netcoreapp2.0 projects seems to be 15.3.1.
What worked for me was installing .NET Core SDK 2.0 and making the following changes:
in .csproj:
change
<TargetFramework>netcoreapp1.1.0</TargetFramework>
to
<TargetFramework>netcoreapp2.0</TargetFramework>
and in global.json:
"sdk": { "version": "1.1.0" }
to
"sdk": { "version": "2.0.0" }
I didn't know how to use Chris Paton' solution
Updating the Visual Studio 2017 to latest 15.4.1 version resolved the problem for me.
Related
We have Xamarin.Forms solution with iOS and UWP projects. We use Azure pipelines to build the iOS project. Until yesterday everything was working fine.
Now the build fails at the NuGet Restore step with the error:
##[error]The nuget command failed with exit code(1) and error(/Users/runner/work/1/s/"MyProjectName.UWP".csproj : error MSB4057: The target "_IsProjectRestoreSupported" does not exist in the project.
We can see that the problem occurs when trying to restore NuGet packages for the UWP project on the Mac OS build host.
Image: macOS-11
Workaround will be to exclude it from the solution, but we are using it for testing purposes and this is not a good option for us.
We had the same problem yesterday for our iOS (macos-11) and Android (macos-10.15) Pipelines.
The issue 21180 for mono seems to be the root cause, which is also referenced in a pull request to update the mono version for MacOs virtual environments. Regarding to this workflow test we gave msbuild a chance, and it works.
Solution:
Instead of NuGet restore we use directly MSBuild.
- task: MSBuild#1
inputs:
solution: 'App.sln'
configuration: 'Release'
msbuildArguments: /t:restore
Looking at the log file, MSBuild ignores the UWP project. That is the behavior that NuGet had with the older mono version 6.12.0.125. Ignoring the UWP-Project is no problem, because it can only be build on windows environments.
Project "/Users/runner/work/1/s/App.sln" on node 1 (Restore target(s)).
ValidateSolutionConfiguration:
Building solution configuration "Release|Any CPU".
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/NuGet.targets(315,5): warning : Skipping restore for project '/Users/runner/work/1/s/App/App.UWP/App.UWP.csproj'. The project file may be invalid or missing targets required for restore. [/Users/runner/work/1/s/App.sln]
Some additional information:
The NuGet restore task uses msbuild to find all referenced packages. If that fails, it will use the packages.config file as fallback, the pipeline step will not fail.
Instead we got an error in the build steps for Android & iOS:
error NETSDK1004: Assets file
'/Users/runner/work/1/s/../obj/project.assets.json' not found. Run a
NuGet package restore to generate this file.
Updated Answer
This can be resolved using MSBuild task instead, as the collogues mentioned below.
However, in my case this still lead to the same error. After investigating the pipeline. The root cause has been identified:
Both in MSBuild#1 and XamariniOS#2 tasks
you should target the specific iOS Project and not the solution file, like so:
"
- task: MSBuild#1
inputs:
solution: 'PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
msbuildArguments: /t:restore
" - task: XamariniOS#2
inputs:
solutionFile: PathToIosProject/myproject.iOS.csproj'
configuration: '$(BuildConfiguration)'
packageApp: true
signingIdentity: $(APPLE_CERTIFICATE_SIGNING_IDENTITY)
Old Answer
We have managed to resolve the issue. The root cause of it seems to be an update to the mono framework in the MacOS pipeline build agent.
In order to fix it, we need a script for downloading and installing an older version of the mono framework as a first step of the build pipeline like so:
link to the pipeline tasks photo
This is the code of the bash scrip used in the task:
#!/bin/bash
set -ex
MONO_MACOS_PKG_DOWNLOAD_URL='https://download.mono-project.com/archive/6.12.0/macos-10-universal/MonoFramework-MDK-6.12.0.100.macos10.xamarin.universal.pkg'
mkdir -p /tmp/mono-install
cd /tmp/mono-install
mono --version
wget -q -O ./mono-installer.pkg "$MONO_MACOS_PKG_DOWNLOAD_URL"
sudo installer -pkg ./mono-installer.pkg -target /
mono --version
ls -alh /Library/Frameworks/Mono.framework/Versions/Current
I have a .NET Core Web Application with target framework .netcoreapp2.0.
If i publish my application via Visual Studio (folder profile) I get a different Newtonsoft.Json.dll then with the command dotnet publish --configuration Release --output D:/publish/Frontend /property:PublishWithAspNetCoreTargetManifest=false
VS publish version:
dotnet publish version:
The created file AutomaticConfirmationWebfrontend.deps.json has always this dependency:
"runtime": {
"lib/netstandard1.3/Newtonsoft.Json.dll": {
"assemblyVersion": "10.0.0.0",
"fileVersion": "10.0.1.20720"
}
}
This results in a problem for my CI/CD process where I publish my app with the command dotnet publish. If I open the website I get an error message that the assembly Newtonsoft.JSON 10.0.0.0 could not be found. If i copy manually the DLL with version 10.0.0.0 to the application folder it works! Debugging my application locally works also fine!
I have no Newtonsoft NuGet package installed. I think I am using the built in package from .NET Core.
In my Startup.cs I have the following line of code:
services.AddJsonOptions(options => options.SerializerSettings.ContractResolver = new DefaultContractResolver());
I need this for lowercase JSON objects. I have imported this namespace:
using Newtonsoft.Json.Serialization
Anybody an idea what I'm doing wrong or how to fix this?
I did 3 steps:
Upgraded to netcoreapp3.1
Removed all nuget packages from C:\Users\******\.nuget\packages
Installed the latest MSBuild installer
Late answer but it may help someone in future. Within the solution some other (other project) NuGet package also depending Newtonsoft.Json.dll. Check all your NuGet package dependencies especially Testing projects which may be mapped with low version Newtonsoft.Json.dll. (Refer below pic).
If that is the problem, then you can map .csproj file in your publish command like below,
dotnet publish src/myproject.csproj --configuration Release --output D:/publish/Frontend /property:PublishWithAspNetCoreTargetManifest=false
I have ported a .net application to .netcore and want to publish it as a self-contained application. Unfortunately, this does not work:
dotnet publish -r win-x64
Microsoft (R) Build Engine version 16.4.0+e901037fe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
<Path>\IPLauncher.csproj : error NU1100: Unable to resolve 'Microsoft.NETCore.App.Runtime.win-x64 (= 3.1.2)' for '.NETCoreApp,Version=v3.1'.
<Path>\IPLauncher.csproj : error NU1100: Unable to resolve 'Microsoft.WindowsDesktop.App.Runtime.win-x64 (= 3.1.2)' for '.NETCoreApp,Version=v3.1'.
<Path>\IPLauncher.csproj : error NU1100: Unable to resolve 'Microsoft.AspNetCore.App.Runtime.win-x64 (= 3.1.2)' for '.NETCoreApp,Version=v3.1'.
Restore failed in 179,65 ms for <Path>\IPLauncher.csproj.
In case it is important, my csproj-file looks like this:
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<UseWindowsForms>true</UseWindowsForms>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
Edited to add: The weirdest part is that my colleague can publish a self-contained exe for the same project with identical configuration - so it seems to be some problem with my configuration.
It seems like nuget restore command for your application can't restore some packages.
There are many reasons for that, but you can do basic research for determine why it's heppens. Here some tips:
Clear all NuGet caches dotnet nuget locals all --clear
Check if NuGet packages you trying to restore accessible from nuget.org website. Official nuget package manager website has different API's (v2/v3) so you must check you use latest version of API.
If you use NuGet package not from official portal - verify that NuGet server you use for restoring nuget packages is accessible.
These settings placed in default nuget.config file here: %appdata%\NuGet\NuGet.config
Note that if you using custom nuget.config for your project/solution it's overrides default nuget settings. This file can contains some settings that breaks restore command. So check it out first.
I have a solution that contains a number of csproj's.
In my CI, I want all csproj to build both a pre-release package, with the build number as prerelease string, and a release package with the regular version number.
Later, in a release step, I want to push all pre-release packages automatically, and be able to make a manual release for each release package individually.
My csproj file contains
<VersionPrefix>1.8.0</VersionPrefix>
<VersionSuffix>$(VersionSuffix)</VersionSuffix>
From the CLI, I would build a pre-release version with dotnet pack --version-suffix foo to build version 1.8.0-foo, and use dotnet pack without additional arguments to build version 1.8.0
I'm trying to use the .net Core 2.* build task. I'm seeing automated versioning under pack options/automatic versioning, but those seem to ignore the version prefix in the csproj file.
How do I configure things so that the same csproj can be built in to a pre-release package in one task, and into a release nuget package in another, that differ only in that one has a version suffix set to the build number, and the other without a version suffix?
EDIT:
I tried setting VersionSuffix=bar in additional properties, but this gave me a rather uninformative error:
log:
2018-05-07T10:31:27.1536721Z [command]C:\Windows\system32\chcp.com 65001
2018-05-07T10:31:27.1629285Z Active code page: 65001
2018-05-07T10:31:28.1487070Z [command]"C:\Program Files\dotnet\dotnet.exe"
pack D:\a\1\s\path\to\some.csproj --output D:\a\1\a /p:Configuration=release;$VersionSuffix=bar --verbosity Detailed
2018-05-07T10:31:28.3350467Z Microsoft (R) Build Engine version 15.6.84.34536 for .NET Core
2018-05-07T10:31:28.3351167Z Copyright (C) Microsoft Corporation. All rights reserved.
2018-05-07T10:31:28.3351324Z
2018-05-07T10:31:28.4870038Z ##[error]Error: C:\Program Files\dotnet\dotnet.exe failed with return code: 1
2018-05-07T10:31:28.4881392Z ##[error]An error ocurred while trying to pack the files.
Just add additional task for pre-release package:
.NET Core task (Automatic package versioning: Off)
.NET Core task (Automatic package versioning: Off; Additional build properties: VersionSuffix=foo)
After upgrading my app to version 1.0.1 like this in project.json:
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
This works under Windows but not under Linux.
Under Linux I get this error:
Project BackendGems (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
Project test (.NETCoreApp,Version=v1.0) was previously compiled. Skipping compilation.
The specified framework 'Microsoft.NETCore.App', version '1.0.1' was not found.
- Check application dependencies and target a framework version installed at:
/opt/dotnet_cli/shared/Microsoft.NETCore.App
- The following versions are installed:
1.0.0
- Alternatively, install the framework version '1.0.1'.
SUMMARY: Total: 1 targets, Passed: 0, Failed: 1.
I tried to delete the nuget cache and made sure I have the same SDK version 1.0.0-preview2-003121.
What can possible be wrong?
The change that you have done on the project.json forces your app to run on a runtime version >=v1.0.1 or else fail.
dotnet restore updates the dependencies but not the runtime.
So, you just have to install the 1.0.1 runtime in /opt/dotnet_cli/shared/Microsoft.NETCore.App as the error message states.
Each linux distro has different installation instruction on .NET site, so it may be your case that you can do something like 'apt-get install dotnet-dev-1.0.1'
But for Debian, I had to do it manually:
Get the link and download .NET Core binaries only (v1.0.1) from https://www.microsoft.com/net/download#core
$ wget https://go.microsoft.com/fwlink/?LinkID=825887 -O dotnet-1.0.1.tar.gz
Restore it on /opt/dotnet_cli/shared/Microsoft.NETCore.App
tar zxvf dotnet-1.0.1.tar.gz -C /opt/dotnet_cli/
And now dotnet run works as expected.
EDIT: Looks like MS is updating the download page right now, so you will find the file to download labeled as .NET Core binaries only now (no mention to 1.0.1). But the file is still the same one.