Context
After migrating to version 3.1.420 of dotnetcore SDK (installed automatically by Windows Update) we are facing the problem, that a solution failed to build (on a build server) because nuget restore is unable to restore the package Microsoft.NETCore.App.Host.win-x64.
We have local package feeds configured in nuget.config, the source nuget.org is not and must not accessed directly!
Now I get the following output:
c:\> nuget.exe restore ***.sln -NoCache -NonInteractive -ConfigFile .nuget\NuGet.config
[...]
Errors in C:\build\_work\313\s\***.csproj
NU1101: Unable to find package Microsoft.NETCore.App.Host.win-x64. No packages exist with this id in source(s): ***, ***, ***
NuGet Config files used:
C:\build\_work\313\s\.nuget\NuGet.config
Feeds used:
https://***.com/tfs/***/_packaging/A***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/B***/nuget/v3/index.json
https://***.com/tfs/***/_packaging/C***/nuget/v3/index.json
Environment:
C:\build\_work\313\s>dotnet --list-sdks
3.1.420 [C:\Program Files\dotnet\sdk]
5.0.400 [C:\Program Files\dotnet\sdk]
5.0.408 [C:\Program Files\dotnet\sdk]
Question
Why restore process tries to fetch the nuget package while the content is already part of the SDK installed?
What I've tried?
I've analyzed the behavior of the nuget.exe using Process Monitor (Sysinternals).
I found that the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.25\ is accessed but not found, only the folder 3.1.26 exists after update of SDK.
Why restore process tries to access "3.1.25" while "3.1.26" is installed?
On my local machine the restore works as expected. The package is NOT available in my local NuGet cache. Here the folder c:\Program Files\dotnet\packs\Microsoft.NETCore.App.Host.win-x64\3.1.26\ is accessed as expected.
I also tried to reinstall the SDK version. No effect.
Firstly, I highly recommend avoiding nuget.exe restore. If you can, prefer dotnet restore, and otherwise msbuild -t:restore. It's unrelated to the problem you're having here, but you can avoid different types of problems by migrating.
Anyway, the .NET Core SDK 3.1.419 would have had the version 3.1.25 versions of the runtime host, whereas .NET Core SDK 3.1.420 has version 3.1.26 of the runtime hosts. Hence, when the SDK upgraded from 419 to 420, the old version of the runtime host was removed, and the new one installed.
However, as your dotnet --list-sdks output shows, you have the .NET 5 SDK installed. .NET 5 is now out of support, and so it did not receive any update in this month's Patch Tuesday. In May, the last month that the .NET 5 SDK was updated, the latest version of the .NET 3.1 hosting app package was 3.1.25, so when you restore/build an app targeting .NET Core 3.1 with the .NET 5 SDK, the SDK checks for the version of the runtime hosting package it knows about, sees it isn't available locally, and then tells NuGet to download it.
You can either use a global.json to pin that directory's dotnet commands to the .NET 3.1 SDK, or you can install the June 2022 .NET 6 SDK (6.0.301), and then both of them will know that the .NET 3.1 runtime hosting package is version 3.1.26, and therefore should not ask NuGet to download it. Well, unless you uninstall the .NET 3.1 SDK completely and use the .NET 6 SDK to build it.
I know it's confusing. The .NET marketing people chose names that doesn't aid in understanding the difference, but the .NET SDK are build tools that can build any version of .NET equal or lower version, and the .NET runtime is completely independent. As mentioned previously in this answer, you can build .NET Core 3.1 apps with the .NET 6 SDK, the .NET Core 3.1 SDK is not needed (but the runtime will be, unless you publish a "self-contained" app).
I have a solution with 2 projects:
Client Library project made for .NET Standard 2.0
Test project for .NET Core 3.0
And I created Azure DevOps pipeline which builds and packs this library for DevOps private Nuget feed.
The pipeline contains the following steps:
Use NuGet >= 5.3.1 (added this hoping to solve the issue)
Use .Net Core sdk 3.0.100 (added this hoping to solve the issue)
Restore packages
Build
...
But the process fails at Restore packages step with:
error NU1201: Project [Test Project] is not compatible with netcoreapp2.2 (.NETCoreApp,Version=v2.2). Project [Test Project] supports: netcoreapp3.0 (.NETCoreApp,Version=v3.0)
So how can I set up CI/CD for .Net Core 3.0?
I DO NOT use YAML - I hate that thing.
I tried "Use Nuget" to force the pipeline to use the latest Nuget.
I also tried to for it using the latest .Net Core 3.1.x.
All this doesn't help.
What helped was the re-creation of the test project. Now the pipeline works!
Currently my Meteor App running #1.2 version right now I want to upgrade this application into Meteor1.5 version.
How to do this?
While you are in your meteor app's root dir,
To upgrade to a specific version:
meteor update --release 1.5
To upgrade to the latest version (1.5.1 at the time of writing this):
meteor update
I had to update my Meteor application as accounts-facebook was not wokring on previous version which was Meteor 1.3. After running "meteor update" command the meteor version is now updated to 1.5. Previously I was using mupx to deploy my application on Digital Ocean but it is not working for Meteor 1.5.
Can I Build a meteor android app in cloud 9.
meteor add-platform android
Because Im running on windows or should I install linux and run
curl https://install.meteor.com/ | sh
and build it locally.
If you want to build android app on Windows you need to be using the meteor 1.3 release beta which you can install by running meteor update --release 1.3-cordova-beta.5 in your project folder - Details on this release
Prior to 1.3 you will need to build the app on a linux machine
You can build a Meteor app on Cloud9 using any version of Meteor. See Meteor on Cloud9.