Damir Dobric Posts : Windows

How to find out Callback URI of the Windows 10 App?

Damir Dobric — Mon, 14 Aug 2017 05:20:00 GMT

Usually, when implementing AAD authentication in application, according to OAuth protocol, you will have to provide so called Callback-URI. This is the URL of the endpoint capable of receiving redirected request from authority. Because the specification as originally written for web applications, this kind of URL is not natural for native apps.

Depending on type of operative system or even better, depending on client library, which you use, this URL might look different. In a case of UWP (Universal Windows Application), the URL can be extracte as follows:

string URI = string.Format("ms-appx-web://Microsoft.AAD.BrokerPlugIn/{0}", WebAuthenticationBroker.GetCurrentApplicationCallbackUri().Host.ToUpper());

As a result you will get something like this:

ms-appx-web://Microsoft.AAD.BrokerPlugIn/S-1-XX-2-00000000-11111-22222-4444-2290055178-222222-1111111

This URL is what you have to set in application blade in Azure AAD portal.

DesktopAppConverter error : qualified file name must be less than 260

Damir Dobric — Sat, 22 Jul 2017 12:53:00 GMT

When working with Desktop Converter, you might get following error:

C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_x64__8wekyb3d8bbwe\DesktopAppConverter.ps1 : The
specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and
the directory name must be less than 248 characters.
At line:1 char:1
+ &'C:\Program Files\WindowsApps\Microsoft.DesktopAppConverter_2.0.2.0_ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,DesktopAppConverter.ps1

This error has nothing to do with the length f any of your application files. The problem is destination argument of following command:

> DesktopAppConverter.exe -Installer C:\Temp\NodejsApp\NodejsApp -AppExecutable node.exe -Destinat
ion C:\Temp\NodejsApp\NodejsApp\packages -PackageName "MyNodeApp" -Publisher "CN=MyPublisher" -Version 0.0.0.1

This command creates the package from application in path ‘C:\Temp\NodejsApp\NodejsApp ’ and will try to store it to path C:\Temp\NodejsApp\NodejsApp\packages .

Because creating process will read specified path, but in the same time will create packages under the reading path, it will recursively grow until it crashes.

Solution is very easy. You should create a package out of application root:

DesktopAppConverter.exe -Installer C:\Temp\NodejsApp\NodejsApp -AppExecutable node.exe -Destinat
ion C:\Temp\NodejsApp\packages -PackageName "MyNodeApp" -Publisher "CN=MyPublisher" -Version 0.0.0.1

How to enable Windows 10 Start Button?

Damir Dobric — Sun, 31 Jul 2016 19:27:04 GMT

Sometimes on Windows 10 start menu might be disabled. One of solutions is to switch of the option “Use Start full screen” option.

Unfortunately, it is not possible to enter these settings usual way. If you want to change personalization settings while disabled Start-Menu on Windows 10, try following. Start Task Manager (Ctrl+Shift+ESC) and then run new task:

As next start Command Prompt:

Finally run the shell extension called ‘Personalization’:

C:\WINDOWS\system32>start ms-settings:personalization

Build error “error APPX1706:”

Damir Dobric — Fri, 24 Jun 2016 07:38:41 GMT

In a time of transition form .NET framework to .NET core, you might run into issues, which you never ha before.
This is the price for open source.

For example, look at following error:

error APPX1706: The .winmd file 'Windows.Foundation.UniversalApiContract.winmd' contains type 'Windows.Networking.NetworkOperators.MobileBroadbandDeviceServiceCommandResult' outside its root namespace 'Windows.Foundation.UniversalApiContract'. Make sure that all public types appear under a common root namespace that matches the output file name.

You might get this in different type variations (in my case: 'Windows.Networking.NetworkOperators.MobileBroadbandDeviceServiceCommandResult' ), which of course does not have nothing to do with the error.

This error will probably make you crazy and it will not be easy to solve. To illustrate what has happened here, I created a simple solution with two projects.

Project ClassLibrary1 is a portably library, which targets following platforms:

"net46.app",
"uwp.10.0.app"
"dnxcore50.app"

Project TESTFx is UWP application, which references the ClassLibrary1 as project.

The error shown above (or similar) will pop up during build process, if the portable library has a direct reference to some WinRT assembly (or better to say to some ‘winmd’ file).

In my case this is ‘Windows.Foundation.UniversalApiContract’ as shown at the following picture:

Remove that reference and probably also the code, which requires it and error will dissapear.

Crazy compile-time reference for mscorlib in UWP project(s)

Damir Dobric — Thu, 04 Feb 2016 06:00:00 GMT

Science we started with .NET Core and UAP (Universal Application Platform) we complained very often about unexpected errors, which we simply couldn’t understand.

One of my favorites is this one:

Microsoft.NETCore.Portable.Compatibility 1.0.0 provides a compile-time reference assembly for mscorlib on UAP,Version=v10.0, but there is no run-time assembly compatible with win10.

This error is compile time error caused by following project.json configuration:

