The following command builds and publishes my functions to Azure. But it always builds in debug mode - how do I make it switch to building in release mode?
func azure functionapp publish NAME_OF_MY_FUNCIONS_RESOURCE
Update: When I compare the file sizes of the dlls in the Debug, Release and publish folders, the ones in the publish folder matches the ones in the Debug folder, and not the ones in the Release folder.
# Paths that I am comparing.
FunctionApps\bin\Debug\netstandard2.0\bin
FunctionApps\bin\Release\netstandard2.0\bin
FunctionApps\bin\publish\bin <-- Matches Debug\netstandard2.0\bin.
You may be confused about these output. (I work with c# function on Windows).
Actually right now when we use func azure functionapp publish to publish, both debug and publish content will be generated. And this command consumes files in publish folder.
To proof this, check the difference between Debug and publish folder. local.settings.json is copied to the former but not for the later, because the file is only useful in local dev. After I publish my function, this file is not uploaded. So I think the publish does work correctly in publish folder.
Update
Release folder doesn't exist if I only leverage function cli, you probably compare with Release folder generated by VSCode/VS or just dotnet publish --configuration Release manually.
Your assumption should be right. Even though the code to publish is put in bin\publish folder, it is built in debug mode. Have checked PDB file functionappname.pbd, its size is identical to the one in Debug folder(bigger than the one in Release folder).
Found the issue you opened, let's wait for Aure team's reply.
I asked the same question on GitHub and got answer there.
func azure functionapp publish NAME_OF_MY_FUNCIONS_RESOURCE \
--dotnet-cli-params -- "--configuration Release"
More details on GitHub: https://github.com/Azure/azure-functions-core-tools/issues/670.
Related
Has anyone used Azure DevOps to deploy an Umbraco v8 application to Azure?
I can successfully deploy via Visual Studio, but Azure DevOps only seems to copy over all the dlls to the target, no views or anything, and a zip does not get generated.
If anyone has managed this could they share the steps they took please?
The steps I have in the pipeline are:
Build
Test
Deploy
Publish Symbols
Copy File to
Publish Artifact
What I did notice is that I need a publish profile to successfully publish from Visual Studio, however I cant see where a profile should be included in Devops, unless it should be in the build arguments?
My current build arguments:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
I'm using the Visual Studio Build task.
To straight up answer your question, yes MSBuild arguments make or break the deployment here.You can see mine in my screenshot. I took it from a production deployment that's successful for Umbraco.
So I can't see your actual pipeline, but from what I see you don't actually 'build' the application.
As in you have to use Nuget first, then restore the packages, then build the application. You don't need to copy anything (so you don't need a copy step), with the correct MS Build arguments it will build and copy to build.artifactstagingdirectory on its own. Then you need to have the appropriate release pipeline, but one thing at a time. The build steps I use are underneath. After the npm custom step is the actual building of the application.
P.S. Make sure that the appropriate files to run the application are included in the csproj, because that's where azure devops reads what to pick and build.
I'll assume that you're simply copying files onto a VM and that you have dealt with the deployment of your database / content.
If you want to copy all the files from your Visual Studio project you need to ensure that your MSBuild will copy them into the build/artifact directory.
In order to copy the files that you're missing you need to ensure that you have set the “Build Action” to “Copy to output directory” for example your views or pretty much anything that you'd code in App_Data. This is how you'd set the build action in VS: https://learn.microsoft.com/en-us/visualstudio/ide/build-actions?view=vs-2019
I'm deploying an azure function app from package (using this guide - https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package) - this deploys correctly. Yet I can't seem to get an update deployed. Even after I upload a new package, changes are not picked up by azure function app. I tried stopping/starting the app to no avail.
How can I force it to pick up changes?
I ran into this issue with a newly deployed function using function v3, so this still seems to be an issue.
Short answer:
Remove the .zip in D:\home\data\SitePackages and then redeploy and your changes will get picked up.
Long answer
My setup is using ZIP deployment and WEBSITE_RUN_FROM_PACKAGE = 1.
It helps to know what happens when you use ZIP deployment:
The zip file is not written to wwwroot of your site, but instead to D:\home\data\SitePackages (source: https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package)
Then the contents of the zip file is mounted to D:\home\site\wwwroot and run from there.
For some reason, the .zip in D:\home\data\SitePackages was not being replaced, it was still the old version. To fix that, I used the Console of the App Service to delete the file before redeploying.
Navigate to your App Service function and open the Console (under Development tools section)
Run cd D:\home\data\SitePackages and then ls to see the files in the folder.
Run a rm command to remove both the zip and text file.
Redeploy your function, and you will see that changes are picked up.
We had a very weird problem using Azure Function App Deploy from Azure DevOps.
This worked perfectly until we one day made some code changes to the Azure Function that worked locally but not on our dev server. We started looking at the .zip file and the release pipeline but everything looked good here. We could also see that nothing had changed in our azure-pipelines.yml or release pipeline:
Git command: git log -p azure-pipelines.yml
For releases we used the Azure Functions task by Microsoft Corporation.
Looking at the release logs everything seemed good as well:
We then logged in to Kudu (Advanced Tools) and used powershell to look at the files deployed.
https://<your-function>.scm.azurewebsites.net/DebugConsole/?shell=powershell
Running the command dir D:\home\site\wwwroot we could see that the files had not been updated and when we looked at dir D:\home\data\SitePackages we could not see a new .zip file either.
Confirmed wrong .zip by running the command Get-Content D:\home\data\SitePackages\packagename.txt to see which .zip is being used.
Then wen't back to Azure DevOps and tried to create a new release but the files still did not update. Then I tried to clone the Azure Function App Deploy step that had previously worked and disabled the other one. Tried a new release and now everything worked.
I think this must be a Microsoft bug since we did not really change any values at all. Hope this can help someone else and that Microsoft fixes this.
If you replace old package using new one with the same package name(to leverage the same sas url), make sure the old one is overwritten. And you have to click the refresh button next to Function app to sync triggers along with the changes.
Update
I recommend using the publish command(func azure functionapp publish <functionAppName>) provided by Azure Function Core Tools(Cli). V2 Cli benefits from Run from package as well and automates the whole process for us(zip the folder, upload, create app setting, sync triggers).
The command get publishing info(username, password for deployment) first, then
Archives function project.
Uploads zip file(name is in the format of UTCTime-GUID.zip) to function-releases container in Storage account specified by AzureWebJobsStorage app setting.
Create an app setting WEBSITE_RUN_FROM_ZIP(original name of WEBSITE_RUN_FROM_PACKAGE, both work) with SAS Url.
Sync triggers to pick up changes.
After all efforts, the only thing I really determined was that you need to restart - and then wait. About 15-20 minutes after restart the changes were automagically there.
If you try to deploy with new JAR/ZIP to function-app , the changes will be reflected within 1-2 mins
* Make sure that you are using correct value for WEBSITE_RUN_FROM_PACKAGE
* Download the content from console and check whether its same or not
I had the same problem, after changing the deployment to use WEBSITE_RUN_FROM_PACKAGE. I think the problem is that it is using the cached deployment tool, so it's using the previous deployment script, not a new one when you change how you want it to deploy.
If you look at the deploy log in azure devops there is a link to the deploy log in the kudu interface:
I found this answer which explains how to fix it.
We have 2 Azure Webjobs connected to our ASP WebApi application. None of them is using any dependencies from the other one. And yet, after publishing, one of them has executables from the other one. It's worth mantioning that this only happens on publish. Everything is normal on VS build.
This is how files hierachy looks like on Azure FTP
The first one, Deployment, is being published as expected. Those are executables in it's folder:
The second one, EmailSender, has executables from the Deployment:
What's curious, there is also app.publish folder in both of them, containing only one and the same file WebJob.Deployment.exe:
Deployment job works fine. Unfortunately Azure don't recognize EmailSender job, instead it executes Deployment. The only solution that works right now is to manualy delete Deployment's executables directly from FTP, on every publish.
Right now we tried couple of things from SO and blogs, but with no success.
Microsoft.Web.WebJobs.Publish producing duplicate assemblies in deploy package
Azure Webjobs not getting updated after new publish
GitHub solution
Azure Web Job Run Command Incorrectly Set
Edit:
I did accomplished something. It did not resolve the problem, but we don't have app.publish folder anymore. Here is the link to solution on SO. I don't know why we had 'ClickOnce security' options checked for WebJob.Deployment application.
Update:
I run few tests with MSBuild and found something curious. As I said before, Visual Studio Publish works just fine - no additional executables are deployed. But when I run MSBuildprogram (with the same publish profile and project configuration) I got additional Deployment.exe inside EmailsSender folder. This is the command I run:
MSBuild RestAPI.Host.csproj /t:Build /p:Configuration="Develop" /p:Platform="AnyCPU" /p:DocumentationFile="RestAPI.Host.XML" /p:DeployOnBuild="true" /p:PublishProfile="fakebuild_develop.pubxml" /p:OutputPath="backend\build\app\\" /p:SolutionDir="backend\\"
Can someone tell me what's the difference between MSBuild and VS Publish? I cannot find anything usefull on the internet.
I'm confused about deployment webjobs to azure.
I'm using .net core, so I manaully publish my webjobs in my deploy.cmd file, for example like this:
call :ExecuteCmd dotnet publish "%DEPLOYMENT_SOURCE%\My.WebJobs\Mt.WebJobs.csproj" --output "%DEPLOYMENT_TEMP%\App_Data\Jobs\Continuous\MyWebJobs" --configuration Release
That then deploys the webjob to the deployment_temp folder. After that, KuduSync kicks in and syncs to DEPLOYMENT_TARGET which is d:\home\site\wwwroot I can see in there if I look, that there is a App_Data\Jobs\Continuous\MyWebJobs folder, and that ALL my files have been correctly deployed and sync-ed up to that folder.
However, when I run the webjob, it reports it's running from a totally different location (D:\local\Temp\jobs\continuous\MyCustomerIO\bp003r3f.h2g). And when I look in that folder, I see most of my deployed webjob files, but some JSON configuration files that are in App_Data... are missing from here.
So - why is my webjob running from here? And why are some of my deployed files missing?
why is my webjob running from here?
The WebJob is copied to a temporary directory under %TEMP%\jobs\{job type}\{job name}\{random name} and will run from there. This option prevents the original WebJob binaries from being locked which might cause issues redeploying the WebJob.
The WebJob is run directly from the WebJob binaries directory. We call this option in place. This option can have the locking issue and should only be used when there is no risk of locking the file.
By default the first option is used (in place = false).You can explicitly configure this setting in your settings.job. e.g.
{ "is_in_place": true/false }
And why are some of my deployed files missing?
I tested and reproduced this situation too. But I did not find solution to solve this. I suggest that you could use Environment.GetEnvironmentVariable("WEBJOBS_ROOT_PATH"); to get the root path
direcroty of webjob.
WEBJOBS_ROOT_PATH which is location of webjob files, you can specify an absolute path, or otherwise the value will be combined with the default root path:
D:/home/site/wwwroot/ + WEBJOBS_ROOT_PATH(relative) to get webjob_name, webjob_run_id and so on.
For more detail, you could read this article.
I am trying to create automated build to publish a folder with files onto Azure web-site. And I cannot accomplish this.
I am NOT publishing a solution (.sln), but rather a folder with files. I am using VS2013 and Visual Studio Online.
I have experience with TFS web publishing, so I published solutions many times.
So, what I did so far:
Created an MSBuild build.xml file that just copies files from the folder to the output.
Created a build definition based on AzureContinuousDeployment.11.xaml
Specified build.xml in my build definition, Process tab, in "Solution to build" parameter:
If I build my project, it is correctly built, files are copied to the output, etc (I can verify it by opening drop location, all files are there).
Then, I:
Created a web-site in Azure, linked it to my TFS subscription.
Downloaded a publish profile (.PublishSettings from a web-site).
Created a Web publish profile (.pubxml) in Visual Studio based on .PublishSettings file).
Specified Web Deploy Publish Profile and Deployment Settings Name:
But now I am getting an error during build:
Exception Message: Please specify a Visual Studio Solution (.sln) to build. (type BuildFromSolutionException)
So it asks me for a Visual Studio solution, but earlier it worked perfectly with MSBuild file (after step 3).
I tried to rename my .xml to .sln (probably it is not what I should have done), and build now says "There was no Windows Azure project (.ccproj) detected in the solution. Continuous delivery to an Azure Cloud Service requires an Azure project. (type CCProjNotFoundException)"
If I don't specify "Deployment Settings Name", build completes without errors, but again no publishing to Azure.
So, the question is, how to publish a custom MSBuild build, without a solution, onto Azure? Is TFS continuous Azure publishing for Solutions only? I expect it to be agile, like I published folders from Local Git to Web-site without any hassle.
What should I do?
There are a few confused ideas in your question. Fits, there is no relationship between and automated build and Git. You are using Team Foundation Build to run the workflow of deployment. It is the workflow that is not working for you. In effect the build and deployment script. In fact the script you are using works with both Git and TFVC so that is not the issue.
That specific script is designed specifically for building an azure project that is then continuously delivers to Azure and you likley can't use it as you are. You can however create another script and use that. I would suggest you try instead to use the Default build script and use a powershell script within the build to collect the files and then push them to Azure.
If you want to go a little more advanced you could create a copy of the default and make one that does not require MSBuild at all.