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.
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'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
I am trying to migrate from Jenkins to Teamcity 2018
So far I have 4 build steps:
Dotnet restore
dotnet build
dotnet run
dotnet test
When teamcity runs 3rd step, it fails.
it tries to run :
dotnet.exe run --project .\Prime.csproj #D:\TeamCity\buildAgent\temp\agentTmp\5d23e7ecee784cabb12baefd7175c67d.rsp
and it gives error
Unhandled Exception: System.FormatException: Unrecognized argument format: '#D:\TeamCity\buildAgent\temp\agentTmp\5d23e7ecee784cabb12baefd7175c67d.rsp'.
I think, it because dotnet cli doesn't accept the # part..
Have anyone seen such error before?
Solution has 2 projects: Prime (the main code) and a tests project with all the tests. The tests project runs just with with 'dotnet test' command
Using dotnet core 2.0 .
So the only way forward which I found is to run .core app in Docker.
So, you need to publish the app to a folder and then put that code into a docker image and then set up your test project to run against docker instance of the app.
When I run my dotnet core 2 app from my PowerShell I always see 2 processes launched.
This is annoying as in Visual Studio 2017 I cannot "reattach" a debugger as there are always 2 processes with the same name "dotnet".
Any way to change this?
dotnet run is a development command that builds the project and queries the project for the actual command to run. It then launches the program described in the program - which may be a dotnet some.dll or someapp.exe depending on the program type.
To work around your issue, run a command like
dotnet bin\Debug\netcoreapp2.0\mapp.dll
directly to avoid process noise.
You can also chain a build command before it so you can rebuild the project on changes and still have the process that runs msbuild terminate:
dotnet build; dotnet bin\Debug\netcoreapp2.0\mapp.dll
Before I can use msbuild command in command line and pass the profile as a parameter. Is this currently supported in dotnet cli or is there a new way to build projects/solutions in .net core projects?
Under the hood, the dotnet cli is now mostly using msbuild to do the actual work (excluding dotnet new and dotnet run). So if you're doing a dotnet build, it's actually using msbuild internally.
You can still use msbuild parameters when using the dotnet cli, you need to use the following:
dotnet msbuild <options>
One option is /property:n=v which passes in your property name/value pairs directly to msbuild as you used to do with msbuild itself. You can also continue to use semi-colons between pairs, e.g.:
dotnet msbuild /property:WarningLevel=4;Configuration=Release