My application hosted in azure uses old .NETCORE 1.0 SDK. There wasn't any commits for more than a month and when I committed some changes today, it failed to build. I checked the pipeline and I found that it failed on Run dotnet with this error
A compatible installed .NET Core SDK for global.json version
[1.0.0-preview2-003131] from [D:\a\1\s\global.json] was not found.
Does it mean azure devops does not support .NETCORE 1.0 anymore? Do I need to upgrade the application to use .NETCORE 2.x?
Any help will be appreciated.
Cheers
There are several hosted agents, and the different agents have different software installed on it. The list of agents can be found here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?view=azure-devops
the window 2019 hosted agent has the following software installed:
https://github.com/actions/virtual-environments/blob/master/images/win/Windows2019-Readme.md
the window 2016 hosted agent has the following software installed:
https://github.com/actions/virtual-environments/blob/master/images/win/Windows2016-Readme.md
As you can see in the list, the windows 2016 hosted agent still has a .net Core 1.0 version installed. If updating you project to a new .net Core version is not an option, you might be able to build your project on this agent.
You can set the agent to build to windows 2016 by using the following yaml:
jobs:
- job: Build_Web
pool:
vmImage: 'vs2017-win2016'
Agree with PaulVrugt that you should use Windows 2016 hosted agent to build your application if you do want to use .net core 1.
But you may also need an extra Use .net core Task in the first task of the pipeline to specify the version you want to use.
This task can be used to change the version of .NET Core used in subsequent tasks like .NET Core cli task. And this is necessary cause Azure Devops will automatically pick the latest version of .net core sdk unless you use this task to let the pipeline know which version of sdk do you want to use in following tasks.
Related
I built an ASP.NET Core application, but I have a hosting server which allows .NET 4.7.2 version only.
Is it possible to deploy to that environment?
As #marc_s already said that you cannot run .NET Core on .Net xxx
run time as two version has it's own runtime and they are different in
regards of its architecture.
If you have a .NET Core application, depending on its version, you could choose your runtime.
Here is the official release of all .NET Core versions:
Note
If you have any requirement where you need to communicate both .NET Core xxx version along with the Classic .NET xxx version, there is a way to build a bridge between them that is .NET Standard library.
The main goal behind .NET Standard was to establish greater uniformity in the .NET ecosystem. You can get more details in the official document here
Hope above explanation guided you accordingly.
We are trying to run the .net core API service on Cent OS using Nginx server. Do we need .NET SDK or run time libraries are enough to run the .NET service on Linux?
It depends on how you are publishing the application.
If your application is published as a Framework Dependent application, it will need just the .NET Runtime to be installed.
If your application is published as a Self-Contained application, it will not need the .NET Runtime to be installed (but the transitive native dependencies of .NET runtime - such as OpenSSL and ICU might be needed).
At no point should the SDK be required to run the application. If it is, you are doing something wrong, or have run into a bug.
For more details, see:
.NET Application Publishing Overview
Publishing .NET applications with the .NET CLI.
If you are targeting Linux running Intel x86_64 machines, remember to use the linux-x64 Runtime Identifier when targeting the application.
I have a .net core 2.2 web app that has been building successfully in Bamboo for several months. Recently someone rebuilt the new Bamboo server (we're on premise, not in cloud) as the first step in a Bamboo upgrade and my build began failing. The error is:
C:\Program Files\dotnet\sdk\2.1.509\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2.
My original post incorrectly asserted that this error was occurring in a Script task running dotnet publish. I realize now that it is actually occurring in the previous task - a Bamboo Command task running NuGet Restore. And I can reproduce the problem at the command line, so it does not appear to be a Bamboo issue.
So, in summary, I have a .NET Core solution with four projects. All four projects target .NET Core 2.2. I have NuGet 5.3.1 installed on my Bamboo build server. I navigate to the solution directory and run
nuget restore
And I first get the following informational message:
MSBuild auto-detection: using msbuild version '15.9.21.664' from 'C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\bin'.
Followed by four instances of the following error, one per project:
C:\Program Files\dotnet\sdk\2.1.509\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.TargetFrameworkInference.targets(137,5): error NETSDK1045: The current .NET SDK does not support targeting .NET Core 2.2. Either target .NET Core 2.1 or lower, or use a version of the .NET SDK that supports .NET Core 2.2.
What is causing the nuget restore operation to be working with .NET Core 2.1 instead of 2.2? Is there a problem with the msbuild auto-detection?
I initially found that .net core 2.2 had not been installed on the new server, so I installed it, so both are now installedre. But the error above persists and continues to reference .net core 2.1.
Instead of running nuget restore use dotnet restore.
A cleaner way to set this up would be to configure a dotnet executable as a Command in Bamboo. By doing this you can ensure that you are running the correct executable every time. Additionally you will gain the following benefits:
The command will show what version it is
This scale to other build agents
Adds clarity to the Bamboo task (will show as dotnet 2.2 instead of a script).
Then you can have dedicated tasks for each step (e.g., restore, build, test)
I'm getting more and more confused with .NET Core's SDK and runtime versioning, and I doubt I'm the only one. I want to get a few things straight.
I've created an ASP.NET Core application targeting .NET 4.6.1 - it hits 4.6.1 libraries and Net Standard libraries. Recently I made the switch from project.json to csproj as part of the VS2017 rollout. The 1.1.1 runtime came out with SDK 1.0.1 a few weeks ago, which I downloaded (https://github.com/dotnet/core/blob/master/release-notes/download-archive.md).
dotnet --version gives me the correct SDK (1.0.1)
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime is installed.
Fast forward to hosting my app: I install the latest windows server hosting package to host on IIS according to https://learn.microsoft.com/en-us/aspnet/core/publishing/iis, that is 1.0.4&1.1.1. Installing this on my server installs "Microsoft .NET Core 1.0.4 & 1.1.1 - Windows Server Hosting" and "Microsoft .NET Core 1.0.4 - Runtime". Shouldn't it have also installed the 1.1.1 runtime? It works, so maybe it's not necessary.
Ultimately, my questions are the following:
Does the runtime version matter when targeting .NET 4.6.1 at all?
Is runtime just used to run the AspNetCoreModule for the IIS to kestrel reverse proxy?
Will installing new Windows Hosting packages break existing projects already running on the servers?
Does .Net's netstandard packages (such as MVC) versioning correspond in any way to the runtime version, or is it just regular semantic versioning? The newest versions of most "Microsoft.AspNetCore.X" packages are 1.1.1.
I'm in the same situation, compiling my ASP.NET Core app against the full .NET Framework (4.5.2 in my case) and deploying it on IIS. Hopefully I can help.
When using the full .NET framework, you need to install the SDK on your developper machine to compile, but to deploy it on an IIS server you don't need any .NET Core runtime installed at all. On my IIS server, I just need .NET Framework installed and then I'm installing the "Windows Server Hosting" as suggested here: https://github.com/dotnet/core/blob/master/release-notes/download-archives/1.0.4-download.md with a command line that won't even install any .NET Core on my server:
DotNetCore.1.0.4_1.1.1-WindowsHosting.exe OPT_INSTALL_LTS_REDIST=0 OPT_INSTALL_FTS_REDIST=0
This installation is super quick and is just deploying the minimum amount of files IIS needs to run your .NET Core app, which is mainly the aspnetcore.dll. I don't even have a directory "C:\Program Files\dotnet" (so no runtime or sdk) on my server and my app is working fine.
So, I would say:
no, it doesn't matter, it won't run against any .NET Core runtime
no, AspNetCore.dll is a C++ module (https://github.com/aspnet/AspNetCoreModule)
I don't see how it could break anything
at the moment, when you add a Nuget package in your ASP.NET Core app, its versionning seems quite independant to me, that's why Microsoft is now providing metapackage to help people using the proper set of Nuget package (https://andrewlock.net/what-is-the-microsoft-aspnetcore-metapackage/)
Regarding:
However, typing "dotnet" into cmd I see "Version : 1.1.0". Shouldn't
this say 1.1.1? My Programs and Features shows that the 1.1.1 runtime
is installed.
I'm wondering the same thing and can't figure out where this is coming from, maybe it's just the version of the "dotnet" command line tool that is package with the SDK 1.0.1, but I can't prove it.
I am trying to deploy an asp.net web app from BitBucket to an Azure web app and getting the below error:
Command: "D:\home\site\deployments\tools\deploy.cmd"
Handling ASP.NET Core Web Application deployment with MSBuild.
MSBuild auto-detection: using msbuild version '14.0' from 'D:\Program Files (x86)\MSBuild\14.0\bin'.
Restoring packages for D:\home\site\repository\src\Sertech\project.json...
Committing restore...
Lock file has not changed. Skipping lock file write. Path: D:\home\site\repository\src\Sertech\project.lock.json
D:\home\site\repository\src\Sertech\Sertech.xproj
Restore completed in 1753ms.
NuGet Config files used:
C:\DWASFiles\Sites\#1SertechWebApp\AppData\NuGet\NuGet.Config
Feeds used:
https://api.nuget.org/v3/index.json
Cannot find DNX runtime dnx-clr-win-x86.1.0.0-rc1-update1 in the folder: .dnx\runtimes
D:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(248,5): error MSB4044: The "GetBuildOptions" task was not given a value for the required parameter "RuntimeToolingDirectory". [D:\home\site\repository\src\Sertech\Sertech.xproj]
Failed exitCode=1, command="D:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "D:\home\site\repository\Sertech.sln" /nologo /verbosity:m /p:deployOnBuild=True;AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false;publishUrl="D:\local\Temp\8d3d203fca67f23"
An error has occurred during web site deployment.
\r\nD:\Program Files (x86)\SiteExtensions\Kudu\57.50831.2397\bin\Scripts\starter.cmd "D:\home\site\deployments\tools\deploy.cmd"
The Publish Web option in Visual Studio works just fine, the issue only happens from a BitBucket deployment.
What I've tried so far in no particular order:
Use custom deployment script I found while searching the issue.
Use custom deployment script downloaded from the Kudu page of my
Azure web app.
Change the SDK version in VS.
Install the dnx-clr-win-x86 nuget package locally.
Install the dnx-clr-win-x86 nuget package on the web app resource
using the Azure console (this failed to find a package).
If anybody can point me in the right direction for troubleshooting further or has a solution I would be very thankful.
DNX? RC1? A release candidate isn't quite RELEASED software. Just as The Donald isn't the president just because he's a candidate (well at least not as of this writing).
ASP.NET 5.0 betas, Core 1.0 RC1 and Core 1.0 RC2 are no longer supported in Azure App Service.
Admittedly this was announced in a blog post so visibility may suffer - https://blogs.msdn.microsoft.com/waws/2016/06/14/supporting-asp-net-5-core-rc1-on-azure-app-service/
Is ASP.NET 5, Core RC1, RC2 supported on Azure App Service?
No, ASP.NET 5, Core RC1 or RC2 is no longer supported on Azure App Service. The only supported ASP.NET Core stack is RTM on Azure App Service. Check the newly announced RTM version at https://blogs.msdn.microsoft.com/appserviceteam/2016/06/27/azure-app-service-and-asp-net-core/
No wonder you see things breaking. Upgrade your project to ASP.NET Core 1.0 RTM and redeploy.
Official migration guide here:
https://docs.asp.net/en/latest/migration/rc1-to-rtm.html