1. Create your Azure Functions App and write down the URL

   1. E.g. https://myazurefunctions.azurewebsites.net (make sure to make it a HTTPS URL)
    

2. Configure your application in Azure Active Directory B2C:

   1. Write down the Application ID
   2. Add a reply URL for your Functions App, adding the suffix /.auth/login/aad/callback. E.g. https://myazurefunctions.azurewebsites.net/.auth/login/aad/callback

     The configuration should look something like this:  

3. Get the Metadata Endpoint URL for your Sign-in policy

   1. If you open the details of your sign-in policy, you'll find it right at the top. E.g.:

       

4. In your Functions App, on the bottom left select "Function app settings" and go to "Configure authentication":

    

5. Turn on authentication and select Azure Active Directory:

    

6. Select the advanced settings and enter the following values:

   1. Client ID: The Application ID which you copied in step 2. a.
   2. Issuer Url: The Metadata Endpoint URL from step 3.
    

7. Save your settings and you're done!

• Was data being ingested by the system?
• Was data being processed by the system?
• Did the rate of ingestion / processing match?
• Were there any unexpected spikes?

• SendInterval: The interval (in seconds) at which the processor sends metrics it has gathered to Application Insights.
• PrefixMetricsWithType: When sending metrics to Application Insights, it will appear under “Custom” (in the Metrics Explorer) or “customMetrics” (in Analytics) and, at first sight, we won’t know which type of telemetry this data came from. (E.g. events called “MyEvent” will appear as if you had sent a MetricTelemetry item called “MyEvent”) If you set PrefixMetricsWithType to true, the TelemetryToMetrics processor will add a prefix, corresponding to the telemetry type, to the data it uploads. (E.g. events called “MyEvent” will appear as “Event.MyEvent”)
• TelemetryTypesToTrack: The types of telemetry you’d like the processor to track, separated by commas. (MetricTelemetry is not supported at this time)

• Check whether the item is a duplicate and has been sent before (by comparing the name/message and – if present – the properties)
  • An item will only be passed on to the next processor (i.e. sent to Application Insights) if it is new (important: only a single copy of each unique telemetry item is sent to Application Insights, so make sure it’s not lost anywhere else – e.g. by client-side sampling or ingestion filtering)
• Independently of the previous step, all items passed to the TelemetryToMetrics processor are counted
• Once every X seconds (determined by the SendInterval parameter), the processor will send the numbers it has collected to Application Insights and reset its counters

I just published this new post on our team blog over here: https://aka.ms/Oz6rgn

Cheers,

Helge Mahrt

Hello everyone,

So you finished your Windows Store app and are eager to get it into the Store – but it failed the Windows App Certification Kit (WACK) test and the results do not provide sufficient information about the reason of the failure. What can you do to get more details?

The first thing to look at are the internal logs of WACK. You can find them in the following folder: C:\Users\<user>\AppData\Local\Microsoft\AppCertKit (Especially interesting are the .txt files. Look out for the name of the test that your app failed.)

If you need to review the content of the xperfTemp.txt file, e.g. for the performance launch test, you may find that it is empty, or that its content does not reflect the output from the test anymore. That is because it is a temporary file and gets overwritten by different tests. In this case, you have two options:

1. You can run exactly the same command that is listed in the (internal) log file, which WACK used to extract the timing information from the .ETL file
2. You can run the test that failed manually, and only that test

To run a single test manually, you can use the following command: Appcert.exe test -apptype windowsstoreapp -packagefullname <full package id> -reportoutputpath c:\temp\testpackage.xml –testid <test id>

You can look up the test id here: C:\Program Files (x86)\Windows Kits\8.0\App Certification Kit\configuration.xml (E.g. the index for the Performance Launch test is 43)

I hope this helps, should your app ever fail a test in WACK and you don’t know why.

Cheers,

Helge Mahrt

My colleague José Ortega and I just published some articles about the new .NET 4.5 keywords await and async, and about the Task Parallel Library (TPL). As they are in Spanish we put them on his blog. If you are interested, please have a look here: https://blogs.msdn.com/b/desarrolloweb/archive/2013/02/22/asincronia-en-net-4-5.aspx

Cheers,

Helge Mahrt

Update: Thanks to Nigel Sampson for correcting my post. :)

As you probably already know, .NET Framework 4.5 introduced two new keywords: async and await. (Look here for information about how to use them.)

If you are adding the possibility to share content of your Windows Store application, you will have to implement the DataTransferManager.DataRequested callback. From the MSDN documentation:

This event is fired when a sharing operation starts—typically when the user taps the Share charm, although it is also fired if your app starts a share operation programmatically.

As with the callbacks on the App class (OnLaunched, OnActivated etc.), you can just convert this function into an asynchronous one. However, take the following sample implementation:

async void App_DataRequested(DataTransferManager sender, DataRequestedEventArgs args) 
{
     DataRequest req = args.Request;
     await Task.Delay(500);
     req.Data.Properties.Title = "Test";
     req.Data.SetText("Hello World!");
     req.GetDeferral().Complete(); 
}

If you use this code, when you are sharing data from your application, you will get a message like one of the following:

“What happened?”, you may ask. Well, there is a trick to making this callback asynchronous.

If we think about the consequences of using async and await, and about the nature of the share operation, we can explain this behavior easily: Once the call to DataRequested returns, it expects the DataRequest to contain the information we want to share. However, if our callback is marked with async and we add a call using await, it will cause the execution flow to leave the function until we are notified by the awaiter that we can continue. DataTransferManager, however, does not know about this and will assume that we have completed the request correctly.

Fortunately, there is a way to tell DataTransferManager to wait for us: using the GetReferral method. Before, we only called it at the end of our callback, to mark the DataRequest as complete. However, if we call it at the beginning we will be able to call asynchronous methods:

async void App_DataRequested(DataTransferManager sender, DataRequestedEventArgs args) 
{     DataRequest req = args.Request;     DataRequestDeferral deferral = req.GetDeferral();     await Task.Delay(500);     req.Data.Properties.Title = "Test";     req.Data.SetText("Hello World!");     deferral.Complete(); 
}

Please note that if the asynchronous operations will take more than 200ms you have to use a DataProviderHandler to prevent the operation from timing out.

I hope this helps you.

Cheers,

Helge Mahrt

We may find ourselves in the situation where we need to access custom properties that have been defined for objects in our Active Directory. However, using the managed class DirectoryEntry we may receive an exception with the error code 0x8000500CL when accessing the custom property the following way:

myDirectoryEntry.Properties["myProperty"]

As the error text indicates, the cause for this issue is the lack of information about how to convert the value of our custom property into a managed object. DirectoryEntry does not offer the possibility to specify this meta information, so how can we access our custom properties?

Luckily there is COM library, ActiveDS, which exposes (amongst others) the following two functions:

• IADsPropertyList::GetPropertyItem
• IADsPropertyList::PutPropertyItem

Once we add a reference to the library to our Visual Studio project, selecting it from the COM tab (it appears as "Active DS Type Library"), we can implement a wrapper like the following:

class PropertyHelper
{
    public static List

We can then access our custom property using the following call:

var sReturnValues = PropertyHelper.GetProperty(entry, "sAttribute", ADSTYPEENUM.ADSTYPE_CASE_IGNORE_STRING);

Implementing a similar wrapper for setting the values of our custom property should be straightforward from here. I hope this helps.

Cheers,

Helge Mahrt