{

"dependencies": {

"Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"

"frameworks": {

"uap10.0": { }

"runtimes": {

"win10": { },

"win10-arm": { },

"win10-arm-aot": { },

"win10-x86": { },

"win10-x86-aot": { },

"win10-x64": { },

"win10-x64-aot": { }

}

To workaround this problem, You should change configuration as shown below. Please remove “win10” from list of runtimes.

{

"dependencies": {

"Microsoft.NETCore.UniversalWindowsPlatform": "5.0.0"

"frameworks": {

"uap10.0": { }

"runtimes": {

//"win10": { },

"win10-arm": { },

"win10-arm-aot": { },

"win10-x86": { },

"win10-x86-aot": { },

"win10-x64": { },

"win10-x64-aot": { }

}

Troubleshooting NuGet references

Damir Dobric — Tue, 26 Aug 2014 05:28:00 GMT

When working with NUGET in big projects (just a bit bigger than default hello-world) you might run into following issue:

Could not load file or assembly ‘…’

The prominent of this error example is :Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.

This very simple error message can be caused by a number of different reasons. In this article I will try to put together all issues and solutions which I found.

1. Incorrect assembly loaded

Typically one assembly cannot be loaded, because it is not referenced at all. Assuming that this is very trivial issue, you have probably referenced it.
Unfortunately some other component referenced from your project (i.e. Http.Formatting.Dll) can als reference the same assembly, but different version.

For example, your the required version is defined by NuGet in packages file as follows:

But this does not means, that all other assemblies will try to load exactly this version of the assembly.
(Before you proceed have to first enable Fusion Log to get all binding failures).
If you did it, you will get following more descriptive error:

=== Pre-bind state information === LOG: DisplayName = Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed (Fully-specified) LOG: Appbase = file:///C:/Tfs/Hyperion/Homag/ProFuture/CoreServices/Homag.ProFuture.GenericIDocHandler.Service/ LOG: Initial PrivatePath = C:\Tfs\Hyperion\Homag\ProFuture\CoreServices\Homag.ProFuture.GenericIDocHandler.Service\bin
Calling assembly : System.Net.Http.Formatting, Version=5.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. ===

Please lookup a word: “Calling” to figure out which assembly is trying to load incorrect version. In this case it is System.Net.Http.Formatting. That assembly is trying to load System.Net.Http.Formatting, although you have referenced some higher (or even older) version. The problem is that only one version of the same assembly can be loaded in domain. In this case, your application has loaded v5.2 (specified in packages file) version of Newtonsoft.Json , but Http.Formatting assembly will version 4.5.

To workaround this we need to define assembly binding redirect in web.config (app.config).

</runtime>

This will enforce loading of v6.0.0.0 for all requests of any version of the Newtonsoft.Json assembly.

2. Version mismatch between NuGet and Assembly

If you already did everything as described in step 1, and if you till get the same error. In this case it could be that the NuGet version does not match the version of assembly.
For example, packages file can request assembly as follows:

If you have defined redirect in your config file to load the correct version you will do following:

In this case you have defined everything correctly, but it still does not work, it is most likely that you have a version mismatch problem.
For example NuGet requires v6.4, but assembly version is v6.0 (stored in metadata, explorer does not necessarily helps to see this mismatch).

To fix this you would put in config file following :

Note, assembly loader doe not know anything about nuget. It loads the version as specified in config-file as long this version mathes physically stored metadata.

3. Incorrect assembly referenced

Sometimes when working on different machines or in different workspaces or when you move project in TFS form one location to another one it can happen that incorrect assemblies are referenced.
For example, packages file specifies version 6.0.4 of Newtonsoft.Json.
In this case the reference to that assembly should be something like “C:\Tfs\MyProject\packages\Newtonsoft.Json.6.0.4\lib\net45\Newtonsoft.Json.dll”.
Unfortunately you can figure out that this is not the case. In this case the reference will be typically like: “c:\program files86\referencedassemblies\Newtonsoft.Json.dll”

Basically this means, that this is incorrect version. VS has referenced the default version, because the right one was not found.

If the right version was not found it can be that it does not exist on the disk or it is on different location.
- If it does not exist on the disk
go to Package Manager Console and you will see this:

Click on Restore and package will be downloaded. In this case reference will not be automatically repaired. So, you have to go to references, remove existing
reference (c:\program files86\referencedassemblies\..) and add the correct one C:\Tfs\MyProject\packages\Newtonsoft.Json.6.0.4\lib\net45\Newtonsoft.Json.dll.)

- If it on on different location

you will also have to reference it as describe before. Remove existing reference and add correct one.
Unfortunately this problem mostly happen when you move solution or project in TFS from one location to another one. To fix this you could go to all referenced assemblies and change reference.
This would typically take very long time by 30-50 assemblies which you have in average.

So, right mouse click on project and unload it:

Then edit the project in editor:

Following shows (yellow marked) the assembly which is not correctly referenced. This assembly was originally on location MyProjects\packages. Then the project was moved to different location.

<SpecificVersion>False</SpecificVersion>

<HintPath>..\..\Assemblies\Daenet.SecurityManager.Client\Daenet.SecurityManager.Client.dll</HintPath>

</Reference>

<SpecificVersion>False</SpecificVersion>

<HintPath>..\..\Assemblies\Daenet.System\Daenet.System.dll</HintPath>

</Reference>

<Private>True</Private> <HintPath>..\..\MyProject\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll</HintPath>

</Reference>

<SpecificVersion>False</SpecificVersion>

<HintPath>..\..\packages\Microsoft.AspNet.WebApi.Client.5.2.0\lib\net45\System.Net.Http.Formatting.dll</HintPath>

</Reference>

The right path would be this one in my case.

<Private>True</Private> <HintPath>..\..\packages\Microsoft.Web.Infrastructure.1.0.0.0\lib\net40\Microsoft.Web.Infrastructure.dll</HintPath>

To me this was the best one to see all invalid references at once.
Unfortunately the VS fallback mechanism will not notify us if something is wrong and it will reference the default version, which will be a cause for very bad failures

How to prepare for Side Loading of Windows Store Apps?

Damir Dobric — Tue, 13 May 2014 06:17:00 GMT

If you want to deploy Windows Store Apps in enterprises, Windows 8 provides a concept called “Side Loading”, which is described in this article, at least.
Basically, when preparing side loading, you will have to build the package, sign it and deploy it. Please note, there are several ways do side-load the app.
Right now, deployment can be done by executing power shell scripts, by using of SCOM or it can be distributed on the Windows image itself. There are many articles which describe this procedure, but unfortunately all of them targets deployment with developer license key. That means, you run Visual Studio, create the package and finally start power shell scripts. All look very easy. This is true, because you don’t have to do anything. Visual Studio will take care about everything. Period.
Instead on one thing, called code signing key. VS will create self signing key, which will run under developer license. Developer license is usually valid 30 days, but if it is create by using the store it is valid 90 days.

In this article I will try to describe all required steps which are required for production environment.

To recap all this, following steps have to be done:

1. Prepare your machine
2. Create enterprise signing certificate
3. Enroll Certificate
3. Deploy the app

1. Prepare your machine

Before you deploy the app, you need to do some preparation of the machine where the app has to be installed.
Side loading works in general on Windows Server 2012 and Windows 8 Enterprise editions if following is satisfied:

a) The machine is domain joined.
b) The group policy is set to Allow trusted apps to install.

To setup group policy open Group Policy editor setting located at
Local Computer Policy | Computer Configuration | Administrative Templates | Windows Components | App Package Deployment. Navigate to Allow all trusted apps to install and enable it.

This can also be done by setting following registry key:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Appx\AllowAllTrustedApps = 1

For side loading to Windows 8 Pro, Windows RT, or Windows 8 Enterprise, you need to

a) Activate the product key.
b) Set the group policy to Allow trusted apps to install.

As you see side loading on Windows 8 Pro and Windows RT works only if the product key is activated.
Don’t be surprised, side loading on Windows 8 is supported either by Domain Joining or Key activation.

2. Create Enterprise Code Signing Key

One of most important steps which is in fact major prerequisites for side loading is creating of the code signing key. Unfortunately this step is most difficult one and it is not documented well.
One possible solution would be to buy code signing key. Unfortunately the certificate with signing key for Windows Store Apps is slightly different than usual certificate. More about this latter.
Most articles which reference to side loading describe how to create Self Signing Key. In fact this key is automatically created by Visual Studio.

So, I found one way to make all this happen. It is not very easy and it include multiple steps. I’m sorry for this. Please forgive me, it was not my idea to design it this way :)
To make code signing key you have to have installed corporate (or testing one) Certificate Authority (CA). This article does not cover installation of CA.
Once it is installed there is a old, very old ASP Web application, which is used to request certificates. Following three pictures show several steps in the certificate enrollment process.

