Bing Translator Plugin for WordPress Enables Webmasters and Developers to Localize Site Content

Microsoft Open Technologies, Inc. has released a new Bing Translator plugin that lets you apply the power of Bing Translator to any WordPress site running version 3.8 or later.

Using the plugin, visitors can translate a site into any of the 40+ supported languages in one click without leaving the page once this light-weight, cross-browser plugin is installed. This plugin also provides options for a setting a color scheme, as well as an option to allow visitors to suggest translations.

The Bing Translator plugin should be installed from within the WordPress Dashboard by clicking on Plugins >Add New and search for “Bing Translator” and works on any WordPress site. A site developer can also manually install the plugin by downloading it from WordPress.org, then adding the “bing-translator” folder in the “/wp-content/plugins/” directory.

Using Bing Translator Plugin for WordPress Video

More Links to Get Started

Congratulations to Microsoft Open Technologies, Inc team for their great work on the Bing Translator Plugin for WordPress! 

Using Office 365 APIs in your MVC and Windows 8.1 Applications – Part II

In last month’s blog post, we announced the Office 365 API Tools – Preview add-in for Visual Studio 2013. By using Office 365 APIs, developers can access users’ data in the Office 365 cloud, e.g., reading calendar information, storing documents, or sending emails on behalf of users. The Office 365 APIs are an open platform that is available across a variety of languages and technologies. If you’re developing Model-View-Controller (MVC) web projects or Windows 8.1 applications, our Office 365 API Tools for Visual Studio will make it that much easier to add Office 365 APIs to your solution.

The previous post focused on getting started with the tooling and the Office 365 APIs – going through the registration piece and exploring the sample code. This post continues from where the previous post left off, going from using the generated sample code to authoring your own. If you haven’t already done so, I highly recommend reading the previous post before continuing with this one.

Note A couple of weeks ago (April 7, 2014), we released an updated (1.1) version of the Office 365 API Tools – Preview, which offers some reliability improvements to the tool, along with some slightly modified sample code (particularly in relation to SharePoint). Today’s blog post assumes you are using the latest version of the tools and the accompanying samples.

Recap of the Project Structure

In last month’s blog post, we took a look at the files that are added by the Office 365 API Tooling. If you have not already, I would encourage you to read the “Exploring the project structure” section of that post – including the diagrams that show which files are added to the MVC Web Application and the Windows 8.1 app. In a nutshell, after registering an app with the Azure Active Directory, the Office 365 API Tools make the following modifications to a project:

  • Add NuGet packages for Active Directory Authentication Library and Json.NET.
  • Add a set of common helper files (files whose names start with “Office365*,” such as “Office365ServiceInfo”) that are common across different services.
  • Add a set of service-specific sample files (for example, ExchangeSampleController and its accompanying View folder for MVC, or ExchangeSamplePage.xaml and its accompanying code-behind for Windows 8.1).
  • Modify Web.config or App.xaml to include the Client ID (and, in the case of web apps, the Password) for the app.

The NuGet additions and the Web.config/App.xaml modifications are fairly straightforward, so in terms of new files added to the project, we’re left with the helper files and the service-specific sample files. The helper files are designed to be fairly transparent to the developer, as they encapsulate functionality that you shouldn’t need to worry about. The one exception is error-handling, where you may want to customize the experience by customizing the UI or writing the errors to a log or database. We’ve left a TODO flag in the Office365Helper and Office365CommonController files to make it clear where such error-handling logic should be implemented. For the rest of the helper-class implementations, you can treat those files as library files and generally avoid peeking into them, except to satisfy your academic curiosity.

Instead of exploring the underlying plumbing of the helper files, this blog post will focus on showing you how to use the files to accomplish your business needs.

A note on the differences between MVC Web Apps and Windows 8.1 apps

No doubt, every developer has faced the frustration of learning to do something one way – and then needing to re-learn a completely different approach for a similar scenario.

