DefineConstants works with Run command, but not Build command - .net-core

I am struggling to understand the differences between dotnet run and dotnet build commands, in regards to constants defined in the .csproj file
example.csproj
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)'=='Test'">
<DefineConstants>$(DefineConstants);INCLUDE_TESTS</DefineConstants>
</PropertyGroup>
</Project>
program.cs
using System;
namespace define_example
{
class Program
{
static void Main(string[] args)
{
#if INCLUDE_TESTS
Console.WriteLine("It worked!");
#endif
Console.WriteLine("Hello World!");
}
}
}
If I run dotnet run -c Test, -> It worked! Hello World!
If I run dotnet build -c Test, then dotnet run {buildpath} -> Hello World!
Why does the defined constant go missing when I run the build command?

dotnet build and dotnet run are both commands that act in relation to a csproj file, not a dll or executable.
dotnet build will call the dotnet restore command and then build the project.
dotnet run will call the dotnet build command (this is important to note with respect to your issue) and then run the resulting dll or exe.
What you're currently telling dotnet to do by calling dotnet build -c Test and dotnet run is:
clean, restore, build (using the "Test" configuration)
clean, restore, build, run (with no configuration specified)
The second clean will cleanup the files produced by the first build and then you will build again as part of the run command, but without the Test configuration specified, causing the observed behaviour.
You could change dotnet run to dotnet run --no-build to tell it to assume a build has already been completed and to just assume that the files that would have been created are present and correct.
Alternatively, given that your project has an OutputType of Exe, you could just invoke the executable that is produced by the build command in the regular way as the second step. i.e. using the command example.exe.
If your OutputType was unspecified, or the default (Library) then this would produce a dll rather than an exe, and you could run it using the dotnet command: dotnet example.dll.
Useful reading on the various commands and also common properties:
dotnet command
dotnet build command
dotnet run command
Common MSBuild project properties

Related

Jenkins Dotnet Project Publishing Issue

I am trying to publish my dotnet project-api from jenkins via powershell. The problem is when I publish it from powershell it's missing around 30 files and I can't reach api. However when I publish it from visual studio manually (or from visual studio package manager console with commands) it works perfectly. What might be causing this issue?
Here are the commands that I am running to publish api ;
dotnet restore
dotnet build --configuration release
dotnet publish -c release --output "path to the publish file"
I have also tried with this to publish command yet it didn'T work;
dotnet publish dotnet publish -c Release --self-contained -r win10-x64
I have been trying to figure this issue for a long time but I couldn't find a way. I would highly appreciate any help. Thanks!!
You should try following 2 Execute Windows batch command
Command
"C:\Program Files\dotnet\dotnet.exe" restore yourProjectSLN file
[E.g:yourProjectSLN = git/FolderName/ProjectName.sln , it should be same as jenkins configuration]
Command
dotnet publish yourProject_csproj_file_location -c:Release
[E.g:yourProject_csproj_file_location = git\FolderName\ProjectName.csproj]

dotnet publish command not working with asp dotnet project in aws buildspecs.yml file

I have created sample dot net application, folder structure as follows.
When i am using this command
dotnet publish -c release -o ./build_output demorepo2.csproj build output is getting created inside build_output folder correctly.
Now i have another asp.net mvc web application.
Now i am using same command dotnet publish -c release -o ./build_output test1.csproj but this not working. Getting the following error.
Any idea why this error?
From ASP.NET Web Deployment using Visual Studio: Command Line Deployment
Try to run this command:
msbuild demorepo2.csproj /p:DeployOnBuild=true /p:PublishProfile=MyPublishProfile

How to run self-contained .NET Core tests?

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

How to run "dotnet xunit PathToLibrary.dll" from command line (in Continous Integration)

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

Compile multiple dotnet core projects in one step using dotnet cli

Assuming this folder structure
SampleApp
global.json
Src
Web
project.json
Startup.cs
...
Model
project.json
Startup.cs
...
how does one compile both projects using dotnet? (from command line, not in visual studio)
If you run dotnet build at the root folder level you get
Could not find file .. project.json
I can see there is this outstanding enhancement on the CLI repo but that is from Feb2.
Any script would have to take dependencies into account before just blindly calling dotnet on all src sub-folders.
The dotnet build command accepts glob patterns. So you can do this:
dotnet build Src/**/project.json
There's no such a tool yet. Even KoreBuild, the tool that the ASP.NET team uses, goes blindly in each folder and invokes dotnet build/pack.
The nice thing is that dotnet build is now smart enough to not recompile the dependencies if they haven't changed, so that's not a problem anymore.
For linux I'm using:
for p in $(find . -name *.csproj); do dotnet build $p; done
I had a similar requirement. This is my workaround:
#echo off
for /D %%d in (*) do (
cd %%d
cd
dotnet restore
dotnet build
cd ..
)
exit /b
Use GNU Make. I use it to build my projects. all you have to do create a Makefile in your project root folder. You can nest Makefiles in directories and have a Top Level Makefile that runs the subdirectories. then you set up Makefiles for each of your "Sub Projects" folders and run any comandline tool. with dotnet core is is dotnet .
Wait... GNU - "GNU is not Unix" that's a Unix/Linux application... I run windows. Well the good news is you can do this is in windows. I'm using make.exe through my git-bash installation (git for windows). You will have to go find the cygwin port of make. (google: "make for git-bash") Then install it to your bin directory under the cygwin folder. You could also just install cygwin if you really wanted to.
The nice thing about using Gnu-Make is it is universal. Since dotnet core is platform agnostic, every environment Mac/FreeBSD/Linux have "make" most likely already installed. Adding it to your Windows machine and projects to me makes a lot of sense. Since you project can now be built by everyone the same way.
some of my projects need to build docker containers with dockerfiles, or snap packages, deploy to test, etc... Make (pardon the pun) makes it easy.
Here is a sample of simple projects Makefile. Running 'make' by itself is like saying 'make all' you could set up a command like 'cd ./subdir; make' as one of your .phoney directives. (Google: "Makefile documentation")
project_drive?=/c/prj
nuget_repo_name?=Local_Nuget_Packages
local_nuget_dir?=$(project_drive)/$(nuget_repo_name)
RELEASE_VERSION:= `grep "<Version>" *.csproj | cut -d '>' -f 2 | cut -d '<' -f 1`
.PHONEY: clean release test doc nuget install debug_nuget debug_install
all: doc MSBuild
test:
./test.sh
MSBuild:
dotnet build
clean:
dotnet clean; dotnet restore
release:
dotnet build -c Release
doc:
doxygen ./Doxyfile.config
nuget: release
dotnet pack -c Release
install:
cp ./bin/Release/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
debug_nuget: MSBuild
dotnet pack
debug_install:
cp ./bin/debug/*.$(RELEASE_VERSION).nupkg $(local_nuget_dir)
What's missing is that you can also use the commands on project.sln files if you do not have project.json
dotnet build src/**/project.json
-- or --
dotnet build src/project.sln
same goes for dotnet test

Resources