The package manger console in visual studio is capable of far more than just adding and removing nuget packages.
It is in fact a full powershell scripting environment with direct access to the Visual Studio IDE Management Api.
This is not just read-only:
$dte.StatusBar.Text = “Hello”
You can find out about the dte’s properties here:
$dte | get-member | out-gridview
The following is a great way of finding what commands are available to visual studio
$dte.Commands | Out-GridView
And this shows the local environment variables:
gci variable:* | out-gridview
I am wondering if this could be used to add command-line refactoring to visual studio.
Given that the officicial documentation (http://msdn.microsoft.com/en-us/library/azure/ee924680.aspx) I have prepared the following powershell script:
#Enter username and password
Get-AzureOSVersion | where IsActive -eq $true | Out-GridView
This tells you what is actually live, not just planned.
A developers life can consist of new features, change requests and bugs.
The basic approach to bugs is to fix them in priority order.
A more sophisticated technique is to identify that cause of the bug, and introduce a change in the process to prevent it from happening again.
For example, if you are using mvc you may have a convention based set of images.
A simple powershell script can check that the images exist in the correct location from a simple list of pages.
This list could be hardcoded in the tests, but will probably be available from somewhere else in the system.
A similar approach can be taken with logs. It can be assumed at minimum that you are logging errors.
If you only look at the logs when you have a specific error then you are missing out on a lot of data.
Simple analysis of the logs data, such as obtaining counts of each of the types of errors within an hour, will provide massive benefits.
Firstly you will be able to find the most frequent errors – even if the users are not reporting them.
If the error is not a real problem, downgrade it to a warning. If it is a real problem then it should become a priority to resolve.
Secondly it will show you areas where there are missing errors, especially if the users are reporting errors that the logs do not show.
The following shows how to query the 7digital api from powershell.
[xml]$data = (invoke-webrequest -uri http://api.7digital.com/1.2/release/details?releaseid=951886`&country=gb`&oauth_consumer_key=$my7digitalKey | select -ExpandProperty Content)
This provides an in memory object that you can walk the tree.
This is how I investiagate most xml/json feeds.
I am not publishing my key so get your own and set it in your profile:
Found after a crash that exposed api details.