When designing our helper classes, we worked hard to ensure that much of the individual differences between platforms and services are abstracted away. Using our helper classes, accessing Exchange from a Windows 8.1 app feels no different than accessing SharePoint from an MVC web app. For example, authentication on Windows 8.1 apps has different caching mechanisms than web applications, but our helper classes handle it transparently for the developer in either case. Likewise, accessing OneDrive for Business in SharePoint requires an extra discovery step, whereas accessing Exchange does not; but again, this is not be something that a developer needs to remember. By using our helper classes, the code that you author will be similar both in spirit and structure, no matter which project type and which service you choose to target.

So, what does the sample code look like when the individual differences are abstracted away by helper classes? Let us take a function that retrieves calendar events from Exchange and take a look, step by step.

Performing a GET request

Step 1: Obtain information for communicating with the service

To use the helper functionality, first you need to create an object to represent the service. The object type is one of the helper classes, Office365ServiceInfo. This class encapsulates information about a service’s API endpoint, resource ID, access token, error handling, and more (generally speaking, much of this information should be transparent for your code). All you need to do is obtain an instance of the service, and then pass it around to other helper functions.

To construct an Office365ServiceInfo instance, the Office365ServiceInfo file offers a number of static methods that construct an instance of a particular service type:

MVC Web App

Office365ServiceInfo serviceInfo =
    Office365ServiceInfo.GetExchangeServiceInfo();

if (!serviceInfo.HasValidAccessToken)

{

    return Redirect(serviceInfo.GetAuthorizationUrl(Request.Url));

}

Windows 8.1

Office365ServiceInfo serviceInfo = await
   
Office365ServiceInfo.GetExchangeServiceInfoAsync();

if (!serviceInfo.HasValidAccessToken)

{

    return null;

}

By necessity, this preamble to get the Office365ServiceInfo object is somewhat different between the two project types – but it does stay identical between services (merely substituting GetExchangeServiceInfoAsync for GetOneDriveServiceInfoAsync, GetActiveDirectoryServiceInfoAsync, etc).

As a side note, the reason for the difference is that a web project must redirect to a login page and then back to itself in order to show a login UI, whereas a Windows 8.1 project is able to display the login screen as an overlay dialog. Thus, whereas the MVC code needs to redirect to the authorization URL if no access token is retrieved, the Windows 8.1 code does not. The difference also accounts for the need to “await” the dialog in Windows 8.1 (though certain services, like GetOneDriveServiceInfoAsync, still need to be async even in the case of an MVC Web App, as they first require a call to a Discovery service).

Step 2: Create a URL for retrieving the data

The next step is to construct a URL to call into the service. This code is completely the same across project types (though it is different for different service types).

How do you know which URL to use for the service, and which query parameters to pass in? In the MSDN Office 365 APIs Preview documentation, choose an appropriate section for your service type, such as the article on Using the Mail, Calendar and Contact REST APIs. For this example, the “Work with calendar items” section describes the format of the query to retrieve calendar data and even suggests a filter that you can apply, which is part of the standard ODATA syntax.

GET https://outlook.office365.com/ews/odata/Me/Calendar/
Events?$filter=Start le 2014-02-14T05:00:00Z and End ge 
2014-02-10T05:00:00Z HTTP/1.1
Accept: application/json

Armed with the example above, we can create our own query. In the case of the sample code that the tool produces, this query will retrieve the top 10 upcoming calendar events (and minimize data sent over the wire by doing only a select on a few fields):

Both MVC and Windows 8.1

string[] queryParameters =

{

    String.Format(CultureInfo.InvariantCulture,

         “$filter=End ge {0}Z”, DateTime.UtcNow.ToString(“s”)),

    “$top=10″,

    “$select=Subject,Start,End”

};

string requestUrl = String.Format(CultureInfo.InvariantCulture,

    “{0}/Me/Calendar/Events?{1}”,

    serviceInfo.ApiEndpoint,

    String.Join(“&”, queryParameters));

