August 2016 - Seite 5 von 70 - Cloud Computing Köln

Breaking changes were introduced in Azure PowerShell v1.4. These breaking changes are present in Azure PowerShell versions 1.4-1.6 and versions 2.0 and later. The following Azure Storage cmdlets were impacted:

Get-AzureRmStorageAccountKey: Accessing keys
New-AzureRmStorageAccountKey: Accessing keys
New-AzureRmStorageAccount: Specifying account type and endpoints
Get-AzureRmStorageAccount: Specifying account type and endpoints
Set-AzureRmStorageAccount: Specifying account type and endpoints

To minimize impact to cmdlets, we are releasing Azure PowerShell v1.7 – a hotfix that addresses all of the breaking changes with the exception of specifying the Endpoint properties for New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount. This means no code change will be required by customers where the hotfix is applicable. This hotfix will not be present in Azure PowerShell versions 2.0 and later. Please plan to update the above cmdlets when you update to Azure PowerShell v2.0.

Below, you’ll find examples for how the above cmdlets work for different versions of Azure PowerShell and the action required:

Accessing keys with Get-AzureRmStorageAccountKey and New-AzureRmStorageAccountKey

V1.3.2 and earlier:

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key1

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key2

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key1

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key2

V1.4-V1.6 and V2.0 and later:

The cmdlet now returns a list of keys, rather than an object with properties for each key.

# Replaces Key1
$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[0].Value

# Replaces Key2
$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[1].Value

# Replaces Key1
$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[0].Value

# Replaces Key2
$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[1].Value

V1.7 (Hotfix):

Both methods work.

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname).Key1

$key = (Get-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname)[0].Value

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).StorageAccountKeys.Key1

$key = (New-AzureRmStorageAccountKey -ResourceGroupName $groupname -Name $accountname -KeyName $keyname).Keys[0].Value

Specifying account type in New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount

V1.3.2 and earlier:

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

V1.4-V1.6 and V2.0 and later:

AccountType field in output of this cmdlet is renamed to Sku.Name.

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

V1.7 (Hotfix):

Both methods work.

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).AccountType

$AccountType = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

$AccountType = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).Sku.Name

Specifying Endpoints in New-AzureRmStorageAccount, Get-AzureRmStorageAccount, and Set-AzureRmStorageAccount

V1.3.2 and earlier:

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

$blobEndpoint = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

$blobEndpoint = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.AbsolutePath

V1.4-V1.6 and V2.0 and later:

Output type for PrimaryEndpoints/Secondary endpoints blob/table/queue/file changed from Uri to String.

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

$blobEndpoint = (New-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

$blobEndpoint = (Set-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob

Note: The ToString() method for these cmdlets will continue to work. For example:

$blobEndpoint = (Get-AzureRmStorageAccount -ResourceGroupName $groupname -Name $accountname).PrimaryEndpoints.Blob.ToString()

V1.7 (Hotfix):

No hotfix was provided for this breaking change. The return value’s endpoints will have to continue to be string, as changing these back to Uri would introduce an additional break.

Next steps

Download Azure PowerShell v1.7 (hotfix).
View all Azure PowerShell releases.
See migration guide for Azure PowerShell 2.0.

Quelle: Azure

31. August 201631. August 2016

da Agency

Exploring HockeyApp data in Application Insights: introducing the Bridge App

In a previous blog, we announced that soon, the data from any app in HockeyApp would be accessible through the Analytics, and Continuous Export features in Application Insights. This functionality is now available to you through the new HockeyApp Bridge App! With it, you will now be able to query raw HockeyApp data and gain insights from it, as well as export it to your own data store for warehousing purposes. In this blog post, we’ll see how to take advantage of this new feature as well as answer common questions about how to instrument your applications going forward.

The HockeyApp Bridge App

HockeyApp is a great tool for instrumenting your mobile and desktop applications. It has powerful facilities for tracking distribution, adoption, crash reporting, feedback, and other data. It also has a collection of dashboards through which this data can be explored. Sometimes, however, you need to access, analyze, and visualize your data in ways other than are presently exposed in HockeyApp. This is where the new HockeyApp Bridge application type in Application Insights comes in! Your HockeyApp data will be available to you in its raw form to query and analyze using Analytics and export to your own data store via Continuous Export!

Creating a HockeyApp Bridge App in Application Insights

The HockeyApp Bridge App is the core feature that will enable you to access your HockeyApp data in Application Insights through the Analytics and Continuous Export features. Data collected by HockeyApp after the creation of the HockeyApp Bridge App will be accessible from the aforementioned features. All you need to set up a Bridge App is to create a new Application Insights resource with the “HockeyApp Bridge Application” app type. You will need to provide an API key that you can obtain from your HockeyApp settings, and soon after creating it, the Analytics and Continuous Export features will be accessible to you against your HockeyApp data.

Please see our documentation for a detailed walkthrough of setting up a HockeyApp Bridge App, as well as to learn more about the various ways to access your data.

Using the HockeyApp Bridge App

Let’s look at a simple practical example of using the HockeyApp Bridge App. In this case, we’ll be looking at telemetry generated by an iOS app that was created for the Xamarin Evolve 2016 conference (App Store link). This app was instrumented using the iOS HockeySDKs.

First, let’s create a HockeyApp Bridge App per the instructions above:

Now, let’s press the Analytics button to open a new Application Insights Analytics window. Once loaded, let’s open a new tab, type in the following query, and press “go”:

customEvents
| summarize country_Count = count() by client_CountryOrRegion
| order by country_Count
| render piechart

And just like that, we now have a pie chart of the country of origin of our users!

This is a very simple scenario, but building on it with the extensive querying capabilities in Analytics, you can begin to really investigate and gain insights about your HockeyApp applications. In parallel, you can configure Continuous Export to store this data in your warehouse, to later join with other data sources. All of these possibilities and more are now possible with the new HockeyApp Bridge App in Application Insights!

FAQs

Over the last several blog posts around instrumenting mobile and desktop apps, we’ve received some common questions:

Can you summarize how to instrument my applications going forward?

Please refer to the simple flowchart below to determine how to instrument your applications and access your data going forward (click for a large version):

Should I use Application Insights or HockeyApp to instrument my mobile and desktop applications?

You should use HockeyApp to instrument mobile and desktop applications going forward. HockeyApp provides great capabilities for these types of apps including distribution, adoption, crash reporting, and feedback tracking.

What if I need more information than the dashboards in HockeyApp provide?

Should you need to access or analyze the raw data from HockeyApp beyond the pre-made dashboards available there, you should create a HockeyApp Bridge App as described in this blog post. You can then further interact with your data through the Analytics and Continuous Export features in Application Insights.

What SDKs should I use for my mobile and desktop applications?

While the Application Insights SDKs for mobile and desktop applications will continue working for the foreseeable future, you should use the HockeyApp SDKs going forward. More details about this are available in our previous blog post.

How do I track handled exceptions in my mobile and desktop applications?

Tracking of handled exceptions is not natively available for mobile and desktop apps. It is however easy to implement via the Custom Event mechanism. To do this, a helper method can be created as described in the HockeyApp KB repository.

Next steps

Instrumenting your mobile or desktop application is easy – use HockeyApp and the HockeySDKs, and create a HockeyApp Bridge App in Application Insights if you need to analyze or access your raw data. Continue using Application Insights and the Application Insights SDKs for all other application types.

As always, please share your ideas for new or improved features on the Application Insights UserVoice page, and for any questions visit the Application Insights Forum or HockeyApp Support!
Quelle: Azure