I am trying to build a docker image for an ASP.NET Core 3.1 application and I fail to restore the packages. My solution has multiple projects and after copying all the project files, I am trying to create a layer which contains restored dependencies only.
The docker file
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
WORKDIR /app
EXPOSE 80
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY ["ExampleApi/ExampleApi.csproj", "ExampleApi/ExampleApi/"]
COPY ["Common.Web/Common.Web.csproj", "ExampleApi/Common.Web/"]
COPY ["Example.Data/Example.Data.csproj", "ExampleApi/Example.Data/"]
COPY ["Example.Services/Example.Services.csproj", "ExampleApi/Example.Services/"]
RUN mkdir /tmp/build/
COPY . /tmp/build
RUN find /tmp/build -name *.csproj
RUN dotnet restore "ExampleApi/ExampleApi.csproj" --verbosity detailed
COPY . .
WORKDIR "/src/ExampleApi/ExampleApi"
RUN dotnet build "ExampleApi.csproj" -c Release -o /app --no-restore
FROM build AS publish
RUN dotnet publish "ExampleApi.csproj" -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "ExampleApi.dll"]
Docker build
I am running without cache to be able to output all the csproj files within the container for each run (otherwise it gets cached and the files are not longer displayed).
docker build --no-cache -f ExampleApi/Dockerfile .
Sending build context to Docker daemon 116.4MB
Step 1/22 : FROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS base
---> a843e0fbe833
Step 2/22 : WORKDIR /app
---> Running in e33e9c821c0b
Removing intermediate container e33e9c821c0b
---> eec973a226e0
Step 3/22 : EXPOSE 80
---> Running in 8e813a3a8b85
Removing intermediate container 8e813a3a8b85
---> c8d95a3a1de4
Step 4/22 : FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
---> cef7866e800b
Step 5/22 : WORKDIR /src
---> Running in f56bf9402ed1
Removing intermediate container f56bf9402ed1
---> 55694332db0e
Step 6/22 : COPY ["ExampleApi/ExampleApi.csproj", "ExampleApi/ExampleApi/"]
---> 4beb2e169ec7
Step 7/22 : COPY ["Common.Web/Common.Web.csproj", "ExampleApi/Common.Web/"]
---> ed7a9c81e8f7
Step 8/22 : COPY ["Example.Data/Example.Data.csproj", "ExampleApi/Example.Data/"]
---> aaca52c111b4
Step 9/22 : COPY ["Example.Services/Example.Services.csproj", "ExampleApi/Example.Services/"]
---> efb15c17a096
Step 10/22 : RUN mkdir /tmp/build/
---> Running in 7da9eae324ca
Removing intermediate container 7da9eae324ca
---> b06126b19a7f
Step 11/22 : COPY . /tmp/build
---> 04598eaab98c
Step 12/22 : RUN find /tmp/build -name *.csproj
---> Running in 2fd26dba963d
/tmp/build/ExampleApi/ExampleApi.csproj
/tmp/build/Example.Data/Example.Data.csproj
/tmp/build/Common.Web/Common.Web.csproj
/tmp/build/Example.Sql/Example.!Sql.csproj
/tmp/build/Example.Services/Example.Services.csproj
/tmp/build/Example.Services.Tests/Example.Services.Tests.csproj
/tmp/build/Example.IdentityServer.Infrastructure/Example.IdentityServer.Infrastructure.csproj
/tmp/build/Example.IdentityServer/Example.IdentityServer.csproj
/tmp/build/Example.Data.Tests/Example.Data.Tests.csproj
/tmp/build/ExampleIntegrationApi/ExampleIntegrationApi.csproj
Removing intermediate container 2fd26dba963d
---> 78eadf796305
Step 13/22 : RUN dotnet restore "ExampleApi/ExampleApi.csproj" --verbosity detailed
---> Running in 5dc9b5bbd04e
MSBUILD : error MSB1009: Project file does not exist.
Switch: ExampleApi/ExampleApi.csproj
The command '/bin/sh -c dotnet restore "ExampleApi/ExampleApi.csproj" --verbosity detailed' returned a non-zero code: 1
find
indicates that ExampleApi/ExampleApi.csproj
is there, yet the dotnet restore
complains about not finding it.
Error MSB1009: Project file does not exist is no longer a problem with this handy solution by our Support Techs.
At Bobcares, we offer solutions for every query, big and small, as a part of our Server Management Service.
Let’s take a look at how our Support Team recently helped out a customer with the error MSB1009: Project file does not exist.
How to resolve error MSB1009: Project file does not exist
Have you been facing the following messages recently?
MSBUILD: error MSB1009: Project file does not exist. Switch: ProjectName.csproj ERROR: Service 'ServiceName' failed to build: The command '/bin/sh -c dotnet restore "ProjectName.csproj"' returned a non-zero code: 1
Fortunately, our Support Techs have a solution up their sleeves. After helping several customers with a similar issue, our Support Team recommends ensuring the Dockerfile is in the root of the project. Furthermore, we have to modify the settings in the docker-compose.yml file as shown below:
FROM mcr.microsoft.com/dotnet/core/runtime:2.2-stretch-slim AS base WORKDIR /app EXPOSE PortNumberOpenedOnDatabaseServer FROM mcr.microsoft.com/dotnet/core/sdk:2.2-stretch AS build WORKDIR /src COPY ["ProjectName.csproj", "ProjectName/"] RUN dotnet restore "./ProjectName.csproj" COPY . . WORKDIR "/src/." RUN dotnet build "ProjectName.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "ProjectName.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "ProjectName.dll"]
Here, we will build the Docker Image via the sudo docker-compose build command. We can also build and run the container at the same time by running sudo docker-compose up in the folder where docker-compose.yml is present.
According to our Support Techs, the docker-compose.yml should include the correct path for this to work seamlessly and hence no longer see this error message
When we avoid pruning images or docker containers no longer in use, the second command for building images will fail. In other words, we have to clean the Docker System with the following command:
sudo docker system prune -a
Furthermore, we can verify this with the sudo docker images command and then proceed with the sudo docker-compose build command to build images. Once we get this doen, we will not come across the MSB1009 error message.
[Looking for a solution to another query? We are just a click away.]
Conclusion
In short, the skilled Support Engineers at Bobcares demonstrated how to resolve the Project file does not exist error.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
Содержание
- Error MSB1009: Project file does not exist | How to fix
- How to resolve error MSB1009: Project file does not exist
- Conclusion
- PREVENT YOUR SERVER FROM CRASHING!
- FreeCAD Forum
- Compile on windows. MSBUILD error MSB1009 Project file does not exist.
- Compile on windows. MSBUILD error MSB1009 Project file does not exist.
- Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
- Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
- Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
- Ошибка развертывания .net core azure: файл проекта не существует
- 1 ответов
- Msbuild error msb1009 файл проекта не существует
- Answered by:
- Question
- MSBUILD: ошибка MSB1009: файл проекта не существует
Error MSB1009: Project file does not exist | How to fix
by Nikhath K | Jan 5, 2022
Error MSB1009: Project file does not exist is no longer a problem with this handy solution by our Support Techs.
At Bobcares, we offer solutions for every query, big and small, as a part of our Server Management Service.
Let’s take a look at how our Support Team recently helped out a customer with the error MSB1009: Project file does not exist.
How to resolve error MSB1009: Project file does not exist
Have you been facing the following messages recently?
Fortunately, our Support Techs have a solution up their sleeves. After helping several customers with a similar issue, our Support Team recommends ensuring the Dockerfile is in the root of the project. Furthermore, we have to modify the settings in the docker-compose.yml file as shown below:
Here, we will build the Docker Image via the sudo docker-compose build command. We can also build and run the container at the same time by running sudo docker-compose up in the folder where docker-compose.yml is present.
According to our Support Techs, the docker-compose.yml should include the correct path for this to work seamlessly and hence no longer see this error message
When we avoid pruning images or docker containers no longer in use, the second command for building images will fail. In other words, we have to clean the Docker System with the following command:
Furthermore, we can verify this with the sudo docker images command and then proceed with the sudo docker-compose build command to build images. Once we get this doen, we will not come across the MSB1009 error message.
[Looking for a solution to another query? We are just a click away.]
Conclusion
In short, the skilled Support Engineers at Bobcares demonstrated how to resolve the Project file does not exist error.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
Источник
FreeCAD Forum
The help and development forum of FreeCAD
Compile on windows. MSBUILD error MSB1009 Project file does not exist.
Compile on windows. MSBUILD error MSB1009 Project file does not exist.
Post by DeepSOIC » Thu Sep 10, 2020 7:54 pm
22:45:30: Running steps for project FreeCAD.
22:45:30: Starting: «S:Qtcmake3-14-3bincmake.exe» —build . —target all
Microsoft (R) Build Engine version 16.0.461+g6ff56ef63c for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
MSBUILD : error MSB1009: Project file does not exist.
Switch: all.vcxproj
22:45:30: The process «S:Qtcmake3-14-3bincmake.exe» exited with code 1.
Error while building/deploying project FreeCAD (kit: Desktop (x86-windows-msvc2019-pe-64bit))
When executing step «CMake Build»
22:45:30: Elapsed time: 00:00.
Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
Post by DeepSOIC » Thu Sep 10, 2020 8:23 pm
Qt Creator 4.13.0
In cmake output (see attached file), there are two things that catch my attention:
Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
Post by DeepSOIC » Thu Sep 10, 2020 8:28 pm
Hmm. creating a symlink «ALL.vcxproj» to ALL_BUILD.vcxproj in the build directory seems to have solved it, it’s building something. now i just wait for it to finish.
EDIT: it is built, and runs. Still wondering, why did I have to do that, doesn’t look right to me.
Re: Compile on windows. MSBUILD error MSB1009 Project file does not exist.
Post by DeepSOIC » Thu Sep 10, 2020 9:25 pm
Источник
Ошибка развертывания .net core azure: файл проекта не существует
у меня есть приложение app-service, настроенное в Azure, которое будет развернуто после фиксации в репозитории team-services git. До сих пор это работало нормально, и развертывание завершается с ошибкой:
однако, если я открою консоль azure и компакт-диск в каталог проекта, я увижу, что файл проекта (asp.net ядро .xproj) действительно существует. Я знаю его в правильном каталоге из вывода в журнале развертывания, показывая, что пакеты находятся восстановлено:
интересно, что у меня есть два приложения app-service, указывающие на разные проекты в одном решении. Suddently они оба терпят неудачу с тем же сообщением об ошибке, даже если они развертывают разные проекты.
любая помощь очень ценится.
редактировать
у меня уже был глобальный.json в моем корне решения (на том же уровне, что и мой .sln файл), но это указывало на более старая версия SDK, поэтому я обновил это, и это не имело никакого значения. Затем я попытался избавиться от «тестового» проекта в файле json, и это тоже не имело значения. Все еще не удается с той же ошибкой
1 ответов
по-видимому, вам нужно явно указать версию SDK в вашем глобальном.JSON в противном случае Kudu использует последнюю версию, которая теперь является preview3, которая несовместима.
будьте осторожны, вы глобальной.файл json должен жить в корне вашего репозитория.
Источник
Msbuild error msb1009 файл проекта не существует
Answered by:
Question
Using VS2015 solution. Using VSTS Online (https:// .visualstudio.com/
). Using VS source control repository, Using Visual Studio Build process in VSTS. Using «Hosted» Agent queue for build process. Build configuration = «Release»
Created simple source controlled SSRS solution in VSTS successfully mapped and managed in VS2015. Able to build successfully in VS2015. However when building in VSTS I always get error: «MSB1009: Project file does not exist»
In VSTS the build process is comprised of only 2 processes 1: Get Sources & 2 Build Solution (Visual Studio Build).
Under the Get sources process I have the correct Repository and for Workspace mappings I have Type=Map & Server path = $/ / . I think the issue is with Local path under $(build.sourcesDirectory) I am leaving it blank because I do not know what to put in it.
The log from the build is shown below. As you can see the project file does exist (yellow highlighte). I am not sure what the «switch» means. Any help would be appreciated. I’m trying to learn how to Build in the Cloud. (DEVOps)
Источник
MSBUILD: ошибка MSB1009: файл проекта не существует
Я пытаюсь реализовать CI (непрерывная интеграция) с использованием TFS для моего веб-сайта ASP.NET(Website Project). Я постоянно получаю следующие ошибки в течение нескольких дней. Ниже приведен полный журнал. Его просто не получают последнюю версию в локальном каталоге, поэтому его выдача ошибки. MSBUILD: ошибка MSB1009: Файл проекта не существует. Я проверил, что TFS не получает последнюю версию, я не уверен, почему. .
Любая помощь действительно оценена, спасибо заранее.
Согласно вашему протоколу и описанию, кажется, что команда TFS get (Get Source Step) ошибочно возвращает «Все файлы обновлены». и привести к следующему шагу MSBuild.
Сначала попробуйте выполнить шаги, чтобы проверить, работает ли он, установив очистку во время получения источника:
Измените свое определение: в репозитории установите » Очистить» на » Истинный», » Очистить» параметр «Источники» (попробуйте установить исходный каталог, если это не работает) Также включите параметр » Очистить» для решения задачи сборки
Другая возможность — папка с корневыми источниками ( D:UAMCAgent_work3s ) не отображается, т. D:UAMCAgent_work3s пространство не содержит сопоставления корней.
И предложите вам дважды проверить соответствующее разрешение учетной записи сборки, а также дать ему разрешение локального администратора на агенте сборки.
Вы можете отключить исходные шаги по умолчанию в определении сборки. И используйте свой собственный скрипт, чтобы получить исходные/выталкивающие файлы, чтобы увидеть, получится ли у вас такая же ситуация. Как это сделать, пожалуйста, следуйте: возможно ли проигнорировать/отключить первый шаг? Получить источник в vNext Build?
Источник
- Remove From My Forums
-
Question
-
Hi
I get above error when trying to build msi using BTDF
Christiane
-
Edited by
Friday, June 5, 2015 5:15 PM
-
Edited by
Answers
-
Hi,
Check the spelling of the file name and path. Give the correct names if wrongly given.
Ravi
-
Marked as answer by
Christiane0696
Monday, June 8, 2015 1:23 PM
-
Marked as answer by
-
The probable cause of this issue could be that the project
file does not exist in the specified directory or, if no directory was specified, the project file does not exist in the current working directory. As suggested already you have to check the spelling of the file name and path.Rachit
Please mark as answer or vote as helpful if my reply does
-
Marked as answer by
Christiane0696
Monday, June 8, 2015 1:23 PM
-
Marked as answer by
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
jsgoupil opened this issue
Nov 22, 2016
· 16 comments
Comments
Steps to reproduce
When using a .xproj project, I try to run «dotnet build D:pathtofolder».
Or if I CD into the project and run «dotnet build .» It fails on Azure. But it works on my computer.
This is failing on Azure only. On Azure, I have to cd
into the folder, then run exactly dotnet build
Expected behavior
Build properly
Actual behavior
MSBUILD : error MSB1009: Project file does not exist.
Environment data
dotnet --info
output:
.NET Command Line Tools (1.0.0-preview3-004056)
Product Information:
Version: 1.0.0-preview3-004056
Commit SHA-1 hash: ccc4968
Runtime Environment:
OS Name: Windows
OS Version: 6.2.9200
OS Platform: Windows
RID: win8-x86
However, forcing the version with global.json
to the following otherwise it doesn’t build…
"sdk": {
"version": "1.0.0-preview2.1-003155"
}
Azure web apps includes prevew2, preview2.1, and preview3. Without a global.json the project will default to preview3 [the latest] which won’t work for a project.json-based app.
Does the global.json address the issue for you?
@piotrpMSFT The global.json does not fix the issue. I have put the global.json in the folder first and it still say MSBUILD : error MSB1009: Project file does not exist.
Without the global.json but by doing dotnet build
, I can’t build (I get a different error error: MSB4019: The imported project «D:Program Files (x86)dotnetsdk1.0.0-preview3-004056ExtensionsMicrosoftVisualStudiov14.0DotNetMicrosoft.DotNet.Props» was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.).
With the global.json AND with dotnet build
, it builds.
OK, I have retried this and it seems to work. This is definitely a strange behavior
1. global.json not in the root, does not compile
/path/where/global.json
/path/ > dotnet build «.where»
This will fail with MSBUILD : error MSB1009: Project file does not exist. Switch: .where
2. global.json in the root
/path/global.json
/path/ > dotnet build «.where»
It builds.
If this is a normal behavior then I guess you can close.
Yes, I believe what it does is walk up from the current folder looking for global.json. So if it’s in a subfolder, it doesn’t find it, even if it’s in the folder of the app you’re asking it to build. Frankly, I think that’s a bit broken, but that’s the behavior of dotnet.exe.
@davidebbo is right on. The issue here is that dotnet.exe
doesn’t know anything about build
parameters and it selects a CLI
version before delegating to build
. By the time build
figures out it has a project path it already is too late to select a different CLI. We could make different decisions, but this would kill the CLI’s ability to be extensible since the root dotnet.exe
would need to understand the invocation semantics of every extensibility command. We went with this direction because workaround by changing pwd
is much easier than workaround by making a PR to the .net host cpp files and wait for CLI to re-ship
…
@piotrpMSFT Since you are here to talk about this version, I have been searching on how to not use this global.json and use the —fx-version? This simply doesn’t work… Is —fx-version supposed to work like that?
On Azure with no global.json
> dotnet
Version : 1.1.0-preview1-001100-00
...
--fx-version <version> Version of the installed Shared Framework to use to run the application.
...
> dotnet --info
Version: 1.0.0-preview3-004056
> dotnet --fx-version "1.0.0-preview2.1-003155" --info
Unknown option: --fx-version
Confusing much?
@schellap you should comment here as well
That is pretty frustrating. We need to do a better job of disambiguating fx version [runtime] from tools version [sdk]. What you are expecting from the last command, I suspect, is something I’d type as dotnet --sdk-version "1.0.0-preview2.1-003155" --info
. However, due to a couple of behaviors what is happening is that the host ignores —fx-version because it goes into sdk mode
and then the SDK fails to deal with —fx-version.
@schellap, can we do something in the host to make this simpler? some thoughts:
- add
--sdk-version
- should the host honor
--fx-version
when in SDK mode? I think this could be nice in some scenarios - I think the host should have uniform handling of its options, and not pass them on to e.g. SDK in some cases
Thoughts?
add —sdk-version
Why is global.json
within the project root not sufficient? I just wanted to understand why, before we add --sdk-version
.
should the host honor —fx-version when in SDK mode? I think this could be nice in some scenarios
Is it just for testing? Then you can simply use: dotnet --fx-version "1.2.0" sdk/1.2.0/dotnet.dll --info
at the expense of UX.
I think the host should have uniform handling of its options, and not pass them on to e.g. SDK in some cases
I think the help message states the --fx-version Version of the installed Shared Framework to use to run the application
. It was never intended for the SDK.
Cc @gkhanna79
Picking a tool based on having a global.json in the root is not obvious. If you were to run dotnet.exe from a path I don’t have access to drop any files, then we would never be able to choose the SDK version.
Also, the fact that Azure updates with new «previews» and in turn changes the behavior of the dotnet
command makes me cringe… Especially the fact that it’s not backward compatible. Now you will tell me «if I had put a global.json in the first place, it would not be a problem.» But it’s all these little things I have to do to make my site work that hinder my development/deployment.
In the output I pasted below, why dotnet
and dotnet --info
gives different version ? If they are different version (tool, sdk, framework?) maybe a description of what version is showing would help.
Like most of the tools we build as engineer, I believe we forget how other people are intending to use them.
@jsgoupil, I agree it is convenient to use a --sdk-version
. I had been under the impression that the tooling always placed the global.json
file. We can take care of this in dotnet.exe
@blackdwarf the version messaging is confusing, could you give this some thought so it would be less confusing? The problem is: dotnet.exe
prints a version, dotnet.exe --version
prints one version when SDK is present and another when it is absent.
I am actually actively working on proposing a fix for the version issues.
@schellap can you link the issue tracking this?
I agree it is convenient to use a —sdk-version. I had been under the impression that the tooling always placed the global.json file. We can take care of this in dotnet.exe
@blackdwarf any pointers to a work-in-progress?
@piotrpMSFT not yet, should be this week I hope.
Thanks @schellap. Closing in favor of dotnet/core-setup#753
msftgits
transferred this issue from dotnet/cli
Jan 31, 2020
- Remove From My Forums
-
Вопрос
-
Hi
I get above error when trying to build msi using BTDF
Christiane
-
Изменено
5 июня 2015 г. 17:15
-
Изменено
Ответы
-
Hi,
Check the spelling of the file name and path. Give the correct names if wrongly given.
Ravi
-
Помечено в качестве ответа
Christiane0696
8 июня 2015 г. 13:23
-
Помечено в качестве ответа
-
The probable cause of this issue could be that the project
file does not exist in the specified directory or, if no directory was specified, the project file does not exist in the current working directory. As suggested already you have to check the spelling of the file name and path.Rachit
Please mark as answer or vote as helpful if my reply does
-
Помечено в качестве ответа
Christiane0696
8 июня 2015 г. 13:23
-
Помечено в качестве ответа
I read some documentation on how to setup a docker file for an asp.net core project.
I have a rest api named dsi.rest.app and I try to create a dockerfile.
I followed tutorials and created a Dockerfile in the dsi.rest.app folder. The following folder is containing the solution i want to dockerise.
FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
WORKDIR /DockerSource
# Copy csproj and restore as distinct layers
COPY *.sln .
COPY *.csproj ./
RUN dotnet restore
# Copy everything else and build website
COPY /. ./
WORKDIR /DockerSource/dsi.rest.app
# RUN dotnet publish -c release -o /DockerOutput/dsi.rest.app --no-restore
RUN dotnet build "dsi.rest.app.csproj" -c Release -o /DockerOutput/dsi.rest.app --no-restore
# Final stage / image
FROM mcr.microsoft.com/dotnet/aspnet:5.0
WORKDIR /DockerOutput/dsi.rest.app
COPY --from=build /DockerOutput/dsi.rest.app ./
ENTRYPOINT ["dotnet", "dsi.rest.app.dll"]
I try to build the image:
docker build --pull -t dsi.rest.rest .
And I obtain an error message:
=> ERROR [build 8/8] RUN dotnet build "dsi.rest.app.csproj" -c Release -o /DockerOutput/dsi.rest.app --no-restore 0.5s
#15 0.505 MSBUILD : error MSB1009: Project file does not exist.
#15 0.505 Switch: dsi.rest.app.csproj
the project file is situated at the same level as the dockerfile. the csproj file is at the same folder level as the Dockerfile.
My csproj file contains the following information :
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net5.0</TargetFramework>
<UserSecretsId>4b7e5335-798e-4066-a795-83e772338899</UserSecretsId>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Bcl.AsyncInterfaces" Version="5.0.0" />
<PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="3.2.4" />
<PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.10.13" />
<PackageReference Include="MsgReader" Version="3.12.4" />
<PackageReference Include="Newtonsoft.Json" Version="13.0.1" />
<PackageReference Include="Swashbuckle.AspNetCore" Version="6.1.1" />
</ItemGroup>
<ItemGroup>
<Folder Include="PropertiesPublishProfiles" />
</ItemGroup>
</Project>
I ran the command : dotnet build «dsi.rest.app.csproj» -c Release -o /DockerOutput/dsi.rest.app —no-restore
without any problem. It did generate my application in C:/DockerOutput/dsi.rest.app