I am trying to create a GitHub workflow that will run an Entity Framework Core migration on my database.
The C# project containing my data model is targeting netcoreapp3.1.
Here is the bulk of the workflow: (trigger conditions omitted)
jobs:
migrate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Setup .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: 3.1.301
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Install EF Core tools
run: |
dotnet tool install --global dotnet-ef
dotnet tool restore
- name: Migrate
run: dotnet ef database update
When the workflow runs, I get this error:
Run dotnet ef database update
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '1.0.0' was not found.
- The following frameworks were found:
3.1.5 at [/opt/hostedtoolcache/dncs/3.1.301/x64/shared/Microsoft.NETCore.App]
You can resolve the problem by installing the specified framework and/or SDK.
The specified framework can be found at:
- https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=1.0.0&arch=x64&rid=ubuntu.18.04-x64
##[error]Process completed with exit code 150.
I have also tried specifying the version when installing the EF Core tools (--version 3.1.0) but this doesn't change anything.
Why I am getting this error? How can I fix it?
Update:
I added a task to the workflow with these commands, right before the failing migration task:
dotnet --list-sdks
dotnet tool list --global
Output of dotnet --list-sdks:
3.1.301 [/opt/hostedtoolcache/dncs/3.1.301/x64/sdk]
Output of dotnet tool list --global:
Package Id Version Commands
--------------------------------------
dotnet-ef 3.1.6 dotnet-ef
What is looking for .NET Core 1.0.0?
I got this to work by replacing dotnet ef with dotnet-ef on the last line of the example. I also noticed that the dotnet-ef will restore and build, so some steps in the workflow are redundant.
Related
I am trying to automate deployment of an ASP.NET WebAPI on a Linux server using the following command:
dotnet publish --configuration Release
However, when adding a new NuGet package to the solution, and then trying to run the dotnet publish command, I get an error because the compiler does not know the new package. Is there a way to tell the dotnet command to pull all NuGet packages ? (I'm kind of looking for an equivalent for pip install -r requirements.txt in python).
For information, I add the NuGet packages via VisualStudio without compiling the solution.
Edit : it seems like, unless I build the solution in VisualStudio, just adding a NuGet packet will only add the packet name and version in the file projectname.csproj.nuget.dgspec.json, but will not add the PackageReference projectname.csproj file, hince the not pulling new packets issue.
I assume you are using some CI/CD pipeline which could publish your web application somewhere.
Feels like you are missing steps before publish:
# Restore (restores nuget packages)
run: dotnet restore
# Build
run: dotnet build --configuration Release --no-restore
# Test (if you have tests in project)
run: dotnet test --no-restore --verbosity normal
# Publish
run: dotnet publish --no-restore --no-build --framework netcoreapp3.1
May be this link may be helpful: github .net CI/CD
I want to define my software's version number manually by hand within the source code. At least the major, minor, and patch version components (terminology taken from Semantic Versioning 2.0.0). However, for the build metadata, and .NET's assembly revision version component, I want them to be automatically overwritten by the build server. For example, in a development environment (developers desk), the build metadata, and assembly revision version component, is always empty resp. 0 (e.g. SemVer "1.2.3", Assembly "1.2.3.0"). When the developer checks-in the code changes, the build server replaces the build metadata, and assembly revision version component, with the format yyMMdd (nightly build). Using the already given example, the result would be like SemVer "1.2.3+200721", and Assembly "1.2.3.200721".
The software I am developing is a .NET Core 3.1 C# application, written with Visual Studio 2019. Therefore, I am using the dotnet CLI with a single solution file, referencing several C# projects (one primary project, and several supporting libraries). For the final build/publish (only the one primary project is build), I want to overwrite the build metadata, and assembly revision version component, with the current date for automatic nightly releases as described above.
The build server is GitHub Actions. This is my workflow script:
name: "Solution.sln (main)"
# Controls when the action will run. Triggers the workflow on push or
# pull request events but only for the master branch.
on:
push:
branches: [ "develop" ]
pull_request:
branches: [ "develop" ]
# A workflow run is made up of one or more jobs that can run sequentially or in
# parallel.
jobs:
ubuntu-build:
name: Ubuntu 20.04 build
runs-on: ubuntu-20.04
env:
DOTNET_NOLOGO: true
DOTNET_CLI_TELEMETRY_OPTOUT: true
DOTNET_MULTILEVEL_LOOKUP: true
steps:
- name: Checkout source code
uses: actions/checkout#v2
with:
clean: true
fetch-depth: 1
lfs: true
submodules: true
- name: Setup dotnet core cli
uses: actions/setup-dotnet#v1
with:
dotnet-version: "3.1.x"
- name: Restores NuGet packages
run: dotnet restore Solution.sln
- name: Builds solution assemblies
run: dotnet build Solution.sln --configuration Release --no-restore
- name: Tests solution assemblies
run: dotnet test Solution.sln --configuration Release --no-build --no-restore
- name: Publishes application
run: dotnet publish MainApplication/MainApplication.csproj --configuration Release --no-restore --output publish/ -p:PublishReadyToRun=false -p:PublishSingleFile=false -p:PublishTrimmed=true --self-contained false -p:Version
I have the following within my *.csproj files:
<PropertyGroup>
<VersionPrefix>1.2.3</VersionPrefix>
<VersionSuffix></VersionSuffix>
<Version>$(VersionPrefix)$(VersionSuffix)</Version>
<AssemblyVersion>$(VersionPrefix).0</AssemblyVersion>
<FileVersion>$(AssemblyVersion)</FileVersion>
<InformationalVersion>$(Version)</InformationalVersion>
<PackageVersion>$(Version)</PackageVersion>
</PropertyGroup>
Be aware, that VersionSuffix may already contain information, e.g. alpha.1 (pre-release version notation). Such information must not be overwritten, and have to persists in the final assembly. You probably noticed, that I have overwritten the default Version concatenation mechanics, this is because a stable release (VersionSuffix would be empty) version would result into a build server version like "1.2.3-+200721", which is an invalid SemVer, as "-" is the marker for the pre-release version, but there is no pre-release version content, so I have overwritten it, and have to put the "-" for pre-releases manually in VersionSuffix.
I am aware, that I can overwrite CSPROJ properties via the dotnet CLI using command line arguments like -p:VersionSuffix=+200721, -p:AssemblyVersion=1.2.3.200721.
However, the issue with this solution (exactly as described) is that the build server does not know about the already assigned version within csproj file.
How do I extract VersionPrefix, and VersionSuffix within the GitHub Actions environment, to use them as (environment) variables in the GitHub Actions script's job steps?
To summarize what I want to do:
extract VersionSuffix (, and VersionSuffix if VersionSuffix cannot be appended but only replaced),
(via dotnet CLI) append (not replace) to VersionSuffix the nightly build date (format +yyMMdd),
(via dotnet CLI) replace AssemblyVersion with "$(VersionSuffix).yyMMdd".
I’m using the DevOps pipeline to push my dotnet build to an Octopus cloud instance.
It worked fine until I added the dotnet SDK 3 installer to the devops pipeline
- task: UseDotNet#2
displayName: 'Install .net core 3.0.100'
inputs:
packageType: sdk
version: '3.0.100'
installationPath: $(Agent.ToolsDirectory)/dotnet
The octopus part of my azure-pipelines.yml looks like this:
- task: OctoInstaller#4
inputs:
version: 'latest'
- task: OctopusPush#4
inputs:
OctoConnectedServiceName: 'XXX.octopus.app'
Space: 'Spaces-1'
Package: '$(Build.ArtifactStagingDirectory)/$(Build.DefinitionName).$(Build.BuildNumber).zip'
Replace: 'false'
I have tried every combination of OctoInstaller that I can think of including embedded and explicit version numbers. I keep getting this error message with #4.
Failed to push package. The Octo command line tool is too old to run this task. Please use version 6.10.0 or newer, or downgrade the task to version 3.*.
With OctoInstall#3 I get another error:
Failed to push package. The process '/opt/hostedtoolcache/dotnet/dotnet' failed with exit code 150
Has anyone been able to use dotnet 3 with Octopus deploy? One option
might be to install the octo extension for dotnet but I’m not sure how
you would do that from the azure pipeline. Or to use a Windows build
instead of Ubuntu.
I also noticed an error in the build step.
The specified framework 'Microsoft.NETCore.App', version '2.0.0' was not found.
- The following frameworks were found:
3.0.0 at [/opt/hostedtoolcache/dotnet/shared/Microsoft.NETCore.App]
This means that octopus must be trying to use the dotnet 2 framework.
After looking carefully at the logs, I discovered that OctopusPush was failing because it depends on dotnet 2.0.0. I added in a yml task to install that framework and now it pushes to octopus.
It might be neater to use the dotnet octo tool, as described by TrevorBrooks however I don't know how to install dotnet extensions in the DevOps Pipeline.
Use dotnet octo https://octopus.com/blog/octopus-and-netcore
The blog article explains in detail how to make this work.
For Azure Pipelines follow this article: https://octopus.com/docs/packaging-applications/build-servers/tfs-azure-devops/using-octopus-extension
Keep in mind
The Azure DevOps extension tasks require Octo to be available on the
path when executing on a build agent and must have the .net core 2.0.0
runtime or newer installed. This may not always be possible such as
with the Azure DevOps hosted agents. In order to make this work, all
Octopus tasks will automatically attempt to download and use the
latest version of Octo tools unless they're available on the build
agent as specified above. If you would like to avoid any additional
downloads or to use a specific Octo version then you can by adding the
Octo Installer task to the start of your build definition. No attempt
will be made to download Octo if the capability is detected on your
build agent.
I'm trying to build a dotnet core application via Azure DevOps. I want my assemblies to be versioned with the build number.
In .csproj file:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
<Version>0.0.1</Version>
</PropertyGroup>
The yaml build pipeline contains:
trigger:
branches:
include:
- master
pool:
name: 'Hosted Windows 2019 with VS2019'
#vmImage: 'ubuntu-latest'
variables:
buildConfiguration: 'Release'
Version.Revision: $[counter(format('{0:yyyyMMdd}', pipeline.startTime), 0)]
VersionMajor: 0
VersionMinor: 1
name: '$(VersionMajor).$(VersionMinor).$(Date:yy)$(DayOfYear).$(Version.Revision)'
steps:
- task: DotNetCoreInstaller#0
inputs:
version: '2.2.300'
- script: dotnet build --configuration Release /p:Version=$(Build.BuildNumber)
displayName: 'dotnet build $(buildConfiguration) $(Build.BuildNumber)'
In the Azure Devops build log the command seems to pick up the correct version:
dotnet build --configuration Release /p:Version=0.1.19185.10
But when I download the artifacts and verify the dlls they still contain version number 0.0.1
Executing this command locally does add the version number in the dll. So, why is the version not added via Azure DevOps?
Unless you tell it otherwise dotnet publish will cause a recompile before publishing files, and thus overwrite anything you've previously tried to acomplish with dotnet build. You use the --no-build flag to supress the compile. Note that --no-build will also set --no-restore so you need to call dotnet restore explicitly. A typical set of commands (with typical variables you might see in Azure DevOps) might be:
dotnet restore
dotnet build --configuration $(BuildConfiguration) --no-restore /p:Version=$(Build.BuildNumber)
dotnet publish --configuration $(BuildConfiguration) --no-build --output $(Build.ArtifactStagingdirectory)
See this blog post for more details.
Background
.NET Core CLI (e.g., dotnet restore, dotnet build)
SDK-style project files (e.g., <Project Sdk="Microsoft.NET.Sdk">)
An application project that depends on a package that I publish through a nuget server.
Semantic versioning of my packages (e.g., 1.6.10, is version 1.6.9, with backwards compatible fixes)
Project package references in the application with a patch placeholder (e.g., 1.6.*)
nuget.config file (with path to packages folder and list of NuGet sources.)
My project file for my application might contain this:
<PackageReference Include="MyDataAccessLibrary" Version="1.6.*" />
Here is the problem: When I publish a new version of my package to the nuget server, running dotnet restore on my development machine is not downloading that new version (if I have already been building against a previous version.)
For example, if I have been building against package version 1.6.9, I expected that dotnet restore would detect the recently published 1.6.10, install it, and use it when building my dependent application. That has not been my experience on my development machine. (On the build server, it works fine because it gets a clean copy for every build.)
Here is what I have been doing as a workaround on my dev machine:
Edit the project file, replacing 1.6.* with 1.6.10.
Run dotnet restore
Watch the new package version be downloaded
Edit the project file, reverting the 1.6.10 back to 1.6.*
Question: What is the right way to say, "please download the latest patch for a package" in the above situation?
I think I found the answer... the --no-cache option on dotnet restore.
dotnet restore --no-cache
In my case I was just using the NuGet Restore in the build pipeline and packages did not restore with latest version as I set in .csproj like version="1.0.*"
steps:
- task: NuGetCommand#2 displayName: 'NuGet restore'
inputs:
restoreSolution: Mobile.sln
vstsFeed: '0120c3c...'
noCache: true
After including dotnet restore command and moving dotnet clean on to top of pipeline,
my issue is fixed and I manage to restore with latest package version.
steps:
- task: DotNetCoreCLI#2 displayName: 'dotnet clean'
inputs:
command: custom
custom: clean
steps:
- task: DotNetCoreCLI#2 displayName: 'dotnet restore'
inputs:
command: restore
vstsFeed: '0123a2z1...'