Azure Functions in .NET 7 (isolated) published to Azure, 0 functions loaded - c#

I'm trying to deploy an Azure Function (isolated) with .NET 7 to MS Azure using a GitHub Actions workflow. Everything seems to run fine, but for some reason, the Function is not loaded when I deploy it to the cloud. When I run the function local host, everything is fine (works on my machine), once deployed it doesn't.
public class DemoFunction
{
private readonly ILogger _logger;
public DemoFunction(ILoggerFactory loggerFactory)
{
_logger = loggerFactory.CreateLogger<DemoFunction>();
}
[Function("DemoFunction")]
public HttpResponseData Run([HttpTrigger(AuthorizationLevel.Anonymous, "get", "post")] HttpRequestData req)
{
var response = req.CreateResponse(HttpStatusCode.OK);
response.Headers.Add("Content-Type", "text/plain; charset=utf-8");
response.WriteString("Demo function works!");
return response;
}
}
The Function App contains only a single function with an HTTP binding (no authentication, anonymous requests allowed). I use Bicep to deploy infra and GH Actions to deploy the Function App. Log Analytics shows this:
So for some reason it does find the function, but not load it. If I navigate to the Functions blade in the Azure Portal I don't see any function. The project is just a POC project and hosted publicly available at https://github.com/nikneem/function-deployment-with-gh-actions
Any ideas?