This application has few issues. First, it does not provide by default code signing template. Second, It deal with Windows Server 2008 Enterprise certificate templates.
It can only deal with Windows Server 2003 Enterprise certificate templates.
So I decided to try 2003 certificate. templates. Enrollment process worked fine, but unfortunately the app verification process during side load has failed over and over again.
For this reason I decided for me, “This application is not useful for issuing of code signing certificates for Windows Store Apps ”. If somebody knows how to make this working with this application, I would love to see comments here.

But, don’t wary, there are still some possibilities to complete this story successfully.
Open the MMC and and add-in called “Certificate Templates” as shown on the picture below.

Click on the node on the picture above and on the right side the list of installed templates will appear. As next, lookup Code Signing certificate template.
Usually we should not deal with templates assuming that we have certificate template which we need. Unfortunately the Code Signing certificate template,
which you found in the list is not useful for Windows Store Apps. This template will probably be used by other certificate authorities if you decide to purchase the certificate.
In other words, if you use default code signing template side loading will fail.

The reason for this is that certificate for Windows Store Apps requires few more attributes than default template.
Please select the template (right mouse click) and choose “Duplicate”, to create the copy of existing template. You guess, we will extend existing template.

In following dialog you need to select Windows Server 2008 enterprise as shown below.
This is exactly the step which is not supported by Web Application shown above.
Remember, in the web application we had to select Win2003 template.

In the next step, you have change the template. Please be careful to perform exactly described steps.
If you make some mistake in this step, it will be almost impossible (difficult) to figure out why side loading will not work.
As next select Subject Name tab and click “Supply in Request”. This will enforce developer to provide the subject name of the certificate, when certificate is added in the Visual Studio solution.

The subject which is enforced in the last step will became Common Name attribute known also known CN, which should match to the publisher of the app.
As you might know, publisher can/should be associated with the store. This is shown at the right picture below. The Common Name (Subject) must equal Publisher Name shown in package manifest.
To make them same, you will have to enter publisher name in the subject in Certificate Request (explained below).

Note, you don’t have to associate your app with the store account, to make side loading happen. But it is good practice to do this even if you don’t want to publish application
through store. It is good to do it, because Publisher will be set on your publicly known organization name, if the app is associated with your public account.
If you do not associate it with the store account the package will contain your user name as a publisher like shown at the next picture.

