If you have deleted a release definition, either intentionally or by mistake, currently there is no way to restore it through the UI. However, there is a way to recover it using a simple PowerShell script. The details for the script can be found here.
A couple of points to note about running the script.
- The script will only work within 4 weeks of the definition being deleted.
- You will need to create a Personal Access Token (PAT) within your DevOps account. Details for creating your PAT are available here.
- You do not need to encode the $accountName, $projectName and $definitionNameToRecover variables. Values containing spaces will work.
- The script will recover the release definition but not the release history
When calling a Function App that returns a 202 (Accepted) Status Code I found my HTTP action in my Logic App was returning a status code of 405 with the a message of “The HTTP ‘GET’ method is not supported by the ‘GenericJsonWebHookReceiver’ WebHook receiver.”.
This seemed a bit odd because I had tested my Function App using the exact same request using Postman and it was returning a valid 202 response. After reading a bit more about HTTP Actions (https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-workflow-actions-triggers#http-action) the section on Asynchronous Patterns gave me the answer. To disable the asynchronous behavior previously described, set operationOptions to DisableAsyncPattern in the action inputs. In this case, the action’s output is based on the initial 202 response from the server.
Having made this change to the Logic App the server response was accepted and considered a success.
I needed a way to get read access to a local XML file in the Azure Web App that is not a .config file. Using the standard naming format for the root folder I can read the XML data file into a DataSet.
DataSet dataSet = new DataSet();
var wscXML = string.Concat(Environment.GetEnvironmentVariable("HOME", EnvironmentVariableTarget.Process), @"\site\wwwroot\wsc.xml");
When you install Visual Studio 2017 it very kindly gives you the option to install Node.js
The only problem with this is that if you are not using v15.3 (or greater) of VS2017 then working with Azure Functions can present a couple of unusal issues.
- Not being able to install the Azure Client Tools.
- My application not being able to read from the local.settings.json file using the WebConfigurationManager.
The problem turned out to be the version of Node.js that was installed with Visual Studio and that I needed to update it to a more recent version. After completing the updated installation I was able to install the Azure tools and successfully read values from my local.settings.json file in my local development environment.
I had been running my Azure Functions locally to debug the processes when this morning the func.exe kept failing each time I pressed F5 and would not allow me to debug my code. The Storage Emulator on my machine was started and I could access it through the Storage Explorer and my application Properties were correct but func.exe would not fire up.
After a bit of head scratching I decided to fire up the func.exe outside of Visual Studio and run it against my project and func gave me the answer straight away.
I had been playing around with my local.settings.json and the entry for AzureWebJobsStorage was empty. Because the func.exe shuts down straight away when running in Visual Studio I wasn’t able to see the error but I could when I ran it outside of the IDE.
As with any (relatively) new Azure app there is always pain mixed in with the pleasure. The simplicity of the Logic Apps Designer can throw in curve balls that can only be handled in the Code View.
A good example of this is the SQL -Get Row connector and what happens if the row is not found.
The default logic here is to look for the row and then progress if the Row Id can be matched, and in the Designer view this is all handled for you. But what if you want a condition where you want to handle this failure. The Designer allows us to put in a check for the failure, although you have to edit it in Advanced mode. The problem is that the Designer does not let you allow ‘Failed’ as a valid option.
In the Designer view this is not obvious (at the moment) so you need to switch to the Code view. The default runAfter option (for the Condition) is set to ‘Succeeded’
"Get_row" : [ "Succeeded" ]
So what we need to do is add ‘Failed’ as a valid option
"Get_row" : [ "Succeeded", "Failed" ]
The ‘Get row’ is then able to succeed by failure when no matching row is found and the Condition check will be evaluated correctly.