ALL of my .net core dockerfiles are 99% the same except for this last line:
ENTRYPOINT ["dotnet", "<APP NAME HERE>.dll"]
seems pretty dumb of me because they could all be identical otherwise
Is there a way to change the dll name with the dotnet publish -c Release -o out command? can I do that without having to modify csproj files or anything?
You can use this command to perform the build and rename the assembly:
dotnet msbuild -r -p:Configuration=Release;AssemblyName=foo
On Linux/macOS you will have to add quotes around the command, like this:
dotnet msbuild -r '-p:Configuration=Release;AssemblyName=foo'
However, there can be unintended side effects due to a global property being set. You should read this open issue from Sep 2019 as it speaks directly to your question regarding Docker and renaming the output: https://github.com/dotnet/msbuild/issues/4696
Also, I know you wanted to avoid editing the .csproj file, but in case you aren't aware, you can add the AssemblyName property and set the output name in that manner.
Such as:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<AssemblyName>foo</AssemblyName>
</PropertyGroup>
This will create foo.dll (and other files as well, e.g. .pdb, .deps.json, etc.)
As the documentation suggests:
You can override the ENTRYPOINT instruction using the docker run --entrypoint flag.
The command will look something like this:
docker run --entrypoint dotnet YOUR_IMAGE "<APP NAME HERE>.dll"
OR
As another helpful bit of documentation suggests, that you can also pass arguments to the entrypoint at the end of docker run command like so:
docker run YOUR_IMAGE "<APP NAME HERE>.dll"
This will also require you to change your ENTRYPOINT to:
ENTRYPOINT ["dotnet"]
In addition to #gcamp806's answer: I couldn't get the command to run under Windows 10 when using ; between the arguments. Instead I had to use a normal comma: ,
My command to publish a self-contained executable now looks like this:
dotnet publish -r win-x64 /p:Configuration=Release,PublishSingleFile=true,IncludeNativeLibrariesForSelfExtract=true,AssemblyName=appname --self-contained --output ./releases/windows/v1
Related
Calling dotnet restore <project> from my Dockerfile is resulting in a NU1301: Unable to load the service index for source error. I've been going through many of the suggested similar questions and continue to have issues. Here is as much info about the things I've tried as I can provide:
Docker Engine has its DNS set to "8.8.8.8"
Using Linux containers
RUN ping google.com succeeds (so I can reach the internet)
Works perfectly fine hitting the nuget.org feed
The nuget.config file currently has credentials in it just to get this working
This will be removed for a different approach once I get this working
These are the same credentials (username/PAT) that I use during development on my host machine
RUN curl <nuget_feed_url> succeeds
Running the restore command with --verbosity detailed doesn't provide any other error messages but the one
Here is the section of the Dockerfile in question
FROM mcr.microsoft.com/dotnet/aspnet:6.0.13 AS base
# Create dockeruser in base layer
RUN addgroup --system --gid 1000 dockergroup \
&& adduser --system --uid 1000 --ingroup dockergroup --shell /bin/sh dockeruser
WORKDIR /app
EXPOSE 8080
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
# Arguments are required in each stage in order to get the correct value
WORKDIR /src
COPY ["src/Nucleus.LumberYard.API/", "Nucleus.LumberYard.API/"]
COPY ["./nuget.config", "./nuget.config"]
WORKDIR "/src/Nucleus.LumberYard.API"
#COPY [".editorconfig", "./"]
RUN dotnet restore "Nucleus.LumberYard.API.csproj"
RUN dotnet build "Nucleus.LumberYard.API.csproj" -c Release --no-restore
Environment info
Docker Desktop v3.3.1
Docker v20.10.5
Based on my understanding you have the following scenario:
a .NET 6 application with some references to nuget packages
some nuget packages are taken from the usual Nuget public repository, some others are taken from a private nuget feed
you are distributing your application via a docker image and during the docker build process you want to run a dotnet restore command targeting one of your csproj file
the dotnet restore command fails because the dotnet cli is unable to talk with your private nuget feed
I encountered the very same situation with the project I'm working on. We have a private Nuget feed hosted in Azure Devops and we too had some troubles figuring out how to solve this.
First of all, let's clarify the root cause of the problem.
You did the right thing veryfying that you are able to reach the nuget feed from your build machine, via the curl command you mentioned.
What is actually failing is the authentication between your build machine and the private nuget feed.
The first thing you need is a personal access token with read permissions for your nuget feed. You can follow this guide to create the personal access token you need.
Once you have the token, you need to provide it to the dotnet cli.
There are several ways to do so, I'm going to explain the one that worked for us.
Instead of adding the nuget source to the nuget.config file, we registers it via a cli command.
I'm quite sure there is a way to do exactly the same thing via the nuget.config file (see here for more details).
This is the cli command we use inside of our docker file:
RUN dotnet nuget add source https://foo.bar.com/something/nuget/v3/index.json -u "whatever" -p "my-personal-access-token" --store-password-in-clear-text --valid-authentication-types "basic"
Notice that:
https://foo.bar.com/something/nuget/v3/index.json is the absolute URL pointing to the index of your private nuget feed
the username can be whatever you like. You do need to provide a value, but I didn't notice any difference even putting there a random string like whatever
the fictious value my-personal-access-token must be substituted with the personal access token you have created as a first step
Here you can find the full reference for the dotnet nuget add source command.
After registering this source with the dotnet cli, you will be able to run your dotnet restore command with no errors.
Hope this helps!
What is the -o flag in this .NET CLI command: dotnet new webapi -o RESTfulAPIName?
My .Net Core SDK version is 6.0.403.
It's the Output flag. It's used to change the location of the scaffolded files to another directory name. By default, the code is placed in ./<ProjectName>/.
You can see the documentation for this flag by running dotnet new --help or online.
According to Microsoft Learn, the -o flag means:
[-o|--output <OUTPUT_DIRECTORY>] [--project <PROJECT_PATH>]
It just creates a folder and puts your created .NET project inside it with a specific name.
See this screenshot of my terminal with and without the -o option specified below:
All these answers are very helpful and below is the best answer I found by #gunr2171
It's the Output flag. It's used to change the location of the scaffolded files to another directory name. By default, the code is placed in .//.
You can see the documentation for this flag by running dotnet new --help or online.
I have a .NetCore 3.1 commandline app. When buidling locally and publishing, it works completely fine using below commandline
dotnet publish -c dev -r win-x64 --self-contained true
In the Azure pipeline - I had to do the dotnet restore before doing a publish using the above command. Whilst publishing I had to add extra param --no-restore, as per Microsoft's recommendation here as I have private nuget feeds.
dotnet publish -c dev -r win-x64 --self-contained true --no-restore
Most dotnet commands, including build, publish, and test include an
implicit restore step. This will fail against authenticated feeds,
even if you ran a successful dotnet restore in an earlier step,
because the earlier step will have cleaned up the credentials it used.
To fix this issue, add the --no-restore flag to the Arguments textbox.
Now, the publish part of the pipeline has started failing with the error -
C:\Program Files\dotnet\sdk\3.1.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file 'MyProject\obj\project.assets.json' doesn't have a target for '.NETCoreApp,Version=v3.1/win-x64'. Ensure that restore has run and that you have included 'netcoreapp3.1' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers.
Am not using a publish xml, but specifying all the arguments as shown above in the command line. I've checked the csproj has the target framework specified
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<Configurations>Debug;Release;dev;test;pre;prod</Configurations>
</PropertyGroup>
Need any pointers as to what might be going wrong here?
Thanks
Please add RuntimeIdentifier as mentioned in the error message:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp3.1</TargetFramework>
<Configurations>Debug;Release;dev;test;pre;prod</Configurations>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
Please also check PlatformTarget.
<PlatformTarget>AnyCPU</PlatformTarget>
I guess the local machine has a different OS than the build agent.
To run dotnet core application with specified absolute path we need to run following command:
dotnet run -p C:\foo\bar\Project\Project.csproj
But it seems it doesn't work the same with dotnet watch run:
watch : Could not find a MSBuild project file in 'C:\directory\where\we\execute\command'. Specify which project to use with the --project option.
Running the same command with -project instead of -p doesn't help however...
Dotnet watch help specifies -p or -project parameter anyway:
Microsoft DotNet File Watcher 2.1.1-rtm-30846
Usage: dotnet watch [options] [[--] ...]
Options: -?|-h|--help Show help information
-p|--project The project to watch -q|--quiet Suppresses all output except warnings and errors -v|--verbose
Show verbose output --list Lists all discovered
files without starting the watcher --version Show
version information
Environment variables:
DOTNET_USE_POLLING_FILE_WATCHER When set to '1' or 'true',
dotnet-watch will poll the file system for changes. This is required
for some file systems, such as network shares, Docker mounted
volumes, and other virtual file systems.
DOTNET_WATCH dotnet-watch sets this variable to '1' on all child
processes launched.
Remarks: The special option '--' is used to delimit the end of the
options and the beginning of arguments that will be passed to the
child dotnet process. Its use is optional. When the special option
'--' is not used, dotnet-watch will use the first unrecognized
argument as the beginning of all arguments passed into the child
dotnet process.
For example: dotnet watch -- --verbose run
Even though '--verbose' is an option dotnet-watch supports, the use
of '--' indicates that '--verbose' should be treated instead as an
argument for dotnet-run.
Examples: dotnet watch run dotnet watch test
What's wrong then? Why absolute path to project doesn't work with dotnet watch run while works with dotnet run?
You can resolve this by specifying the -p (or the longer --project) option on the watch command rather than on the run command. In your case, that would be:
dotnet watch -p C:\foo\bar\Project\Project.csproj run
There's a note in the docs that covers this:
You can use dotnet watch --project <PROJECT> to specify a project to watch. For example, running dotnet watch --project WebApp run from the root of the sample app will also run and watch the WebApp project.
I'm not 100% sure, but dotnet watch is looking for file changes in the current directory. So if you use absolute path it must know where should it looks for changes. Of course, such implementation is possible but I just think that nobody thinked about it when implementing watch command
In my case, its just a minor error, you have to enter in the project directory before executing dotnet command, like:
cd yourAppName
dotnet watch run
It'll run
I've been searching for quite some time now, and can't seem to find an answer to this problem. Found only two questions/answers on SO and they still don't answer this question (https://stackoverflow.com/search?q=netcore+publish+mac+app).
I'm working with DotNetCore on Mac, using Visual Studio as the IDE. The app is a Console App, not an ASP.Net app, simple "Hello World" app in C#:
...
Console.Writeline("Hello World");
...
So here's the question... To run the app, I know I can use the "dotnet" command to run it. I'm trying to build/publish the app, as you normally would do in Windows by creating an .exe file, but now on Mac by creating a native binary file.
I have found zero documentation on how to do this, and deploy the application as a self contained app that can run independently without having to call the program using the "dotnet" command. Maybe I'm looking in the wrong places but haven't even found anything on Microsoft's documentation, they all point to documentation for building ASP.Net apps on .NetCore.
Any suggestions?
Found the answer by looking at the "dotnet publish" options:
dotnet publish -c Release --self-contained -r osx.10.13-x64
Where --self-contained includes all required libraries, and -r specifies the runtime target.
$ dotnet publish -c Release --self-contained -a x64
Determining projects to restore...
Restored /Users/walshca/code/temp/MutexThrow/MutexThrow.csproj (in 155 ms).
MutexThrow -> /Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/MutexThrow.dll
MutexThrow -> /Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/publish/
dotnet publish docs
Then I run ./bin/Release/net6.0/osx-x64/publish/MutexThrow
This didn't specify the --output cli arg, so you can see in the build output it defaulted to [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/
(In dotnet 6.0 instead of -r runtime target, you can specify --arch x86 and it uses the default RID for your system.)
If your project props sets a different build output, can you find the executable by enumerating files by unix file permissions:
$ gci -r -file | ? UnixMode -match 'x$' | % FullName
/Users/walshca/code/temp/MutexThrow/obj/Release/net6.0/osx-x64/apphost
/Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/MutexThrow
/Users/walshca/code/temp/MutexThrow/bin/Release/net6.0/osx-x64/publish/MutexThrow