Such kind of certificate would not look very professional. This is why it is better to setup organizational account. Even if you use store account
and associate your app with organizational store account, side loading process will remain as it is. No any additional step or tweaks have to be done.

Following picture shows how to make certificate which provides described flow.

As next you need to enable private key to be exported. If you don’t do this you will not be able to move PFX (code signing certificate) with private key.
That means you will not be able to sign the package.

In the next step you should give some descriptive name of the template (see picture below left).
Later, after certificate is created the template name will appear in the certificate as shown at the picture below on right.

Optionally you can set expiration date. Default is one year.
Now , you have to enable Basic Constraints Extension. This is what most code signing certificates do not include (at least at time of writing of this article).
When you purchase this certificate by some third party, be sure that this extension is included.
To add this extension, just click the check-box.

After applying of this template will appear in the list of all templates.

Refresh the list and select your new template.

Finally select it an choose “enable”

This is all what you need to do to create the certificate template.

3. Certificate Enrollment

As next, you have to enroll certificate for you app. To do that open certificate management tool (MMC with user certificate management)

Select the certificate template to be used for your new certificate.

The yellow warning is not an issue. Remember we have chosen for Subject Name “Supply in the Request”.
This is basically what the message below is trying to explain. Ignore this and proceed with “Enroll”.

As next, you can select a friendly name for your certificate.

The certificate Friendly Name and Description are attribute which will become consisted part of your certificate after it is enrolled:

As almost last step, you have to enter the Subject Name of the certificate. This name should be the name copied from the App-Package as
I already described above.

