I want to publish folder with framework dependent deployments - FDD. But as soon as I want to target different directory then default, application is published as self contained deployments - SCD.
This deploy as FDD:
dotnet publish -c Release
and this as SCD:
dotnet publish -c Release -o "d:\temp\publish"
How can I deploy as FDD and also defined output dir?
I am using .NET Core 2.1.
I also tried (but it's not working):
dotnet publish -c Release -o "d:\temp\publish" -f netcoreapp2.1
My .csproj file is:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>
<TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
<IsPackable>false</IsPackable>
<Version>2.2.0</Version>
<PackagesRoot>..\</PackagesRoot>
<SpaRoot>Angular\</SpaRoot>
<WWWRoot>wwwroot\</WWWRoot>
<!-- Hides dist folders in wwwroot! -->
<DefaultItemExcludes>$(DefaultItemExcludes);$(WWWRoot)dist*\**</DefaultItemExcludes>
</PropertyGroup>
Status:
Not sure if this is a bug, but here is issue on GitHub.
Problem occurred when MSTest Test project (.NET Core) was added to project.
Solution is to specify target project and not publish entire solution.
This works:
dotnet publish ./Hosting/Hosting.csproj -c Release -o d:\temp //publish project
and this not:
dotnet publish -c Release -o d:\temp //publish solution
Here is link to additional explanation.
try specifying the framework like the line below:
dotnet publish -c Release -o "d:/temp/publish" -f netcoreapp2.1
more info about dotnet publish and examples for publishing
The output option works for both options, the difference between a framework-dependent deployment (FDD) and self-contained deployment (SCD) is in the -r RID option along with the optional --self-contained true/false flag (defaults to true when the -r option is used).
So you would use this to create a FDD:
dotnet publish -c Release -o "D:\temp\publish-fdd"
and an SCD with:
dotnet publish -c Release -r win-x65 -o "D:\temp\publish-fdd"
If you don't specify the -o option, the publish output will be put into the project's bin\Release\netcoreapp2.1\publish for FDDs or the runtime-specific subfolder bin\Release\netcoreapp2.1\publish\win-x64 for SCDs
Related
What Condition Expression for PropertyGroup/ItemGroup should be used to differ target OS (-r argument of dotnet publish)? E.g. on these commands:
dotnet publish -c Release -r win-x86 --self-contained false
dotnet publish -c Release -r linux-arm --self-contained false
Currently I've forced to use different Configurations and build using these commands:
dotnet publish -c ReleaseWin32 -r win-x86 --self-contained false
dotnet publish -c ReleaseLinux -r linux-arm --self-contained false
I know that MSBuild can define even target .NET Core/Framework version (e.g.Condition="'$(TargetFramework)' == 'netcoreapp3.1'"), so probably should also define target OS (something like Condition="'$(TargetOS)' == 'win-x86'").
Does there may be somehow used direct detection of target OS in CSPROJ file without using -c ReleaseWin32 / -c ReleaseLinux for builds for different platforms? Shortly, does MSBuild syntax have any Condition about target OS?
The CLI's -r linux-arm translates to MSBUild -property:RuntimeIdentifier=linux-x64 so you can use $(RuntimeIdentifier) in conditions:
<PropertyGroup Condition="'$(RuntimeIdentifier)' == 'linux-arm'">
</PropertyGroup>
<ItemGroup Condition="$(RuntimeIdentifier.StartsWith('win'))">
</ItemGroup>
I am using a DockerFile created by visual studio to create my image. I want to build with Azure DevOps and set my assemblies version inside the image the version I have in the Pipeline. I feel that I have to change this line but I dont known how.
RUN dotnet build "ImportBatch.Api.csproj" -c Release -o /app/build
My DockerFile
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["ImportBatch.Api/ImportBatch.Api.csproj", "ImportBatch.Api/"]
COPY ["ImportBach.Dto/ImportBatch.Dto.csproj", "ImportBach.Dto/"]
COPY ["Common/Common.csproj", "Common/"]
COPY ["Common.Dto/Common.Dto.csproj", "Common.Dto/"]
COPY ["Common.Azure.Storage/Common.Azure.Storage.csproj", "Common.Azure.Storage/"]
RUN dotnet restore "ImportBatch.Api/ImportBatch.Api.csproj"
COPY . .
WORKDIR "/src/ImportBatch.Api"
RUN dotnet build "ImportBatch.Api.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "ImportBatch.Api.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Cardinal.Software.ImportBatch.Api.dll"]
From pipeline:
- task: Docker#1
displayName: 'Build the image'
inputs:
dockerfile: 'Dockerfile'
imageName: '$(imageRepoName):$(GitVersion.SemVer)'
arguments: '--build-arg version=$(GitVersion.SemVer)'
continueOnError: true
On DockerFile:
FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS build
WORKDIR /src
COPY . .
ARG version #define the argument
#use this argument while running build or publish, for example
RUN dotnet publish "./yourProject.csproj" -c Release /p:Version=${version} -o /app/publish --no-restore
For SDK-style projects assembly version attributes are generated automatically, so you can use p:Version=1.2.3.4 right out of the box. Please check example here (at the bottom)
dotnet build -p:Version=1.2.3.4
My project is an AspNet Core 2.2 Api, I am building it in Azure Pipelines (classic) I want to generate the swagger document during an azure pipeline build - for this I am using Swashbuckle.AspNetCore.Cli and the documents in Retrieve Swagger Directly from a Startup Assembly
I have a Use .NET Core task set to 2.2 at the beginning of the job
I have installed the tools using .NET Core task with custom tool command with arguments install swashbuckle.aspnetcore.cli --version 5.0.0-rc4 --global, this seemed to work; If I run this task again it fails with message that tool is already installed.
Then in my CI Build, I added a .NET Core task with settings
command to Custom
Path to Project(s) to the path csproj file
Custom command to swagger
Arguments to tofile --output $(Build.ArtifactStagingDirectory)/swagger.json $($(Build.ArtifactStagingDirectory)_Dxxxxx.Api.dll v1
I'm getting this error No executable found matching command "dotnet-swagger"
Help!
Here is a working example using the JAR maintained by the Swagger Codegen team.
I used the public microsoft speech-to-text-api-v3 API but feel free to change it.
trigger:
- master
variables:
jar_version: 3.0.29
- job: swagger_client
pool:
vmImage: 'ubuntu-latest'
steps:
- task: JavaToolInstaller#0
inputs:
versionSpec: '11'
jdkArchitectureOption: 'x64'
jdkSourceOption: 'PreInstalled'
displayName: 'Set-up Java'
- script: |
java -version
wget https://repo1.maven.org/maven2/io/swagger/codegen/v3/swagger-codegen-cli/$(jar_version)/swagger-codegen-cli-$(jar_version).jar -O swagger-codegen-cli.jar
java -jar swagger-codegen-cli.jar generate \
-i https://westus.dev.cognitive.microsoft.com/docs/services/speech-to-text-api-v3-0/export\?DocumentFormat\=Swagger\&ApiName\=Speech%20to%20Text%20API%20v3.0 \
-l python \
-o lib/python-client
- task: DownloadPipelineArtifact#2
inputs:
patterns: 'python-client/**'
path: $(Build.SourcesDirectory)/lib/python-client
I am writing in C# .NET core (VS 2017), using the build for linux containers, using docker-compose.
When I build the image (or publish), there is always reference to the internet, because of nuget usage.
Last error encountered (which I persume of downtime on the nuget, but no matter
- any downtime should not lead to exception in build/publish).
/usr/share/dotnet/sdk/2.1.503/NuGet.targets(114,5): error : Unable to
load the service index for source https://api.nuget.org/v3/index.json. ...
I want to build the image, even the nuget is down, or even there is no interet connection
The yml file look like this:
services:
myProj:
image: my_proj
build:
context: ./all_projects/base_solution/
dockerfile: myProj/Dockerfile
It seems that "dotnet publish..." command call restore from the internet.
If I run publish with --no-restore, the code not compiled, but I want to restore the nuget packages from my own pre-build of my computer.
How can I do it? With no internet connection? Why should I depend on the internet to restore the nuget at each build?
Why cannot I restore nuget package from my own pre-build image, and not always?! get from nuget (actually nuget packages not change occasionally in my code).
May I just copy the folder from the nuget, and not using "COPY" command?
I did the following:
Build an image from a 'common' project, that uses all the nuget package.
Add a reference in the built-image for the new other image, like this:
Create a new common image:
# there is no runtime.
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY TestDock/TestDock.csproj TestDock/
FROM build AS publish
RUN dotnet publish TestDock.csproj -c Release -o /app
And at the original image:
FROM microsoft/dotnet:2.1-runtime AS base
WORKDIR /app
# FROM microsoft/dotnet:2.1-sdk AS build do:
FROM my_common_image AS build
WORKDIR /src
COPY TestDock/TestDock.csproj TestDock/
# Added the following. I tried to copy all, but this doesn't help.
# I persume I can copy part of the common build.
COPY --from=build /app /app
COPY --from=build /src /src
COPY --from=build /usr /usr
FROM build AS publish
RUN dotnet publish TestDock.csproj --no-restore --no-dependecies -c Release -o /app
FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "TestDock.dll"]
I have tried to add an intermediate image, with Dockerfile as following:
# This image is base image for all dockers (no need runtime)
# docker build . -f DockerFile_Common -t docker_common
FROM microsoft/dotnet:2.1-sdk AS build
COPY . .
WORKDIR /src/myProj
FROM build AS publish
RUN dotnet publish myProj.csproj -c Release -o /app
RUN dotnet pack /src/myProj.csproj -c Release -o /app
and use it in my image (that I don't want to build using the internet), instead of:
FROM microsoft/dotnet:2.1-sdk AS build
I did:
FROM docker_common AS build
I also tried to add the line: "RUN dotnet publish ..." when setting the workdir as the solution folder, and mark the "Microsoft Visual Studio Offline Packages" (unmark default "nuget.org").
Still, the above doesn't build correctly.
For not using the internet, you can follow the steps.
What is needed is to publish in visual studio, as following:
https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/visual-studio-publish-profiles?view=aspnetcore-2.2
(Alternative publish in command line).
dotnet publish myProj.csproj -c Release /p:PublishProfile=Properties\PublishProfiles\
<myprofile>.pubxml /p:PublishDir=<proj_folder>\bin\Release\netcoreapp2.1\publish
or put in the Post-build event a line like:
dotnet publish $(ProjectDir)$(ProjectName).csproj -c $(Configuration)
/p:PublishProfile=Properties\PublishProfiles\PublishProfile.pubxml
/p:PublishDir=$(TargetDir)publish --no-build
... and in the Dockerfile I just did with need to do "COPY ..." from the relevant publish directory!
FROM microsoft/dotnet:2.1-runtime
COPY MyProjectFolder/bin/Release/netcoreapp2.1/publish /app
WORKDIR /app
ENTRYPOINT ["dotnet", "myproject.dll"]
I can run the web application by using dotnet run on the .gitlab-ci.yml script.
stages:
- build
build:
stage: build
before_script:
- 'dotnet restore'
script:
- echo "Building the My Application"
- "dotnet publish Eitms.Decoder.sln -c release"
- "cd C:\\MyFolderContaints\\Eitms.Decoder.Backend"
- "dotnet run"
only:
- release
But how I can publish into the IIS? anyone can show the step?
Thanks
UPDATE
After view the script from HERE, still not success yet. Did I do something wrong here?
stages:
- build
- deploy
build:
stage: build
before_script:
- 'dotnet restore'
script:
- echo "Building the app"
- "dotnet publish Eitms.Decoder.sln -c release"
artifacts:
untracked: true
only:
- release
deploy_staging:
stage: deploy
script:
- echo "Deploy to IIS"
- "dotnet publish Eitms.Decoder.Backend\\Eitms.Decoder.Backend.csproj -c release -o C:\\Secret Path\\PRODUCTION\\Secret Project"
dependencies:
- build
only:
- release
I don't know is it still actual or not and also i never used GitLab CI
but looking on provided scripts i think you need just to copy (using CMD commands like xcopy) files into IIS folder after publish
like when you want to do same using CMD .bat file
Steps
publish project
stop appPool
copy files
start appPool
e.g (just for example)
dotnet publish "Eitms.Decoder.Backend\\Eitms.Decoder.Backend.csproj" -c release -o "C:\\Secret Path\\PRODUCTION\\Secret Project"
appcmd stop apppool /apppool.name:"Secret Project APP POOL"
xcopy "C:\\Secret Path\\PRODUCTION\\Secret Project" "C:\\inetpub\\wwwroot\\Secret Project" /s /e
appcmd start apppool /apppool.name:"Secret Project APP POOL"
I had the same requirement, and #Simon response helped me a lot. But when trying to apply it, I was confronted to some other problems that I have handled with an improved script
deploy_staging:
stage: deploy
script:
- 'dotnet publish WebProjectFolder\\WebProject.csproj -c release -o E:\\TemporaryLocation'
#I used powershell to stop the apppool.
#I also added a test to verify that the apppool is already Started. (If you try to stop a stopped apppool your job will fail)
- 'if ((Get-WebAppPoolState -Name pointeuse).Value -eq "Started") { Stop-WebAppPool -Name pointeuse }'
# I used /exclude so I doesn't copy config files (in my case it was web.config and appsettings.json)
# These config files already exists under my IIS because they contains specific configuration (So I copied them manually once because they do not change)
# deployignore.txt is a file that I added to the root of my solution (next to SolutionName.sln). It contains the config files that I don't want to copy (In my case it contains 2 lines web.config and appsettings.json)
# E:\\DeployLocation is the folder where your IIS site points to
- 'xcopy /s /e /y /exclude:deployignore.txt E:\\TemporaryLocation E:\\DeployLocation'
# Added the sleep because the app pool couldn't be started (maybe I can lower the sleep delay)
- sleep 10
- 'Start-WebAppPool -Name pointeuse'
only:
- master
Real thanks Simon.