lkgforit

{tocify} $title={Table of Contents} You can publish actions in GitHub Marketplace and share actions you've created with the GitHub community. Before you can publish an action, you'll need to create an action in your repository. For more information, see "Creating actions." When you plan to publish your action to GitHub Marketplace, you'll need ensure that the repository only includes the metadata file, code, and files necessary for the action. Creating a single repository for the action allows you to tag, release, and package the code in a single unit. GitHub also uses the action's metadata on your GitHub Marketplace page. Actions are published to GitHub Marketplace immediately and aren't reviewed by GitHub as long as they meet these requirements: The action must be in a public repository. Each repository must contain a single action. The action's metadata file (action.yml or action.yaml) must be in the root directory of the repository. The name in the

Website designer open source free | Designer used in Azure API management developer portal | Open source Drag and drop website builder {tocify} $title={Table of Contents} This is a part-II article continuing this part-I, Here you will see detailed steps for working in Paperbits framework. This Paperbits framework is used in Azure API Management Developer portal, so you can use this article to Customize the Developer portal . For exploring this Paperbits framework and also to contribute someone with the website, I have contributed this Youtube Channel to have an website developed using Paperbits framework for free as an contribution to education. You can find that website here: https://tnpscquickies.com which is completely developed by this framework and hosted in GitHub pages freely. Follow this tutorial for the detailed steps for the same. After following Part-I article clone of the Paperbits repo and running the application locally using npm start command a portal will open li

{tocify} $title={Table of Contents}   a. ABC in WCF: · Address: This lets you know the location of the server. Different bindings support different address types. · Binding: Defines which protocol is being used. · Contract: This defines each method exposed from service. i. Contract: · ServiceContract · OperationContract · DataContract · MessageContract ii. BINDING: · HTTP-based: If we want our service to be accessed across multiple OS or multiple programming architectures, HTTP based bindings are our obvious choice. Let’s see the bindings supported. BasicHttpBinding: It is used in case of web service, offers backward compatibility, the message encoding used is Text/XML, supports WS-basic profile. WsHttpBinding: It gives all functionality which BasicHttpBinding offers, apart from that it offers transaction support, reliable message and WS-Addressing. WSDualHttpBinding: Offers all functionality offered by WsHttpBinding, but the main purpose is to be used with duplex comm

Variable substitution in Azure Devops | File Transformation in azure devops using YAML | Troubleshooting File Transformation in Azure Devops {tocify} $title={Table of Contents} Following this document used file transformation task in Azure Devops to substitute variables in json and xml files: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/file-transform?view=azure-devops # File transform # Replace tokens with variable values in XML or JSON configuration files - task: FileTransform@1  inputs:  #folderPath: ‘$(System.DefaultWorkingDirectory)/**/*.zip’  #enableXmlTransform: # Optional  #xmlTransformationRules: ‘-transform **\*.Release.config -xml **\*.config-transform **\*.$(Environment.Name).config -xml **\*.config’ # Optional  #fileType: # Optional. Options: xml, json  #targetFiles: # Optional When using this you will get following error message: “ changes already present message ”. Got the changes already present message when directly targeting the source f

{tocify} $title={Table of Contents} Adds cross-origin resource sharing (CORS) support to an operation or an API to allow cross-domain calls from browser-based clients. Azure API Management cross domain policies | Microsoft Docs The cors policy adds cross-origin resource sharing (CORS) support to an operation or an API to allow cross-domain calls from browser-based clients. CORS allows a browser and a server to interact and determine whether or not to allow specific cross-origin requests (i.e. XMLHttpRequests calls made from JavaScript on a web page to other domains). This allows for more flexibility than only allowing same-origin requests but is more secure than allowing all cross-origin requests. You need to apply the CORS policy to enable the interactive console in the developer portal. Refer to the developer portal documentation for details. Policy statement XMLCopy <cors allow-credentials="false|true" terminate-unmatched-request="true|false">     &

{tocify} $title={Table of Contents} Tutorial: Create a minimal web API with ASP.NET Core Minimal APIs are architected to create HTTP APIs with minimal dependencies. They are ideal for microservices and apps that want to include only the minimum files, features, and dependencies in ASP.NET Core. This tutorial teaches the basics of building a minimal web API with ASP.NET Core. For a tutorial on creating a web API project based on controllers that contains more features, see Create a web API . Overview This tutorial creates the following API: API   Description   Request body   Response body   GET /   Browser test, "Hello World"   None   Hello World!   GET /todoitems   Get all to-do items   None   Array of to-do items   GET /todoitems/complete   Get completed to-do items   None   Array of to-do items   GET /todoitems/{i