# C# Visual Studio 2019 Publish

###### tags: `C#` `Visual Studio` `Publish`

# Reference

* [Build a stand-alone executable by Visual Studio 2019 Community](https://docs.microsoft.com/en-us/answers/questions/178986/build-a-stand-alone-executable-by-visual-studio-20.html)
* [Creating a Single EXE Application with .NET Core](https://www.telerik.com/blogs/creating-a-single-exe-application-with-net-core)
* [Single file deployment and executable](https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file)
* Publish a single file app - Visual Studio

Solution Explorer --> Project --> Right click --> Publish


Add a publish profile


Select __Folder__



Specify a path


Initial --> Show all settings


CPU Configuration


Deployment mode --> select __Self-contained__


Check __Produce single file__


Press __Publish__ button


### Final setting of `x86`


#### Error

Log of publish


The RuntimeIdentifier platform 'win-x64' and the PlatformTarget 'x86' must be compatible.


set `Release | x64` to __CPU Configuration__ and
set `win-x64` to __Target runtime__ can resolve the error

### Final setting of `x64`


---

# [Devenv command-line switches](https://learn.microsoft.com/en-us/visualstudio/ide/reference/devenv-command-line-switches?view=vs-2022)
[Build a .NET Solution or Project from the Command Line
](https://www.c-sharpcorner.com/article/build-a-net-solution-or-project-from-the-command-line/)

---

# [dotnet build](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-build)

This article applies to: ✔️ __.NET Core 3.1 SDK and later versions__

## Synopsis

dotnet build [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>] [-f|--framework <FRAMEWORK>]
    [--force] [--interactive] [--no-dependencies] [--no-incremental]
    [--no-restore] [--nologo] [--no-self-contained] [--os <OS>]
    [-o|--output <OUTPUT_DIRECTORY>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--self-contained [true|false]] [--source <SOURCE>]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet build -h|--help

## Description
The ``dotnet build`` command __builds the project and its dependencies into a set of binaries__.
The binaries include the project's code in Intermediate Language (IL) files with a ``.dll`` extension.
Depending on the project type and settings, other files may be included, such as:

* An executable that can be used to run the application,
if the project type is an executable targeting .NET Core 3.0 or later.
* Symbol files used for debugging with a ``.pdb`` extension.
* A ``.deps.json`` file, which lists the dependencies of the application or library.
* A ``.runtimeconfig.json`` file, which specifies the shared runtime and its version for an application.
Other libraries that the project depends on (via project references or NuGet package references).

For executable projects targeting versions __earlier than .NET Core 3.0, library
dependencies from NuGet are typically NOT copied to the output folder.
They're resolved from the NuGet global packages folder at run time__.
With that in mind, the product of ``dotnet build``
isn't ready to be transferred to another machine to run.
__To create a version of the application that can be deployed,
you need to publish it__ (for example, with the [``dotnet publish``](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-publish) command).
For more information, see [.NET Application Deployment](https://learn.microsoft.com/en-us/dotnet/core/deploying/).

For executable projects targeting .NET Core 3.0 and later,
__library dependencies are copied to the output folder__.
This means that if there isn't any other publish-specific logic
(such as Web projects have), the build output should be deployable.

## Implicit restore

__Building requires the ``project.assets.json`` file,
which lists the dependencies of your application.
The file is created when ``dotnet restore`` is executed.
Without the assets file in place, the tooling can't resolve reference assemblies, which results in errors__.

__You don't have to run ``dotnet restore`` because it's run implicitly__
by all commands that require a restore to occur, such as ``dotnet new``,
``dotnet build``, ``dotnet run``, ``dotnet test``, ``dotnet publish``, and ``dotnet pack``.
__To disable implicit restore, use the ``--no-restore`` option__.

The ``dotnet restore`` command is still useful in certain scenarios
where explicitly restoring makes sense,
such as __continuous integration builds in Azure DevOps Services__ or
in build systems that need to explicitly control when the restore occurs.

For information about how to manage NuGet feeds, see the [``dotnet restore`` documentation](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore).

This command supports the ``dotnet restore`` options
when passed in the long form (for example, --source).
Short form options, such as ``-s``, are not supported.

## Executable or library output

Whether the project is executable or not is determined
by the ``<OutputType>`` property in the project file.
The following example shows a project that produces executable code:

<PropertyGroup>
  <OutputType>Exe</OutputType>
</PropertyGroup>

__To produce a library, omit the ``<OutputType>`` property or change its value to Library__.
The IL DLL for a library doesn't contain entry points and can't be executed.

## MSBuild

__``dotnet build`` uses MSBuild to build the project__,
so it supports both parallel and incremental builds. For more information,
see [Incremental Builds](https://learn.microsoft.com/en-us/visualstudio/msbuild/incremental-builds).

In addition to its options, __the ``dotnet build`` command accepts MSBuild options__,
such as ``-p`` for setting properties or ``-l`` to define a logger.
For more information about these options, see the [MSBuild Command-Line Reference](https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-command-line-reference).
Or you can also use the [dotnet msbuild](https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-msbuild) command.

#### Note

When ``dotnet build`` is run automatically by ``dotnet run``,
arguments like ``-property:property=value`` aren't respected.

Running ``dotnet build`` is equivalent to running ``dotnet msbuild -restore``;
however, the default verbosity of the output is different.

## Options

* ``-c|--configuration <CONFIGURATION>``

Defines the build configuration. The default for most projects is ``Debug``,
but you can override the build configuration settings in your project.

* ``-r|--runtime <RUNTIME_IDENTIFIER>``

Specifies the target runtime. For a list of __Runtime Identifiers (RIDs)__, see the [RID catalog](https://learn.microsoft.com/en-us/dotnet/core/rid-catalog).
__If you use this option with .NET 6 SDK, use ``--self-contained`` or ``--no-self-contained`` also__.
If not specified, the default is to build for the current OS and architecture.

#### Windows RIDs

Only common values are listed. For the latest and complete version,
see the ``runtime.json`` file in the ``dotnet/runtime`` repository.

* Windows, not version-specific
* ``win-x64``
* ``win-x86``
* ``win-arm``
* ``win-arm64``

* ``--self-contained [true|false]``

Publishes the .NET runtime with the application
so the runtime doesn't need to be installed on the target machine.
__The default is ``true`` if a runtime identifier is specified__. Available since .NET 6 SDK.

* ``-o|--output <OUTPUT_DIRECTORY>``

Directory in which to place the built binaries.
If not specified, the default path is ``./bin/<configuration>/<framework>/.``
For projects with multiple target frameworks (via the TargetFrameworks property),
you also need to define ``--framework`` when you specify this option.

e.g.,

dotnet build --configuration Release

---

# [Single-file deployment and executable](https://learn.microsoft.com/en-us/dotnet/core/deploying/single-file/overview?tabs=cli)

## Sample project file
Here's a sample project file that specifies single file publishing:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <PublishSingleFile>true</PublishSingleFile>
    <SelfContained>true</SelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>

</Project>

These properties have the following functions:

* ``PublishSingleFile``. Enables single file publishing.
Also enables single file warnings during ``dotnet build``.
``SelfContained``. Determines whether the app is self-contained or framework-dependent.
``RuntimeIdentifier``. Specifies the OS and CPU type you're targeting.
Also sets ``<SelfContained>true</SelfContained>`` by default.
``PublishReadyToRun``. Enables [ahead-of-time (AOT) compilation](https://learn.microsoft.com/en-us/dotnet/core/deploying/ready-to-run).

Single file apps are always OS and architecture specific.
You need to publish for each configuration, such as Linux x64, Linux Arm64, Windows x64, and so forth.

Runtime configuration files, such as *.runtimeconfig.json and *.deps.json, are included in the single file. If an extra configuration file is needed, you can place it beside the single file.

## Publish a single-file app

Publish a single file application using the ``dotnet publish`` command.

1. Add ``<PublishSingleFile>true</PublishSingleFile>`` to your project file.

This change produces a single file app on self-contained publish.
It also shows single file compatibility warnings during build.

<PropertyGroup>
    <PublishSingleFile>true</PublishSingleFile>
</PropertyGroup>

2. Publish the app for a specific runtime identifier using ``dotnet publish -r <RID>``

The following example publishes the app for Windows as __a self-contained single file application__.

dotnet publish -r win-x64

The following example publishes the app for Linux as a framework dependent single file application.

dotnet publish -r linux-x64 --self-contained false

``<PublishSingleFile>`` should be set in the project file to enable file analysis during build,
but it's also possible to pass these options as ``dotnet publish`` arguments:

dotnet publish -r linux-x64 -p:PublishSingleFile=true --self-contained false

---

# GitLab CI

#### ``.gitlab-ci.yml``:

stages:
  - build

build_job:
  stage: build
  # tags: [win10-vm]
  tags: [elite_pc]
  variables:
    GIT_CHECKOUT: "true"
    PROJECT_FOLDER: "Q_Color_Automation"
  script:
    - mkdir bin
    - mkdir publish
    - dotnet restore .\$PROJECT_FOLDER\$PROJECT_FOLDER.csproj
    - dotnet build ".\$PROJECT_FOLDER\" -c Release -o .\bin; $LASTEXITCODE
    - if ( $LASTEXITCODE -ne 0) { Write-Output "Build Failure!!"; Exit 1 }
    - Write-Output "Build Success!!"
    - ls .\bin
    - dotnet publish -r win-x64 -p:PublishSingleFile=true -o .\publish; $LASTEXITCODE
    - if ( $LASTEXITCODE -lt 0 -or $LASTEXITCODE -gt 1 ) { Write-Output "Publish Failure!!"; Exit 1 }
    - ls .\publish
    - Write-Output "Publish Success!!"
  artifacts:
    name: "${CI_PROJECT_NAME}_${CI_COMMIT_SHORT_SHA}"
    paths:
      - publish
    expire_in: 1 week

## NU1101 錯誤

* [Common NuGet configurations](https://learn.microsoft.com/en-us/nuget/consume-packages/configuring-nuget-behavior)

在 Local PC 使用 command ``dotnet build``, 會自動執行 ``dotnet restore``
且會吃 Windows User 的 ``NuGet.Config``:
``C:\Users\<your_user_name>\AppData\Roaming\NuGet\NuGet.Config``
所以在 Build 的時候不會有 NU1101 錯誤:

\KessilSwFramework.csproj : error NU1101: Unable to find package System.IO.Ports. No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages [D:\GitLab_Runner\builds\yU5WSYW5\0\elite_lin\qcolorautomation\Q_Color_Automation\Q_Color_Automation.csproj]

但 GitLab CI, 並沒有 ``NuGet.Config``! 所以 Workaround 的方式這個 Ticket:

### [[Workaround found] NuGet errors in Windows build: NU1101 No packages exist with this id in source(s): Microsoft Visual Studio Offline Packages #155](https://github.com/actions/setup-dotnet/issues/155#issuecomment-761195782)

#### GGG-KILLER commented on 16 Jan 2021:
Another thing that solved the issue for me was adding a ``nuget.config``
with the following to my project's root:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget" value="https://api.nuget.org/v3/index.json" />
  </packageSources>
</configuration>

在 Project 的每個 Module 有 *.csproj 檔案的資料夾下, 新增 ``nuget.config`` 檔案

---

## NETSDK1099

當 Project 中有 include Library module 時, 在 ``dotnet publish`` 時報錯

C:\Program Files\dotnet\sdk\5.0.402\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(97,5): error NETSDK1099: Publishing to a single-file is only supported for executable applications. [D:\GitLab_Runner\builds\yU5WSYW5\0\elite_lin\qcolorautomation\KessilSwFramework\KessilSwFramework.csproj]

Google "NETSDK1099" 沒找到答案, 於是就 Google "dotnet publish exclude dependency"
找到這篇

### [How to exclude projects to publish when publishing from a solution file? #13365](https://github.com/dotnet/docs/issues/13365):

#### alexis-landrieu-avanade commented on 10 Jan 2020:

``<IsPublishable>`` worked for me as well, thanks.
I just share a quick example with ``MyUnitTestProject.csproj`` (that could help someone):

Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>

    <IsPublishable>false</IsPublishable>
  </PropertyGroup>
...
</Project>

``<IsPublishable>false</IsPublishable>`` 在 publish 時用來將 Library 排除