Oh wow, I found the answer in the deployment process. In my GitHub Actions workflow, I did a dotnet publish of the Azure Functions project to an output folder. I zipped the content of the output folder and published that zip file as a workflow artifact.
Then in the deployment, I downloaded the workflow artifact (e.g. that zip file) and did a Zip Deployment using that zip file.
Now apparently, something went wrong with this zip file, so I removed that manual zip action, mainly because I found out the deployment step in the GitHub Action also works when you pass a folder containing all published files in.
So the publish step in my GH Actions workflow now looks like this:
publish-functions:
runs-on: ubuntu-latest
needs: versionize
steps:
- uses: actions/checkout#v3
- uses: actions/setup-dotnet#v3
with:
dotnet-version: "7.0.x"
- name: Restore packages
working-directory: src
run: dotnet restore
- name: Publish functions app
working-directory: src
run: dotnet publish $FUNCTIONS_PATH/$FUNCTIONS_PROJECT -c Release --no-restore -o functionsout /p:Version=${{needs.versionize.outputs.semver}}
- name: Upload functions artifact
uses: actions/upload-artifact#v3
with:
name: player-functions
path: src/functionsout/*
and the deployment step looks like this:
deploy-function-app:
runs-on: ubuntu-latest
needs: [publish-functions, deploy-infrastructure-prod]
steps:
- uses: actions/download-artifact#v3
with:
name: player-functions
path: function
- uses: azure/login#v1
with:
creds: ${{secrets.AZURE_PROD}}
- name: Deploy Azure Functions app
uses: Azure/functions-action#v1
with:
app-name: ${{needs.deploy-infrastructure-prod.outputs.functionResourceName}}
package: function
Taking a peek at the logs that the deployment process produces, it will still create a zip file and deploy that. But this is a different zip file than I created manually. All works fine now ;)


As per the note in this documentation:
To be able to publish your isolated function project to either a Windows or a Linux function app in Azure, you must set a value of dotnet-isolated in the remote FUNCTIONS_WORKER_RUNTIME application setting. To support zip deployment and running from the deployment package on Linux, you also need to update the linuxFxVersion site config setting to DOTNET-ISOLATED|7.0. To learn more, see Manual version updates on Linux.
I can see the relevant configuration settings appear to be set correctly in the infrastructure template with the exception of linuxFxVersion - this doesn't seem to be mentioned anywhere and the cicd workflow does appear to be performing a zip deployment.

Related

Azure FunctionApp Dependency Injection Error only if deploying through Azure Devops

When I deploy my function app with the command
func azure functionapp publish '<name>' --dotnet it successfully packages my code and publishes it to the function app, and everything works.
I'm now working on building out automation pipelines, and I created a pipeline with the following stages
- stage: Build
displayName: Build stage
jobs:
- job: Build
displayName: Build
pool:
vmImage: $(vmImageName)
steps:
- task: UseDotNet#2
displayName: 'Use .NET 6 Core sdk'
inputs:
packageType: 'sdk'
version: '6.0.402'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: 'build'
projects: |
$(workingDirectory)/*.csproj
arguments: --output $(System.DefaultWorkingDirectory)/publish_output --configuration Release
- task: ArchiveFiles#2
displayName: 'Archive files'
inputs:
rootFolderOrFile: '$(System.DefaultWorkingDirectory)/publish_output'
includeRootFolder: false
archiveType: zip
archiveFile: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
replaceExistingArchive: true
- publish: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip
artifact: drop
which packages the app and
- stage: Deploy
displayName: Deploy stage
dependsOn: Build
condition: succeeded()
jobs:
- deployment: Deploy
displayName: Deploy
environment: 'development'
pool:
vmImage: $(vmImageName)
strategy:
runOnce:
deploy:
steps:
- task: AzureFunctionApp#1
displayName: 'Azure functions app deploy'
inputs:
azureSubscription: $(azureSubscription)
appType: functionApp
appName: $(functionAppName)
slotName: $(slotName)
package: '$(Pipeline.Workspace)/drop/$(Build.BuildId).zip'
- task: AzureAppServiceManage#0
inputs:
azureSubscription: $(azureSubscription)
Action: 'Swap Slots'
WebAppName: $(functionAppName)
ResourceGroupName: 'group-name'
SourceSlot: $(slotName)
SwapWithProduction: true
It builds perfectly fine and then it also deploys and swaps the function app slots without any error.
The issue is that after it does this, everything is broken when making requests the function endpoints. I either get 404 errors saying my function endpoints don't exist, or I get 500 dependency injection errors. To escape this chaos I locally run func azure functionapp publish '<name>' --dotnet again on the exact same code that was deployed through the pipeline and then everything works fine.
I also tried deploying straight to the production slot instead of swapping, and the result is the same through the pipeline.
I am using the exact same version of dotnet locally as I am in the pipeline. Without any good errors to help me understand why it says it deployed without issue but everything is broken, it's hard for me to figure out what's going on.
Does anyone have any idea what's going on?
Here is the dependency Injection error:
System.InvalidOperationException : Unable to resolve service for type
'Api.Request.Services.User' while attempting to activate
'Api.Request.Functions.Create'.at
Microsoft.Extensions.DependencyInjection.ActivatorUtilities.GetService(IServiceProvider
sp,Type type,Type requiredBy,Boolean isDefaultParameterRequired)at
lambda_method331(Closure ,IServiceProvider ,Object[] )at
Microsoft.Azure.WebJobs.Host.Executors.DefaultJobActivator.CreateInstance[T](IServiceProvider
serviceProvider) at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\DefaultJobActivator.cs
: 42at
Microsoft.Azure.WebJobs.Host.Executors.DefaultJobActivator.CreateInstance[T](IFunctionInstanceEx
functionInstance) at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\DefaultJobActivator.cs
: 31at
Microsoft.Azure.WebJobs.Host.Executors.ActivatorInstanceFactory1.<>c__DisplayClass1_1.<.ctor>b__0(IFunctionInstanceEx i) at C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\ActivatorInstanceFactory.cs : 20at Microsoft.Azure.WebJobs.Host.Executors.ActivatorInstanceFactory1.Create(IFunctionInstanceEx
functionInstance) at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\ActivatorInstanceFactory.cs
: 26at
Microsoft.Azure.WebJobs.Host.Executors.FunctionInvoker`2.CreateInstance(IFunctionInstanceEx
functionInstance) at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\FunctionInvoker.cs
: 44at
Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.ParameterHelper.Initialize()
at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\FunctionExecutor.cs
: 791at async
Microsoft.Azure.WebJobs.Host.Executors.FunctionExecutor.TryExecuteAsync(IFunctionInstance
functionInstance,CancellationToken cancellationToken) at
C:\projects\azure-webjobs-sdk-rqm4t\src\Microsoft.Azure.WebJobs.Host\Executors\FunctionExecutor.cs
: 104
but I am including it in Startup.cs
services.AddScoped<Services.User>();
Also, I am using in-process function apps, could that be why everything is breaking in the pipeline? I just don't get why it works perfect if I use the func command and doesn't work at all when I use the function azure provides in the pipeline. Isn't this all MS, so shouldn't the underlying publish mechanisms be the same?
EDIT
One thing I've just found is that the files in /home/wwwroot are different when deploying through the pipeline and through the func azure functionapp command. When deploying through the pipeline it has a lot more files in it. I'm wondering if it's building the project incorrectly..

The issue was that I had thought I was building/zipping and deploying my code correctly, but it wasn't being packaged the same way that it was locally.
Using Kudu to view the deployed files showed me that everything was being placed in the /home/wwwroot directory instead of having most of the built files being placed in the /bin directory. This explained why I was getting the unexpected behavior. After I altered my build script, I was able to get it to properly build and deploy my code changes.

Change variables in appsettings when deploying with github actions

I am trying to deploy an app with github actions. I linked my azure account to my github repository and the following actions has been created:
name: Build and deploy ASP.Net Core app to Azure Web App - my_app_name
on:
push:
branches:
- master
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#master
- name: Set up .NET Core
uses: actions/setup-dotnet#v1
with:
dotnet-version: '3.1.102'
- name: Build with dotnet
run: dotnet build --configuration Release
- name: dotnet publish
run: dotnet publish -c Release -o ${{env.DOTNET_ROOT}}/myapp
- name: Deploy to Azure Web App
uses: azure/webapps-deploy#v1
with:
app-name: 'my_app_name'
slot-name: 'production'
publish-profile: ${{ secrets.AzureAppService_PublishProfile_xxxxxx }}
package: ${{env.DOTNET_ROOT}}/myapp
I have some variables in my appsettings.json file that I want to overwrite, but I don't find how to do it.

You may add the following action prior to deploying the artifacts to azure.
You can specify multiple files and it is supported with wildcard entries too.
The environment variable key must be specified with dot separated heirarchy.
#substitute production appsettings entries to appsettings json file
- name: App Settings Variable Substitution
uses: microsoft/variable-substitution#v1
with:
files: '${{env.DOTNET_ROOT}}/myapp/appsettings.json'
env:
ConnectionStrings.Default: ${{ secrets.SOME_CONNECTION_STRING }}
App.ServerRootAddress: ${{ env.SERVER_ROOT_ADDRESS }}
The above action can be used for xml and yaml file changes too.

Deploy a C# Stateful Service Fabric application from Visual Studio to Linux

EDIT 04/06/18 => Updated question with last status
So I have this working .Net 4.6 Stateful Service that currently run on my Windows Service Fabric cluster deployed on Azure.
Starting from 09/2017, I should be able to move to Linux: https://blogs.msdn.microsoft.com/azureservicefabric/2017/09/25/service-fabric-6-0-release/
So I'm trying to deploy it on Linux so I can save costs.
First things first, I've migrated all my code from .Net 4.6 to .Net Core 2.0. Now I can compile my binaries without issues. I've basically created new .Net Core projects and then moved all my source code from .Net 4.6 projects to the new .Net Core ones.
Then I've updated my Service Fabric application. I removed my previous SF services from my sfproj, then I've added my new .Net Core ones.
Looks like there is a warning (nothing on the output window though), but it's here anyway if I try to create a new empty Statful service using .Net core 2.0 through the template provided by Service Fabric Tools 2.0 (beta):
So I'm going to live with it.
On my dev machine, I've modified the 2 csproj projects that contain my Stateful services so they can run locally as Windows executables. I've used the win7-x64 runtimeIdentifier.
Running my SF cluster locally on my Windows machine is fine.
Then I've slightly changed the previous csproj files for Linux. I used the ubuntu.16.10-x64 runtimeIdentifier.
Also I've changed the ServiceManifest.xml file to target the linux-compatible binary:
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.9.6">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is a basic script that eventually executes:
dotnet $DIR/MyService.dll
Then I've successfully deployed to my secured SF Linux cluster from Visual Studio. Unfortunately I have the following errors for both my stateful services:
Error event: SourceId='System.Hosting',
Property='CodePackageActivation:Code:EntryPoint'. There was an error
during CodePackage activation.The service host terminated with exit
code:134
Looks like my binary crashes when starting. So here are my questions:
Is the approach right to deploy a C# .Net Core SF stateful service on Linux from Visual Studio?
EDIT: looking inside the LinuxsyslogVer2v0 table, I get the following error:
starthost.sh[100041]: Unhandled Exception:
System.IO.FileLoadException: Could not load file or assembly
'System.Threading.Thread, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest
definition does not match the assembly reference. (Exception from
HRESULT: 0x80131040)
I found the following bug report: https://github.com/dotnet/sdk/issues/1502
Unfortunately, I still get the error without using MSBuild (using dotnet deploy).
EDIT: further clarification:
My boss want me to run on Linux because starting from D1v2 machines, it's half the price compared to Windows machines (no license etc.)
My .NET Core 2.0 services successfully run on Windows. So the .NET Core port should be fine.

So, this was a real pain in the ass to get it working properly. But it works. Well, kind of.
First, Reliable Services are still in preview on Linux: https://github.com/Microsoft/service-fabric/issues/71
Full Linux support should come very soon (actually it should be available already according to the previous link...).
Now for the details about how to procede, here is some information to help others, because there is just nothing about that on Microsoft documentation and I literally lost 3 days trying to make it work.
1. Do use .NET Core 2.0 for your projects.
It is supported on Linux. On preview for now, but it works.
2. Do use the right RID for your projects.
As of today (April 2018), the right RID to use is ubuntu.16.04-x64.
Edit the csproj files of your Reliable Service projects and set the RID like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
The fun part is, you should be able to provide multiple RIDs using the RuntimeIdentifiers parameter (with a S at the end) like that:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifiers>win7x64;ubuntu.16.04-x64</RuntimeIdentifiers>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
So you could build Windows binaries and Linux binaries at the same time.
But it simply doesn't work. When building the project from Visual Studio, I end up with the following directory only:
bin/Debug/netcoreapp2.0/
Only DLLs, no valid entry point. No win7-x64 folder, no ubuntu.16.04-x64, no nothing.
This is a bug, supposed to be fixed, but it's not (I use Visual Studio 15.6.2 all up-to-date as of today). See https://github.com/dotnet/core/issues/1039
3. You need a valid Entry Point for your service.
On Windows it's an executable file (*.exe). On Linux it's not. I ended up getting the Linux C# example and copied/pasted the entry point. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-create-your-first-linux-application-with-csharp
So basically I now have on my ServiceManifest.xml file of each Reliable Service the following EntryPoint :
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="XXXX"
Version="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<!-- This is the name of your ServiceType.
This name must match the string used in RegisterServiceType call in Program.cs. -->
<StatefulServiceType ServiceTypeName="YYY" HasPersistedState="true" />
</ServiceTypes>
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is as follows:
#!/usr/bin/env bash
check_errs()
{
# Function. Parameter 1 is the return code
if [ "${1}" -ne "0" ]; then
# make our script exit with the right error code.
exit ${1}
fi
}
DIR=`dirname $0`
echo 0x3f > /proc/self/coredump_filter
source $DIR/dotnet-include.sh
dotnet $DIR/NAME_OF_YOUR_SERVICE_DLL.dll $#
check_errs $?
dotnet-include.sh is as follows:
#!/bin/bash
. /etc/os-release
linuxDistrib=$ID
if [ $linuxDistrib = "rhel" ]; then
source scl_source enable rh-dotnet20
exitCode=$?
if [ $exitCode != 0 ]; then
echo "Failed: source scl_source enable rh-dotnet20 : ExitCode: $exitCode"
exit $exitCode
fi
fi
Both are inside the PackageRoot folder. I specified for both their properties so the Build Action is "Content" and the Copy to Output Directory is "Copy always".
4. Do NOT build using MSBuild !!
Yeah it is supposed to build Linux packages too, or at least it seems so, because MSBuild is able to produce the following files when you right click on your project and click "Build":
Don't trust the apparent success of the operation, it will miserably FAIL to properly execute when deployed. Some *.so files missing and other issues. MSBuild is buggy as hell and misbehaves regarding dependencies.
See for instance this bug report: https://github.com/dotnet/sdk/issues/1502
Still not fixed after almost a year...
Or https://github.com/dotnet/core/issues/977 (got this one, too).
5. Do write some PowerShell script to build the stuff by yourself.
I ended up reinventing the wheel using the following script to build my package:
# Creating binaries for service 1
cd DIRECTORY_OF_MY_SERVICE_1
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 2
cd ..\DIRECTORY_OF_MY_SERVICE_2
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 3
cd ..\DIRECTORY_OF_MY_SERVICE_3
dotnet publish -c Release -r ubuntu.16.04-x64
# Copying ApplicationManifest.xml
cd ..
mkdir PKG\ServiceFabricApplication
echo F|xcopy "ServiceFabricApplication\ApplicationPackageRoot\ApplicationManifest.xml" "PKG\ServiceFabricApplication\ApplicationManifest.xml" /sy
# Copying Service1 files
mkdir "PKG\ServiceFabricApplication\Service1Pkg"
mkdir "PKG\ServiceFabricApplication\Service1Pkg\Code"
xcopy "Service1\PackageRoot\*" "PKG\ServiceFabricApplication\Service1Pkg" /sy /D
xcopy "Service1\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service1Pkg\Code" /sy
# Copying Service2 files
mkdir "PKG\ServiceFabricApplication\Service2Pkg"
mkdir "PKG\ServiceFabricApplication\Service2Pkg\Code"
xcopy "Service2\PackageRoot\*" "PKG\ServiceFabricApplication\Service2Pkg" /sy /D
xcopy "Service2\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service2Pkg\Code" /sy
# Copying Service3 files
mkdir "PKG\ServiceFabricApplication\Service3Pkg"
mkdir "PKG\ServiceFabricApplication\Service3Pkg\Code"
xcopy "Service3\PackageRoot\*" "PKG\ServiceFabricApplication\Service3Pkg" /sy /D
xcopy "Service3\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service3Pkg\Code" /sy
# Compresses the package
Write-host "Compressing package..."
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath .\PKG\ServiceFabricApplication -CompressPackage -SkipCopy
sfproj file is a Visual Studio / MSBuild related project, so you need to build everything by yourself.
The script above produces the same content as the pkg folder created by MSBuild when building your sfproj using Visual Studio. It copies everything on a PKG folder at the root of your solution.
The package structure is detailed here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/service-fabric/service-fabric-package-apps.md
6. Now it's time to deploy!
At this point I didn't trusted Visual Studio anymore, so I built my own PowerShell script:
. .\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1 -ApplicationPackagePath '.\PKG\ServiceFabricApplication' -PublishProfileFile '.\ServiceFabricApplication\PublishProfiles\Cloud.xml' -DeployOnly:$false -ApplicationParameter:#{} -UnregisterUnusedApplicationVersionsAfterUpgrade $false -OverrideUpgradeBehavior 'None' -OverwriteBehavior 'SameAppTypeAndVersion' -SkipPackageValidation:$false -ErrorAction Stop
It reuses the Deploy-FabricApplication.ps1 script provided by the Service Fabric project template inside the sfproj project. This script parses the Cloud.xml PublishProfile and deploys to your service fabric cluster.
So you specifies the rights values on both PublishProfiles/Cloud.xml and ApplicationParameters/Cloud.xml then execute the script.
It only works if you have the certificate used to secure the cluster installed on your machine, of course.
Do note the first dot '.' is important, because if you don't use it, you'll have the following error:
Get-ServiceFabricClusterManifest : Cluster connection instance is null
See https://stackoverflow.com/a/38104087/870604
Oh, and as there are bugs on the Service Fabric SDK too, you might want to shutdown your local SF cluster too...
https://github.com/Azure/service-fabric-issues/issues/821
7. Now it's time for another deception.
It simply doesn't work, the service crashes on startup. After searching hours inside the LinuxsyslogVer2v0 Azure Storage table (the log table for Linux, located in one of the two Azure Storage Accounts created automatically with the SF cluster), I found that Microsoft own Nuget Packages were buggy too.
Specifically, the Nuget package Microsoft.Azure.Devices doesn't work on version 1.6.0. An issue with a reference of a dll not found or whatever. I rollbacked to a previous version, namely 1.5.1, and it was fixed.
At this point I didn't had anymore energy to create another Github issue about that. Sorry MS, I'm not your QA team, I'm getting tired.
8. Build again using the first PowerShell script, deploy using the second PowerShell script, and you're done.
You've finally deployed C# Reliable Services using .NET Core 2.0 from Visual Studio (kind of, as it's buggy and I used PowerShell) on Windows to a Linux SF Cluster.
Now I still have issues with my ASP.NET Core service, but it will be a story for another day.
Conclusion: TL;DR
The whole thing is a mess. Bugs everywhere. In the SDK, in the tools, in some of Microsoft Nuget Packages. Awful experience. But it is supported (in preview for now) and you can make it work. Hope this post will help...

I was having similar issues, but I believe this is the issue:
In this release, .NET Core 2.0 services are only supported on Service Fabric for Windows. Full cross-platform support for .NET Core 2.0 services on Windows and Linux is coming soon.
From the Service Fabric 6.1 Release Notes
So no Linux as long as you are targeting .net core 2.0.

I have success deploy to Linux service fabric with this help
Open all the service .csproj files and update the RuntimeIdentifier as shown below
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
</PropertyGroup>
Update the ServiceManifest.xml to remove .exe extension as shown below
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>Web1</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
See https://blogs.msdn.microsoft.com/premier_developer/2018/05/27/running-net-core-2-0-applications-in-a-linux-service-fabric-cluster-on-azure/
*Visual Studio 15.7.3

No executable found matching command "dotnet-/../.dll" when running dotnet core docker image in Azure Web App on Linux

1. Background
I'm currently working on the following build/deployment pipeline:
Github (https://github.com/devedse/DeveMazeGeneratorCore)
Travis Build (https://travis-ci.org/devedse/DeveMazeGeneratorCore/jobs/196910720)
dotnet restore
dotnet build
dotnet publish
docker create image
docker publish image to hub
Docker image hub (https://hub.docker.com/r/devedse/devemazegeneratorcore/)
Use Azure Web App on Linux to execute deployment (http://devemazegeneratorcoredocker.azurewebsites.net/api/mazes/MazePath/512/512)
.
2. Problem
Whenever I push something to the Github repository, a build is kicked off and step 1-3 are being executed correctly.
However, the website on Azure is unreachable.
I used SCM to browse to the debug console (https://devemazegeneratorcoredocker.scm.azurewebsites.net/DebugConsole/Default.cshtml (for future reference)) and executed the following commands to find the log files that were generated by Docker:
and then used the following commands to read them:
cat docker_128_err.log
cat docker_128_out.log
The out log showed the following results (which seem correct):
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
5040bd298390: Already exists
fce5728aad85: Already exists
76610ec20bf5: Already exists
51ee4768b31d: Already exists
4dc55ff439a1: Already exists
9cb727c7d7a0: Already exists
2bea08464ad0: Pulling fs layer
2bea08464ad0: Verifying Checksum
2bea08464ad0: Download complete
2bea08464ad0: Pull complete
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Downloaded newer image for devedse/devemazegeneratorcore:latest
Login Succeeded
latest: Pulling from devedse/devemazegeneratorcore
Digest: sha256:647f3db3daa3330b7eb109a1c604e5bd403c2c7089b3c18c5e9249a9805d3a4d
Status: Image is up to date for devedse/devemazegeneratorcore:latest
The error log however, shows the following errors:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"
The strange thing is, is that whenever I run the image locally, it all works fine:
docker run -it --rm -p 0.0.0.0:5001:80 devedse/devemazegeneratorcore:latest
Somehow there seems to be a difference in running a Docker image on a Linux machine in Azure, compared to my local Docker installation which runs the Docker images on the default VM that's being installed when you install Docker for Windows.
3. Configuration files used:
.travis.yml: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/.travis.yml)
Dockerfile: (https://github.com/devedse/DeveMazeGeneratorCore/blob/master/Scripts/Docker/Dockerfile)
4. Summary
So summarizing, it seems that running Docker on Azure is being executed in a different manner then when doing this locally. Does anyone have an idea on what this could be/how to solve it?
Again, (just for easy reference), the error:
2017-01-31T13:11:46.757760723Z No executable found matching command "dotnet-/home/DeveMazeGeneratorCoreWebPublish/DeveMazeGeneratorWeb.dll"

Modify your image to put your application bits somewhere other than /home.
/home is where Azure App Service on Linux bind-mounts the persistent site volume, which is a disk that is shared across instances and is persisted between restarts.
You don't have to use it (you may not have any use for it when running your own image), but anything in your image's /home will disappear at runtime.

Dotnet Restore Failed on Build Server

I have a little dotnet core application and want to build it on jenkins.
In order to make it happen, ive installed dotnet core on the build slave.
Locally i can restore with the same command successfuly (even on my mac)
dotnet restore --configfile .nuget/NuGet.Config
On the build server the restore fails for one package.
Started by user jenkins
Building remotely on 2c3bff31e594 in workspace /root/workspace/Test
Cloning the remote Git repository
...
+ dotnet restore --configfile .nuget/NuGet.Config
Welcome to .NET Core!
---------------------
...
log : Installing System.Runtime 4.1.0-rc2-24027.
log : Installing System.Diagnostics.Tools 4.0.1-rc2-24027.
log : Installing System.Reflection.Extensions 4.0.1-rc2-24027.
...
log : Restoring packages for /root/workspace/Test/test/Test.DataAccess.Tests/project.json...
log : Failed to download package from 'https://api.nuget.org/v3-flatcontainer/remotion.linq/2.1.1/remotion.linq.2.1.1.nupkg'.
log : Response status code does not indicate success: 404 (Not Found).
The strange thing here is, that if i hit the url
"https://api.nuget.org/v3-flatcontainer/remotion.linq/2.1.1/remotion.linq.2.1.1.nupkg" link from the log, the package is their.

probably a firewall or any other local setting
probably firewall. id install fiddler on the computer and look what is the exact request
add fiddler as nuget porxy like this:
https://docs.nuget.org/consume/nuget-config-settings#proxy-settings
Proxy settings
section: config
keys: http_proxy, http_proxy.user, http_proxy.password and no_proxy.
Allows you to set the proxy settings to be used while connecting to your NuGet feed. More details here.
This key can be added using NuGet.exe Config -Set command.
It can also be set via environment variables http_proxy and no_proxy. http_proxy should be specified in the format http://[username]:[password]#proxy.com whereas no_proxy should be a comma-separated list of domains to bypass the proxy server.
Note
The "http_proxy.password" key value is encrypted before storing in the nuget.config file. Hence it can not be added manually by directly updating the config file.

Categories

Resources