Note that to reduce error, the code above substitutes serviceInfo.ApiEndpoint into the beginning of the query, so that you don’t have to type out the same API endpoint (“https://outlook.office365.com/ews/odata”) every time. In addition to saving on typing, this pattern also makes calling different services consistent, whether the API endpoint is static (as it is for Exchange and Active Directory Graph) or dynamically discovered (as in the case of OneDrive for Business).

Step 3: Prepare the HTTP request

Now that the URL for obtaining the data is prepared, the next step is to create HttpClient and HttpRequestMessage objects. While the sample code creates a new HttpClient object every time, you may instead choose to keep it around for easy reuse. The code is the same across project types and fairly similar across service types as well. Differences worth noting are things like substituting odata=verbose versus odata=minimalmetadata for the Accept headers, depending on the service type. For such things, the MSDN documentation gives guidance on which Accept or ContentType headers the REST calls expect.

For the case of doing a simple Get on Exchange, the following will suffice:

Both MVC and Windows 8.1

using (HttpClient client = new HttpClient())

{

    Func<HttpRequestMessage> requestCreator = () =>

    {

        HttpRequestMessage request = new HttpRequestMessage(

            HttpMethod.Get, requestUrl);

        request.Headers.Add(“Accept”, “application/json;odata=minimalmetadata”);

        return request;

    };

 

    <Upcoming code here>

}

You may wonder, why do we create a lambda (e.g., a function that returns an HttpRequestMessage) rather than just creating the appropriate HttpRequestMessage object? The reason is that a request could fail because of an expired access token, in which case a new access token would need to be created and a new request dispatched to the service. Because an HttpRequestMessage object cannot be used more than once, the procedure for creating the request is captured as a lambda.

The whole business of retrying a request sounds tricky, but fortunately our helper code handles it for you. All you need to do is use the helper, and then you can just read the data. The only difference between the MVC code and the Windows 8.1 code is the name of the helper: Office365Helper vs. Office365CommonController.

MVC Web App

using (HttpResponseMessage response = await Office365Helper.

    SendRequestAsync(serviceInfo, client, requestCreator))

{

    <Upcoming code here>

}

Windows 8.1

using (HttpResponseMessage response = await Office365CommonController.

    SendRequestAsync(serviceInfo, client, requestCreator))

{

    <Upcoming code here>

}

Step 4: Read the response and de-serialize the data

With the response received, it’s time to read the response object; and, in case of failure, to use the common error-handling function to parse out the human-readable error from the response and display it to the user. As mentioned before, the error-handling implementation has a basic default behavior, but you can customize it to suit your needs. The code is the same across service types, and only mildly different between platforms (redirecting to a special error view in the case of MVC, versus displaying an error dialog in the case of Windows 8.1)

MVC Web App

string responseString = await response.Content.ReadAsStringAsync();

if (!response.IsSuccessStatusCode)

{

    return Office365CommonController.ShowErrorMessage(

        serviceInfo, responseString);

}

Windows 8.1

string responseString = await response.Content.ReadAsStringAsync();

if (!response.IsSuccessStatusCode)

{

    await Office365Helper.ShowErrorMessageAsync(

        serviceInfo, responseString);

    return null;

}

Finally, if the response was successful, you typically want to perform some action based on the response. For GET operations such as retrieving mail, calendar, or files, this may involve de-serializing the data. For POST operations, you may still want to de-serialize the data, or you might be content to know that the operation succeeded.

If you do need to de-serialize the data, using a library such as Json.NET (which is added automatically to the project when you add an Office 365 service) makes it possible to work with the returned data as if it is a .NET object. First, however, you need to define the shape of the data that you expect to receive over the wire. The same MSDN documentation as before will show the shape of the returned data. Thus, continuing with the previous example, the section on Work with calendar items defines not only the query format, but also the entirety of the object that you will get back.

Trimming for brevity, the MSDN documentation shows something like this:

{
  "@odata.context": "https://outlook.office365.com/EWS/OData/$metadata#Me/
Calendar/Events",
"value": [
    {
      "@odata.id": "https://outlook.office365.com/EWS/OData/Users
('sadie@contoso.com')/Events('AAMkAGI3...')",
      ...
      "Subject": "Lunch",
      ...
      "Start": "2014-02-13T20:30:00Z",
      "End": "2014-02-13T21:00:00Z",
      ...
    },
    {
      "@odata.id": "https://outlook.office365.com/EWS/OData/Users
('sadie@contoso.com')/Events('AAMkAGI3...')",
      ...
      "Subject": "Test new REST API",
      ...
      "Start": "2014-02-13T16:00:00Z",
      "End": "2014-02-13T17:00:00Z",
    }
  ]
}

Tip While MSDN can be great for initial familiarization with the data step, sometimes you want to experiment with the data against live data in real-time. A common technique is to dispatch the request and then watch the response using a debugging proxy such as Fiddler. In fact, if you run the sample code, you can use Fiddler to intercept the request (Access Token and all) – and then use the Composer tab in Fiddler to re-issue the request with minor modifications.

In any case, once you know the JSON shape, you can create a plain C# class with properties that match the names of the JSON fields. In the case of the sample files, this class is defined towards the top of the files. Alternatively, you could also extract it into a separate file, for example, to reuse across your project.

Both MVC and Windows 8.1

public class CalendarEvent

{

    public string Subject { get; set; }

    public DateTime Start { get; set; }

    public DateTime End { get; set; }

}

With the data structure defined, all that remains is to de-serialize it. The exact call can differ slightly between service types, depending on how nested the JSON structure is. For Exchange, it looks like this:

Both MVC and Windows 8.1

var events = JObject.Parse(responseString)["value"].

    ToObject<SampleModel.Exchange.CalendarEvent[]>();

Also depending on the service, you may need to do additional post-processing on the results. For example, Exchange does not yet support ordering events on the server, so the sample sorts them locally:

Both MVC and Windows 8.1

events = events.OrderBy(e => e.Start).ToArray();

With that, you have successfully accessed data from the Office 365 cloud. From here, the samples display the data in a basic MVC view or a Windows 8.1 page – but for authoring your own code, the sky’s the limit.

Performing a POST request

The sample code produced by the Office 365 API Tools shows only GET requests. Now that you’ve seen how a GET request works, how do you go about authoring a POST request? The answer: Follow the exact same pattern!

To demonstrate that the patterns are in fact the same, I will round off this article with an example of issuing a POST request, such as adding a new contact to Exchange.

As before, we start with looking at the MSDN documentation to see the prototypical way to create a contact. In the Create a contact section, we see:

To create a contact, send a POST request to the Contacts property of the contacts folder with a JSON representation of the new contact in the payload. The following example creates a new contact in the default Contacts folder.

 

POST https://outlook.office365.com/ews/odata/Me/Contacts HTTP/1.1

Accept: application/json

Content-Type: application/json;odata.metadata=full

Expect: 100-continue

 

{

  “@odata.type”: “#Microsoft.Exchange.Services.OData.Model.Contact”,

  “GivenName”: “Mara”,

  “Surname”: “Whitley”,

  “EmailAddress1″: “mara@fabrikam.com”

}

First, ensure you have appropriate permissions by going back to the Services Manager dialog. For this example, select Exchange, then Configure, and then Have full access to the users’ contacts.

With this done – and having added an entry point (such as a method off of a button click, with appropriate error handling) for invoking the action – you would follow the same steps as before. In broad strokes:

  1. Obtain information for communicating with the services.
  2. Create a URL corresponding to the ODATA request – and, in the case of a POST request, prepare a data structure for transmitting the data.
  3. Prepare the HTTP request.
  4. Send the request.
  5. Read the response and handle errors.

The biggest difference is in step #3, when preparing the HttpRequestMessage object:

  • The request must be a POST rather than a GET.
  • The Accept header may need to be adjusted, depending on what the documentation prescribes.
  • A Content header must be added.
  • The request content must be set to the serialized JSON.

Here is the code in its entirety, for a Windows 8.1 app:

private class Contact

{

    [JsonProperty("@odata.type")]

    public string EntityType { get; set; }

    public string GivenName { get; set; }

    public string Surname { get; set; }

    public string EmailAddress1 { get; set; }

}

 

private async Task AddContact() {

    // Obtain information for communicating with the service:

    Office365ServiceInfo serviceInfo = await

       Office365ServiceInfo.GetExchangeServiceInfoAsync();

    if (!serviceInfo.HasValidAccessToken)

    {

        return;

    }

 

    // Create the data structure and the URL corresponding to the ODATA request

    Contact contact = new Contact()

    {

        EntityType = “#Microsoft.Exchange.Services.OData.Model.Contact”,

        GivenName = “Mara”,

        Surname = “Whitley”,

        EmailAddress1 = “mara@gabrikam.com”

    };

    string requestUrl = String.Format(CultureInfo.InvariantCulture,

        “{0}/Me/Contacts”,

        serviceInfo.ApiEndpoint);

 

    // Prepare the HTTP request:

    using (HttpClient client = new HttpClient())

    {

        Func<HttpRequestMessage> requestCreator = () =>

        {

            HttpRequestMessage request = new HttpRequestMessage(

                HttpMethod.Post, requestUrl);

            request.Headers.Add(“Accept”, “application/json;odata.metadata=full”);

            request.Content = new StringContent(

                JsonConvert.SerializeObject(contact));

            request.Content.Headers.ContentType =

                new MediaTypeHeaderValue(“application/json”);

            return request;

        };

 

        // Send the request using a helper method, which will add an authorization header to the request,

        // and automatically retry with a new token if the existing one has expired.

        using (HttpResponseMessage response = await Office365Helper.SendRequestAsync(

            serviceInfo, client, requestCreator))

        {

            // Read the response and deserialize the data:

            string responseString = await response.Content.ReadAsStringAsync();

            if (!response.IsSuccessStatusCode)

            {

                await Office365Helper.ShowErrorMessageAsync(serviceInfo, responseString);

                return;

            }

 

            await new MessageDialog(“Contact added successfully!”, “Success!”).ShowAsync();

        }

    }

}

For an MVC project, the code would be largely the same. For real-world applications, though, the one important difference between Windows 8.1 and MVC code is the initial authentication piece. Whereas a Windows 8.1 app will display a dialog box that prompts the user to enter credentials – and which the code can just “await” – an MVC web project must do a redirect to an authentication provider (e.g., redirect to https://login.windows.net/) before getting redirected back to the MVC controller. As such, if the action is state-full (e.g., you’re adding a contact based on information submitted by the user), you will need to ensure that this information is persisted when the login page returns. You can do this in a variety of ways – for example, storing a cookie, encoding the information as a query parameter on the URL passed to serviceInfo.GetAuthorizationUrl, or ensuring that even a blank form requires the user to log in first.

I hope this blog post has helped you to get started with authoring your own Office 365 APIs code. To learn more, I invite you to read the MSDN documentation on Office 365 APIs, and – if you’ve haven’t already – to watch The Office 365 API Tools for Visual Studio video on Channel 9 that touches upon many of the points in this post.

image

Video: Office 365 API Tools for Visual Studio

- Michael Zlatkovsky, Program Manager on the Office Developer Tools team at Microsoft

Smart Watch: I give up, switching to making a device using the Raspberry Pi

Yep.  I give up.  So I am ordering a Raspberry Pi from Amazon with some extra stuff, like an LCD screen and so forth. Then I will make my own time display or something else.  But the Gadgeteer, Pebble Watch, MetaWatch, Sony Watch and TI Watch, all generally look horrible and the start up for me will take too long. Besides I can just copy Steven’s stuff.  Don’t tell him though….(read more)

BUSINESS INTELLIGENCE – April 2014 Readiness Update

SQL Server 2014 available now + April 15 live streaming keynotes
Microsoft SQL Server 2014 is generally available as of April 1. Learn more about the latest offering here. And mark your calendar for April 15 to watch the Accelerate Your Insights keynotes—featuring CEO Satya Nadella, COO Kevin Turner, and CVP of Data Platform Quentin Clark—live from San Francisco, California. Hear about data platform strategy including how you can drive your business in real-time, from apps to insights, using all of your data.

Exam updates

Microsoft Certified Solutions Expert (MCSE) SQL exams are scheduled to be updated on April 24, 2014 to cover solutions based on both Microsoft SQL Server 2012 and 2014 products. The exam numbers will not change, but the product version (2012) will be removed from the titles of the exams. Review details on the exam updates now—see the Skills Measured section of each Exam Detail web page below, and review the “content covering SQL Server 2014″ section:

· Exam 70-466: Implementing a Data Warehouse with SQL Server 2012

· Exam 70-467: Designing Business Intelligence Solutions with Microsoft SQL Server 2012

Do you know about Practice Accelerator?

Practice Accelerator sessions, designed for technical consultants and architects, enable you and your organization to increase skills in a specific solution or services area. Learn more about Practice Accelerator through this fun, informative, short video.

April 30:  Microsoft Corporate BI and SAP BI Integration Jump Start

How do you successfully deliver business intelligence (BI) to business users in your organization? With so much data and so many users, BI can be tough to navigate. To see how other teams have done it, join this no-cost Jump Start training session and walk through a set of real-world case studies with Sanjay Soni and a team of experts.

Issues with Application Insights Usage – Resolved – 4/23

Update: 4/23/2014 23:55 UTC

Over the last day, the Application Insights Usage data collection endpoints have had intermittent problems.  As a result, different Application Insights Usage customers may see a drop in activity from their users in different regions depending on the time and where the user is physically located.  Affected regions and times:

  • Between 16:30 and 18:15 UTC (9:30 and 11:15 AM PDT) on Apr 22: Europe Usage intermittent impact
  • Between 1:55 and 4:50 AM UTC on Apr 23 (6:55 and 9:50 PM PDT on Apr 22): Global intermittent impact
  • Between 5:30 and 5:55 AM UTC on Apr 23 (10:30 and 10:55 PM PDT on Apr 22): US West/Asia intermittent impact

Please accept our apologies for this inconvenience.

Thanks,

-Application Insights Service Delivery Team

Using the IntelliTrace Events window with a log collected from MMA Standalone

The Microsoft Monitoring Agent allows you to collect reliability performance data and exception data for web applications. You can use IntelliTrace to review this data, or debug this data to get more useful information. In this post I am using MMA Standalone, as opposed to MMA connected to AppInsights or System Center.

One of my colleagues deployed FabrikamFiber site to her local IIS and monitored it with MMA standalone. FabrikamFiber was designed to contain bugs and surprises. Let’s see what we can find from the collected log (attached to the blog).

Open the FabrikamFiber log file in Visual Studio and you’ll see a summary page as following. It’s complaining that some MVC pages have performance alerts and there are also quite a few exceptions. Note that all the exceptions and performance violations are nicely grouped:

Debugging an Exception Data

You can select an item in Exception Data then click the “Debug Newest Exception in Group” button to start debugging this exception. Once the debugger goes into break mode, you are immediately presented in the IntelliTrace window of all the IntelliTrace events collected by the MMA standalone sorted in time order. The expanded event corresponds to the exception that you just started debugging from.

The way Microsoft Monitoring Agent works is it monitors a web application in the background and collects data when undesirable behavior occurs, such as problematic exceptions or poor performance. The collected data includes information about various framework components such as System.XML, ADO.NET and ASP.NET. This information isn’t visible on the IntelliTrace summary page but is available in the IntelliTrace window when debugging:

Each event in the list contains an event type and a short description. Currently the following types are supported by Microsoft Monitoring Agent:

  • Ado.NET
  • ASP.NET
  • Azure
  • BizTalk
  • Gesture
  • Reporting Services
  • Service Model
  • SharePoint
  • Performance
  • Workflow
  • Xml

You can select an event to expand it and see additional information. An expanded event will contain a long description, a time stamp, as well as links to other debugger windows like the Locals window and the Call Stack window. In this case, the Locals window and the Call stack window will also be populated with data from the current event.

For ADO.NET event, you can even click the link and open the event detail in SQL editor, the same as Jump to SQL from performance detail view:

How the IntelliTrace Events Window Helps Troubleshooting

Knowing what’s in the IntelliTrace window, now let’s see how to use this information to troubleshoot the 3 groups of exceptions on the summary page.

Let’s start from debugging the exception that happened most (58 occurrences as we saw on the Summary page):

The expanded event says “The controller for path ‘/FabrikamFiber.Web/Content/fonts/segoewp-webfont.ttf’ was not found or does not implement IController.” This is a bit confusing because there is no controller created for font files in FabrikamFiber. However if you are familiar with this ASP MVC error message, you’ll realize that what the message really saying is it can’t find the segoewp-webfont.ttf font file. After comparing the original code and published web site, it turned out that the font files were not published along with other binaries from my source code folder to the local IIS folder, and the web page failed to access the font files at runtime. I have to say that even though the error message isn’t extremely intuitive, it’s actually really helpful that MMA standalone reported this issue. Because the backup font is so similar to the missing one and it’ll take me much longer time to notice that the font is off on published site without this message.

Now let’s debug the 2nd exception (5 occurrences) which is System.NullReferenceException:

After digging a little bit, I noticed that the two events before this exception event both happened at same time (6:05 PM) as the exception event, and they point to Report.Employees page; which means it’s very likely the NullReferenceException happened when generating the Employees page.

Actually when the exception event is selected, the Call stack window and Locals window also clearly tell us that “EmployeeReportViewModel.GetCustomerSummary” function’s “customer” parameter is null. With this information, I was able to fix the issue quickly later when I got access to the source code.

And the understanding of the last issue is similar to the 2nd one, accessing ServiceTickets.Details page caused an ArgumentException.

I’m really glad that with the help of MMA Standalone log, I can easily find and fix these issues on a published site without live debugging the site.

Debugging a Performance Violation

For performance violation data, you can also open the performance detail view and start debugging by clicking the “Debug This Call” link:

Event better, note that when started from a performance violation item, you’ll see a much shorter list of events because it is filtered to the events related to the current performance violation. You can read more on another blog post how to troubleshoot from a performance alert.

In Closing

We hope you find these features in the Visual Studio IntelliTrace experience for MMA Standalone-sourced IntelliTrace files useful. For feedback on this or any IntelliTrace feature, please ask us at our diagnostics MSDN forum.

Issues with Application Insights – Resolved – 4/23

Final update: 4/23/2014 22:58 UTC

Application Insights GSM service is restored in Moscow location. Customers might see failed web test results coming from Moscow location during the impact window (21:19 - 22:12 UTC). 

———-

Initial Update: 4/23/2014 22:21 UTC

Application Insight GSM service is not available in Moscow location at this moment. Customer will not see GSM data from affected location. Our DevOps team is working to root cause the issue. We will provide an updated status within 2 hours. 

Please accept our apologies for this inconvenience.

Thanks,

-Application Insights Service Delivery Team