I've been working on our build pipeline for AWS Lambdas and wanted to add the ReadyToRun feature to reduce startup times. I noticed that in order to complete the publishing step, I needed to remove the --no-build flag. This rebuild step seems to run fairly quickly, so it's not a problem, but I'm curious as to why exactly it's needed.
This doesn't seem to be documented anywhere, and without it the runtimeconfig.json isn't compatible with a framework-dependent deployment. So basically --no-build is not compatible with --no-self-contained.
For context, we build in a custom Alipne-based container with the latest .net core 3.1 SDK and some other internal tools. The restore/build step runs first so we can then run all the tests and finally zip up the distributable package which is picked up by the rest of the CI pipeline. Everything after that first step carries the --no-build flag, except now for the dotnet publish step.
The commands boil down to basically this:
dotnet build --configuration Release --runtime linux-x64 # also takes care of the restore step
dotnet test --no-build # with some filters and coverage targets
dotnet publish --configuration Release --runtime linux-x64 --no-self-contained --framework "netcoreapp3.1" /p:ReadyToRun=true /p:GenerateRuntimeConfigurationFiles=true
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
In Azure Devops for a .Net core application.
I have three steps
dotnet restore
dotnet build
dotnet test
But if I simply run dotnet test that forces a restore and build. Is there any reason to have the first two steps?
You can use them as follows:
dotnet restore
dotnet build --no-restore
dotnet test --no-build
In this way, you will speed up your build as it can use result of the previous command.
This is default behavior so you don't need to always run all commands to run dotent test for instance. It is convinient and still possible to opt-out from thah behavior.
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 have an MSTest project that works fine when being executed with:
dotnet test --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
I am also able to build a self-contained app out of it with:
dotnet publish -c Release -f netcoreapp2.1 --force --self-contained --runtime win-x64
But I have no idea how to run the tests from the produced output.
Calling
dotnet test .\ProjectName.dll --logger "trx;LogFileName=Result.trx" --settings tests.runsettings
fails with the message:
error MSB4025: The project file could not be loaded.
Any hints as how to run this self-contaiend MSTest-Project?
dotnet test now (2022) accepts .dll files to perform test execution.
You are using the wrong tool:
➜ ~ dotnet --help
test Runs unit tests using the test runner specified in the project.
vstest Runs Microsoft Test Execution Command Line Tool.
dotnet test is the tool used to run unit tests defined in a given project. If you are trying to run tests out of a published dll, dotnet vstest is the command you should us. You do that like this:
dotnet publish -o outputdir
dotnet vstest outputdir/your.dll
I am able to "dotnet xunit" when I am in folder where the project is.
How can I do it from command line where I want to pass already compiled dll as a parameter.
dotnet xunit PathToLibrary.dll
I get an error:
No executable found matching command "dotnet-xunit"
I have copied "xunit.execution.desktop.dll" (get from nuget xunit.core.2.3.0) into current folder, but that does not help.
dotnet-xunit is a per-project CLI tool
Consuming these tools requires you to add a <DotNetCliToolReference> element to your project file for each tool you want to use. Inside the <DotNetCliToolReference> element, you reference the package in which the tool resides and specify the version you need. After running dotnet restore, the tool and its dependencies are restored.
So check that your .csproj contains
<ItemGroup>
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0" />
</ItemGroup>
then do
dotnet restore
This answer isn't a direct answer to OP, but necessary for users of dotnet xunit
dotnet xunit is removed starting from xunit 2.4 Ref: Release Notes 2.4
Excerpt from the Release Notes:
Unfortunately, this release also removes the dotnet xunit runner, as the stability of the runner was never perfect, and it suffered from many assembly-loading related issues. Users from .NET Core can continue to use VSTest (either inside Visual Studio, or via dotnet test).
So, for xunit framework test use the command
dotnet test