You will not believe me, but this is almost all you need to do for enrollment. Sorry :(

The last step is to export certificate with private key. Select your certificate and click “Export”. Then select YES Export Private Key.
This is important, because without private key, certificate can only be used for verification of signature, but not for creating of signature.

Then select PFX format and enter protection password. This should not be a weak password.

When you later select certificate in the app, you will have to enter the password.
Huuhhh. That’s all for enrollment.

3. Deploy the App

The last required step is to deploy the app. This step is exactly as it should be: “simple”. Visual Studio will do all magic.
Open Package Manifest (Package.appmanifest), click on button “Choose Certificate”, browse for certificate file which you have exported in last enrollment step.
Note that after you select certificate, the password has to be entered, which will unlock the key.

Once you have entered the password, you will not be asked anymore to do that.
You can simply continue with development and deployment. Right mouse click on App-project

, select store and then “Create App Packages”. In the next dialog choose “NO”, which means you are not going to publish the App in the store.
You just want to create the signed package.

Now, select the destination folder of the package and architecture. If you don’t know how to choose proper architecture select “Neutral”. It will work on all architectures.

The package is now created in previously specified folder.

Click on URL and notice following files:

If you execute (open) Add-AppDevPackage.ps1 the app will be installed.
That’s it. I hope this article will help to understand side-load deployment process, which is obviously not easy. In my opinion this process can and must be improved and simplified.
Deploying of an app must not be more complex than development of the app. On the other hand, Store-Concept is great example of simplicity. Unfortunately, deploying an app through store requires integration of your enterprise concept in the deployment process of Microsoft Store Apps via Store. In the real world this does not work, because every enterprise must be process owner of its own deployment process without dependency to any other.
Finally, many steps described in this article do not have to be done by every developer or developer at all. Once you have certificate template and certificate deployment is very easy.

Which .NET features can I use and where?

Damir Dobric — Thu, 08 May 2014 06:37:00 GMT

Following table shows in which platform can be used some newest and some kind of architecturally most important features.
You should be aware if this when designing universal applications for Microsoft multiplatform.

Feature	.NET Framework	Windows Store	Silverlight	Windows Phone
Core	√	√	√	√
LINQ	√	√	√	√
IQueryable	√	√	√	7.5 and higher
Dynamic keyword	4.5 and higher	√	√
Managed Extensibility Framework (MEF)	√	√	√
Network Class Library (NCL)	√	√	√	√
Serialization	√	√	√	√
Windows Communication Foundation (WCF)	√	√	√	√
Model-View-View Model (MVVM)	4.5 and higher	√	√	√
Data annotations	4.0.3 and 4.5+	√	√
XLINQ	4.0.3 and 4.5+	√	√	√
System.Numerics	√	√	√

Where can I find more about new Windows Azure SDK2.3 features?

Damir Dobric — Thu, 10 Apr 2014 13:05:52 GMT

On the last //build/ few days ago, Microsoft has announced (and demonstrated) many improvements across all technology stack.
Please take a look on SDK 2.3 release notes for a list of official information.

If you need a more detailed recap of all important features this is the URL. You will find here also features related to Visual Studio 2013 Release 2 RC.
http://aka.ms/azuresdk23blogpost.

And, don’t forget to take a look on the new preview portal

Microsoft Azure Service Bus: Receiving of messages from queue and topic with JavaScript

Damir Dobric — Thu, 27 Mar 2014 07:47:00 GMT

In the previous post i described how to send messages to Service Bus queues and topic by using Java Script. In this post I will describe how to receive messages from queue and topic subscription.
To illustrate this, take a look on following example. Assuming that ’queue’ is a valid queue path like ‘myorg/myqueue/’ the function below will call receiveMessage on module SB. After the function has completed
the callback will be invoked and message result (messagingResult.body) will be injected as html ($("#result").html(..).
This is how the API behind SB module is designed. Think about SB module as a Java Script SDK for Microsoft Azure Service Bus.

          $("#btnReceive").click(function () {
                SB.receiveMessage(queue, function (messagingResult) {
                    $("#result").html(messagingResult.body);
                    if (messagingResult.properties != null) {
                        $("#msgId").html(messagingResult.properties.MessageId);
                                           }
                });
            });

More over, after the message is received, you can grab several message properties also called BrokerProperties. These properties are returned from Service Bus as
Response Header “BrokerProperties”. The value of the named header is serialized as JSON as shown in following example:

BrokerProperties: {
"DeliveryCount":1,
"EnqueuedSequenceNumber":0,
"EnqueuedTimeUtc":"Wed, 26 Mar 2014 21:06:17 GMT",
"MessageId":"d738041df39c401e89b18dc335f5af24",
"SequenceNumber":38,
"SessionId":"MySession",
"State":"Active",
"TimeToLive":922337203685.47754
}

If you compare retrieved properties with the property set defined on BrokeredMessage class in .NET you fill note that Java Script in the case above
contains a subset of properties of the .NET class.

Remember the class BrokeredMessage has also the property called “Properties”, which can be used to attach an custom property to the message instance.
If such properties are used in the message they will be attached as extra response headers when receiving the message.

Content-Type: application/xml; charset=utf-8
Server: Microsoft-HTTPAPI/2.0
BrokerProperties: {"DeliveryCount":1,"EnqueuedSequenceNumber":0,"EnqueuedTimeUtc":"Wed, 26 Mar 2014 21:06:17 GMT","MessageId":"d738041df39c401e89b18dc335f5af24","SequenceNumber":38,"SessionId":"MySession","State":"Active","TimeToLive":922337203685.47754}
Prop1: 100
Prop2: "Halli Hallo"
Access-Control-Expose-Headers: Date,BrokerProperties,Prop1,Prop2
Access-Control-Allow-Origin: http://localhost
Access-Control-Allow-Credentials: true
Date: Wed, 26 Mar 2014 21:06:54 GMT
Content-Length: 29

"i = 0, payload = 2072651487"

Following snippet shows the original response a some message. You can notice two properties: Prop1 and Prop2. The response shown above is a result
of following C# code, which sends the message:

var msg = new BrokeredMessage("i = 0, payload = 2072651487"),
new DataContractJsonSerializer(typeof(string))) { SessionId = "MySession" };
msg.Properties.Add("Prop1", 100);
msg.Properties.Add("Prop2", "Halli Hallo");
client.Send(msg);

Note that code above uses none default serializer. For more information about message serialization take a look here.

The Java script code in SB.receiveMessage looks like shown below:

       // Receives the message from the queue and deletes it in queue.
        receiveMessage: function (entityName, callback) {

            var securityToken = getToken(entityName);

            var xmlHttpRequest = new XMLHttpRequest();
            var receiveUri = getUri(entityName, "head");
            xmlHttpRequest.open("DELETE", receiveUri, true);
            xmlHttpRequest.setRequestHeader("Authorization", securityToken);
            xmlHttpRequest.onreadystatechange = function () {
                if (this.readyState == 4) {

                    var messagingResult;

                    if (this.status == 200) {

                  var brokerProperties =
                  eval('(' + this.getResponseHeader("BrokerProperties") + ')');

                  brokerProperties.ContentType =
                  this.getResponseHeader("Content-Type");

                 messagingResult =
                  new MessagingResult("Success", this.status,
                  brokerProperties, this.response);
              }

                 else if (this.status == 204) {
                        messagingResult =
                        new MessagingResult("Empty",
                        this.status, null, this.response);
                    }
                    else {
                        messagingResult =
                        new MessagingResult("Failure",
                        this.status, null, this.response);
                    }

                    callback(messagingResult);
                }
            };

            xmlHttpRequest.send(null);
        }

For more information about missing functions like getToken and getUri please refer to previous post.

Be aware of “await” lacks CS1998

Damir Dobric — Tue, 04 Mar 2014 18:38:00 GMT

When working with “async” I figured out, that during refactoring process in development of components statistically “async” can often and implicitly happen. That means, that small changes in method signatures can cause changing of “async” behavior. Mostly developers should and aware of this, but such changes are mostly so silent, that unexpected behavioral changes might be often overseen.

Here one example, which might be harmful, but it can be very dangerous:

warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread.

What does this mean?

Assume you have following code:

   public async Task LoadDataAsync()
   {
    1.        await this.ViewData.Dal.LoadDataAsync();

    2.        //NEXT STATEMENT
   }

If you see this warning on method ,LoadDataAsync() then the line 1 will be executed and immediately after this line the line 2 will be executed.
Assuming that the method LoadDataAsync() is a long-running method, it will likely ends up after executing of next statement in the line 2, before long running of the method is finished. However, note you have put await which is statement that says “Wait on LoadDataAsync() in line 1 to be executed and then execute next statement in line 2.”. Depending on what you are doing in statement 2, the application might possible bind to none existing data are even crash.

Following example shows a BAD implementation of the async method which will cause named warning.

public async Task LoadDataAsync()
        {
            Task t = new Task(() =>
            {
                // Some Long Running Code ..

            });

            t.Start();
      }

The BAD thing in this example is putting of async in front of Task. If you do this, without of having any await in the method, you will get warning CS1998. To prevent warning simply remove async . Unfortunately in the real life, you probably already implemented await inside of that method, but due same refactoring, you decided to implement awaiting code inside of the task body and likely forgotten to remove async .

The CORRECT implementation of this method looks like:

public Task LoadDataAsync()
        {
            Task t = new Task(() =>
            {
                // Some Long Running Code ..

});

t.Start();

return t;
}

Another interesting article for async best practices: http://developers.de/blogs/damir_dobric/archive/2013/07/30/async-error-handling-recap.aspx

Hosting Services in Windows Store Apps

Damir Dobric — Fri, 20 Dec 2013 05:50:50 GMT

When you see the title of this article, you will probably think that idea of the service which runs on device like surface sound a bit strange or even crazy.
But it is not strange, it is just crazy.
If you think about service as a peace of code running on some server and supposed to be consumed by some consumer, you are probably right.
The idea of a service which is running on the side of consumer is kind of wrong.
But if so, we should stop to think traditional way. One software developer should always innovate things.
Assume the service is not supposed to be consumed by consumer. Think about service as a piece of code which can be accessed remotely to observer some data.
In the time of cloud computing we are more and more pushed in direction of totally distributed participants.
Participant is in this context defined as any application which connects via network to the system and participate on data exchange.
In such environment (called cloud) every participant can play a role of a service. Following picture show a number of devices.
If connected together they would build mesh of devices.

Most devices will not provide power of computing, but they can do many interesting task.
For example every simple smart phone can be used as GPS device, which can be accessed remotely. Similarly one microscope can be remotely access to provide current image.
Following this example, we could build the service which runs on smart phone and delivers in some interval the GPS location of the smart phone.
Or similarly, we could build the service to receive remotely command and provide Geo Location data on demand.
In both cases we have to explain device to act as a service. In this article we are more interested on accessing of a device remotely, because it is more difficult.
For the rest of this article we assume that device is running on Windows RT platform. In other words we want to build the WinRT app, which acts as a service.

The idea is to build the service which symbolically implement application which can invoke some operation at the service side:

GeoLocation serviceProxy.GetDeviceLocation(instanceOfTypeX);

On the service side we would usually implement operation as:

GeoLocation GetDeviceLocation(TypeX instance)
{

// service code …

return geoLocation;
}

TypeX is some input argument in the operation, which the service logic might use.

This service could be implemented as SOAP service (for example in WCF) or REST service by using of WebApi. In a case of SOAP service we would
(usually without of knowing it) implement Web Service API style called RPC.
In a case of WebApi we would implement resource API style. Most people speculate about which one is better or cooler.
Due explicate strong dependency of Consumer to the Service, in the world of total distribution I would say booth are not the best choice.
We should rather try to achieve the Message API style. Unfortunately I’m going to explain in this article why.

The caller of the hypothetical service shown above service operation need to obtain some service URL. Unfortunately such URL is the biggest practical issue in this scenario.
To have URL of the service which runs on device, it would mean that service has an IP address. This is not impossible to make happen, but it complicates the environment unnecessary.
In the cloud mesh environment we usually also assume that participant in the systems are moving (mobile). Due this assumption they will not only change their location, but also their network (IP).
In this case no admin will run behind device to setup infrastructure (firewall, VPN and Co.).
So, we need a solution which assumes that devices will at least have an outbound connection to internet via HTTP:80.
This is our only requirement.

Here is how to do it.

As next create Windows Store App in Visual Studio and add NuGet reference to package WindowsAzure.Messaging.Managed.
This package brings messaging functionality in the WinRT platform. For more information take a look here. Then we are going to implement the message listener which will listen for messages.
In our case the message will hold the instance of type TypeX. Following example shows how to do this.

        m_QueueListener = new Queue(“myservice/listener”, m_ConnStr);

        private void StartServiceListener()
        {

               m_QueueListener.OnMessage((msg) =>
               {
                   try
                   {
                       if (msg != null){
                           TypeX instanceOfTypeX = msg.GetBody<TypeX>();

                           GeoLocation loc =
                           service.GetDeviceLocation(instanceOfTypeX);

sendResponse(loc);

                        }
                   }
                   catch
                   {

                   }

               });
        }

On WindowsRT we could start the service as a background worker if the application does not need UI. Somewhere in the code service will be
started by invoking of method

StartServiceListener()

That method enters the message pump loop, which listens for mes

sages sent to the queue “

myservice/listener

”.

After the message is received it is materialized to instance of type TypeX and passed as input argument to implementation of GetDeviceLocation().
This method plays the role of the service operation from the point of view of the caller. But notice, unlikely to SOAP RPC we use the message as a contract.
It is even more interesting, that caller and service are totally decoupled. It means you can stop the service and the message will still arrive after the service is started,
even if the service is started on some other node implemented in JAVA or anything else.
After the operation has completed we can send the response to the response queue by invoking method sendResponse.
Following example shows how to implement this method:

       m_QueueResponse = new Queue(“myservice/receiver”, m_ConnStr);

        private void sendResponse(object response)
        {

await queue.SendAsync(new Message(response));
}

Now you can implement the consumer of this service in almost any technology. Windows Azure Service Bus supports at the moment of writing of this article following protocols:

- SBNP (native TCP protocol used with .NET SDK)
- AMQP native TCP protocol introduced in Service Bus 2.0
- HTTP/REST

This means that two participant can communicate to each other even if they are implemented in different technologies and/or talk different protocols.

However, before queues can be used, somebody have to create them. Following example shows how to:

- Create queues
- Create the key
- Setup SharedAccessKey permissions
- Create connection string

Note that this example is build in .NET for Desktop version of Windows.

        private static void prepareSystem()
        {
             string key = SharedAccessAuthorizationRule.GenerateRandomKey();

            if (namespaceManager.QueueExists(m_qName))
                namespaceManager.DeleteQueue(m_qName);

            QueueDescription qDesc1 = new QueueDescription(m_qName);

            qDesc1.Authorization.Add(new
            SharedAccessAuthorizationRule("device_send_listen", key,
            new AccessRights[] { AccessRights.Listen, AccessRights.Send }));

            var connStr =
            String.Format("Endpoint=sb://YOURNAMSPACE.servicebus.windows.net/;
            SharedAccessKeyName= device_send_listen;SharedAccessKey={0}", key);

        }

The code shown above shows how to create a queue with Listen and Send permission. We could also append permissions more granularly if required:

qDesc1.Authorization.Add(new
SharedAccessAuthorizationRule("device_send", key2,
new AccessRights[] { AccessRights.Send }));

pa permissions:

qDesc1.Authorization.Add(new
SharedAccessAuthorizationRule("device_send", key2,
new AccessRights[] { AccessRights.Send }));

Examples and ideas shown in this article are today all supported by Windows RT and Windows Azure Service Bus. As a developer you will agree, that this might not be a big implementation deal.
However, most of as will probably not immediately notice that examples from above hide in detail huge shift in thinking about how to connect things.
If you have carefully read, you figured out that we use message API style instead of all popular tradition API styles.
This is not new idea, but right now can be achieved in its full power. Notice also that queue mechanism bring on table things like CQRS and support for almost all important integration patterns (i.e. Retry, Pub/Sub etc.). All this helps you to build powerful applications in shorter time.
Last but not least, note that can even communicate through closed inbound connections.
I think, this will open a wide range of new innovations soon.

What is “RyuJIT”?

Damir Dobric — Tue, 22 Oct 2013 06:11:00 GMT

.NET x86 JIT-er, was originally optimized to produce code quickly so that the program starts up fast. However at that point of time x64 architecture was mostly used for server, because it was just expensive.
Because of that .NET 64-bit JIT-er was originally designed to produce efficient code throughout the long run of a server process. That means 64 JIT-er was never really optimized for fast start-up.
Today 64-bit computing become the mainstream. All machines today ship with more than or at least 4 GB of RAM. Even some smart phones use 64 architecture, although they do not need to address 64 RAM space (at least not yet).

.NET Code Generation Team has implemented the new JIT compiler codenamed “RyuJIT”. The new compiler is twice fast as the old one. Because start-up time of one .NET application depends on many complex factors, a twice faster compiling will lead to approximately 30% faster .NET application start-up. This is really great news for .NET community. 30% is in this area hard to achieve.

But, this is not all good news. As the first JIT compiler was done it was the x86 compiler. The came x64 compiler and then MDIL (JIT for Windows Phone). But today we have Windows RT too. So, JIT for ARM was need to. As you see, there are more than one JIT compiler. You might think this is good. It is good from some point of view. Unfortunately all JIT compilers have been different branches which didn’t share lot of same code base. This was very huge limitation factor from the innovation point of view.
With RyuJIT all MDIL, ARM, x86 and x64 are one code base. This will make easy innovation progress in the future.

How to activate RyuJIT?
If you just want to enable RyuJIT for one application only, then set an environment variable: COMPLUS_AltJit=*.
If you want to enable RyuJIT for machine, then set the registry key HKLM\SOFTWARE\Microsoft\.NETFramework\AltJit to the string "*".
In both cases 64-bit CLR will redirect to new RyuJIT instead of the old one JIT64.

Note that both methods do just temporary settings—change. They do not make any active changes to your machine.

You can download CTP version here for 64-bit editions of Windows 8.1 or Windows Server 2012 R2.
Related Blog: http://blogs.msdn.com/b/clrcodegeneration/
You can send mail at ryujit@microsoft.com . The team wants to hear from you!
More about RyuJIT: http://blogs.msdn.com/b/dotnet/archive/2013/09/30/ryujit-the-next-generation-jit-compiler.aspx

Honestly, isn’t this an important step for .NET? I think, It is. Who knows, WinFX as a core of operative system might be now more realistic? If some can make JavaScript as a “cpre”, then why not .NET (WinFX)?

Exchanging messages between devices and services.

Damir Dobric — Tue, 08 Oct 2013 17:57:00 GMT

In this post I will provide few example which shows how to exchange messages between devices and service. In all examples, we will assume that service is implemented in .NET for Windows System32 (today known as desktop) and device is implemented in .NET for Windows RT. Please note that there are many other ways like REST or SOAP which can be used to connect any kind of two participants. Assuming that we expect a high-scale or even “unknown scale” it will be difficult to connect all this things in internet by leveraging common techniques. However the scale is not only issue in this context. Think about pushing of messages to device which are not publicly visible (hosted on private IP behind NAT etc.).
If you want to know more about this please take a look on this post. Clemens has briefly described how “things” might/should work. I strongly believe that we will adopt such or similar ways to connect “things” to each other. Unfortunately we are today probably bit too early. I learned that Hardware Engineering in context of software evolution is in majority of cases the special world of proprietary software solutions from the point of view of a software engineer. This is just my personal my lesson learned.

Example shown in this post shows communication between participants based on Message API style. They will exchange messages through service bus queues.
To be more concrete the service provides API messaging implemented in WindowsAzure.ServiceBus assembly. The simplification of the more or less same functionality is provided by messaging API for Windows RT in assembly Windows.Messaging.Managed.

However you have to be aware of one important thing, which is by design in these two assemblies different. Windows.Messaging.Managed uses by default DataContractJsonSerializer for serialization of messages (invoke of Send method) and for deserialization of message body (calling of Receive method). In contrast, WindowsAzure.ServiceBus uses as default serializer DataContractSerializer.
In other words,

Following example shows how to send the message form service (Windows System32 (desktop)) to device running on Windows RT.

        public static void SendFromServiceToDevice()
        {
            QueueClient client = QueueClient.CreateFromConnectionString(m_DeviceConnStr, m_qName);

            for (int i = 0; i < 10; i++)
            {
                var num = new Random().Next();
                Console.WriteLine("Message {0} sent. {1}", num, i);
                var msg = new BrokeredMessage("i = " + i.ToString() + ", payload = " + num.ToString(),
                 new DataContractJsonSerializer(typeof(string))) { SessionId = "MySession" };
                client.Send(msg);
            }
        }

As you see the code above inject explicitly DataContractJsonSerializer which will be used by serialization of the message.
This code will also use SBMP (original native SB protocol) or AMQP protocol (depending on connection string – see amqp overview and video).
If you send the message this way to device, on the device side you do not have to implement any special message handling. Your code to receive this message is very simple:

public static void ReceiveFromeServiceAtDevice() {
m_Queue = new Queue(m_QueueName, m_ConnStr);
var msg = await m_Queue.ReceiveAsync<string>();
}

But, what if there another service which is implemented as Windows system32 application, which should receive this message?
In this case you cannot receive the same message as you would usually do it. Following code will fail with some very strange SerializationException:

”There was an error deserializing the object of type System.String. The input source is not correctly formatted.”

public static void ReceiveAtServiceFromServiceBAD() {
var client = QueueClient.CreateFromConnectionString(cs, qName, ReceiveMode.ReceiveAndDelete);
var m = client.Receive();
}

To make it working you can explicitly specify the serializer, which will be used to deserialize message:

public static void ReceiveAtServiceFromServiceOK() {
var client = QueueClient.CreateFromConnectionString(cs, qName, ReceiveMode.ReceiveAndDelete);
var st = m.GetBody<string>(new DataContractJsonSerializer(typeof(string)));
}

Following code shows how to inject serializer in windows store app. As firts, you have to receive message as native Message. The type Message is
simplification of type BrokeredMessage.

public static void ReceiveFromeServiceAtDevice() {

Message msg = await m_Queue.ReceiveAsync<Message>();
string strMsg = msg.GetBody<string>(new System.Runtime.Serialization.DataContractSerializer(typeof(string)));

}

Last, but not least is the example which shows how device (windows store app) can inject serializer:

private async void Button_Click_5(object sender, RoutedEventArgs e){

Queue queue = new Queue(m_QueueName, m_ConnStr);

await queue.SendAsync(new Message(m_Txt.Text,
new System.Runtime.Serialization.DataContractSerializer(typeof(string))));

}

This post is also related to following article: http://developers.de/blogs/damir_dobric/archive/2013/06/04/messaging-on-windows-rt.aspx

Windows Store App does not pass certification test due to long file path?!

Damir Dobric — Wed, 02 Oct 2013 06:39:21 GMT

When deploying your app it can happen that you want to publish the update of the app, but certification/publishing fails due the length of the name of some assembly. This happened to as after we implemented support for notification hubs. That means we added assembly Microsoft.WindowsAzure.Messaging.Managed.dll, which has pretty long name. Here is the error which you will see after certification toolkit has checked the application:

FAILED

Performance launch

Error Found: The performance launch test collected the following results:.
- The Native Image Generator failed due to long file path for file C:\Tfs\TfsPreview\SecurityNewsApp\SecurityNews.App\bin\Debug\AppX\Microsoft.WindowsAzure.Messaging.Managed.dll
Impact if not fixed: Application launch time is important for creating a fast and fluid experience for the user. This app will not be accepted by the Windows Store.
How to fix: You should ensure that your app’s performance is consistent across different machine configurations and does not exceed the minimum requirements or it will potentially fail during Windows store onboarding. The informational metrics can provide insight into areas that could help improve your app’s performance, but do not impact your apps acceptance by the Windows Store. See link below for more information:
Performance Best Practices
Known issues in native image generator

To solve the problem, create an empty file nonegen.txt and add it to project as shown below:

This file will prevent the NGEN.EXE to generate the native code during installation of the app. In fact NGEN is the guy who prevents you to have name of the package longer than 88 characters. But please note that excluding of NGEN from build process will slow down startup of the app. In most cases this is not an issue, but sometimes it can be.

More information about this:

http://support.microsoft.com/kb/2716152