As you are aware, we can use ConvertTo-Json cmdlet to convert an object to Json output format using PowerShell. However, there is something you need to be aware of while using conversion. By default, it does not work with very large objects (containing of multiple sub-objects) and converts them properly. This is because of the fact that the Depth parameter for ConvertTo-Json has a default value of 2. Let’s understand what this means.
For our example, we’ll create a JSON file with below details first and save it on to your local machine as new-json.json
Recently, if you have been trying to deploy Azure Resource Group template using Visual Studio, you might see below error:
[ERROR]Add-AzureRmAccount: A parameter cannot be found that matches parameter name
[ERROR]'EnvironmentName'.[ERROR]At line:1 char:2379[ERROR]+... xmg' -AccountId 'firstname.lastname@example.org' -EnvironmentName 'AzureC...[ERROR]+~~~~~~~~~~~~~~~~[ERROR]+CategoryInfo:InvalidArgument:(:)[Add-AzureRmAccount],Param[ERROR] eterBindingException
[ERROR]+FullyQualifiedErrorId:NamedParameterNotFound,Microsoft.Azure.Commands.[ERROR]Profile.AddAzureRMAccountCommand[ERROR][ERROR]RunLogin-AzureRmAccount to login.
As discussed in one of the previous blog posts, we can use PowerShell to help create persistent logins. Now consider scenario, where you have access to multiple azure subscriptions. Off course, you can download and save AzureRM profile for each one of the them. However, there are two major issues:
AzureRM profile downloaded is associated with a token by default and it expires in a few days.
If you have too many subscriptions, it can be tiresome to first select subscription and then save the profile.
REST APIs are getting more and more common these days. It is important to learn them to be successful in the DevOps field. In previous blog post, we have used Invoke-WebRequest cmdlet to access the data available to an anonymous user.
PowerShell makes working with rest API’s easy. Starting with PowerShell v3, the cmdlets Invoke-RestMethod and Invoke-WebRequest were introduced. The difference between the two is quite small, Invoke-RestMethod simply being a slightly more convenient wrapper around Invoke-WebRequest as it only returns the content, omitting the headers.Read More »
In last post, we have described on what JSON is and how it is becoming increasingly important in the DevOps phenomenon. So its necessarily not only to understand the format, but also involve in our tools of choices. Microsoft has introduced couple of cmdlets in PowerShell to make use of JSON format namely ConvertFrom-JSON and ConvertTo-JSON.
Again, we can get the same by making use of Get-Command cmdlet:
In this day and age of continuous delivery and integration, the focus is continuously moving away from software interface and on to APIs. One of the prime objectives of DevOps is to achieve end to end automation of delivery. For this, the various kinds of softwares which are used in the process of delivery, need to exchange data. This is where APIs come in handy. Using APIs, there is no manual intervention needed, and all the data can be exchanged easily.
APIs, more specifically REST APIs, return data when queried. The earlier format of choice used to be XML, then it turned over to XAML but now the focus is on JSON due to its easiness. Read More »
This post is continuation of series of PowerShell development using Visual Studio code. In this blog post, we’ll see how to customize Visual Studio code for PowerShell development. One of the great features of Visual Studio Code is the extent to which you can customize it. Each extension usually provides customizable settings, too. To begin to customize Visual Studio Code, select the Command Palette from the View menu, or press Ctrl+Shift+P (Cmd + P on the Mac), type user, and then select Preferences: Open User Settings. This will open two editor windows as shown in the following screenshot: Read More »
It has been a long time since the PowerShell integrated scripting environment (ISE) shipped with Windows PowerShell 2.0 in 2009. Since then .NET has become open source and cross-platform in form of .NET Core. Since PowerShell is built on top of .NET, it was an important pre-requisite before making PowerShell cross platform. Also, PowerShell has become cross-platform as of today. It is also open-source like .NET core. You can find the same at GitHub as well. In fact, we did discuss the open-source PowerShell namely 6.0 installation in few of the earlier posts as well. Read More »