Finding the public key of a .Net assembly

In a previous post I explained how to find the public key token of a .Net assembly.

Recently I need to find the whole public key of a .Net assembly.

To achieve the result I extracted the public key token on a temporary txt file and then I extracted the whole public key starting from the token stored on the temporary file.

To extract the public key token on a temporary file, you need a Visual Studio command propt and to use the SN.exe utility:

sn -tp Microsoft.Surface.HidSupport.dll

To extract the whole public key token:

sn -tp temp.txt

that's all, hth

Develop multitouch multiuser for large format displays / tabletops on Windows RT

In the last months I received some mail of developer asking me witch is the future of Samsung SUR40 with Microsoft PixelSense and the development of multitouch multiuser experience on tabletop / large format displays.

Unfortunately, even if there is no official communication, the Samsung SUR40 with Microsoft PixelSense is a discontinued technology.
Hardware isn't produced any more, and on the software (SDK) side, the is no PixelSense product group in Microsoft any more.
I want to underline that there isn't any official communication on that, this is my opinion based on my toughs.

Print screen of the Bing app on Microsoft PixelSense

 

Well now that we know the state of the art let's face our problem.

Problem can be split in two macro category:

  • Which is the appropriate replacement of the Samsung SUR40 with Microsoft Pixel Sense?
  • Which is the appropriate development environment / SDK to develop multitouch multiuser experience for tabletop / large format displays?

About the first question, the hardware, answer is simple:

Perceptive Pixel by Microsoft, I've tried it, you can find an in depth hands on article here, and imho this is the reference hardware for both tabletop or large format displays.

About the second question: which is the appropriate development environment / sdk to use to develop, the answer definitely is Windows Store App Design and development.
That means that you can develop multitouch multiuser user experiences on large format displays / tabletop by using your preferred development language, that includes:

  • C# / WPF
  • HTML5 / JavaScript
  • C++ CX / DirectX

Unfortunately, the Windows Store app design and development have some leaks when we talk of multitouch multiuser development:

  • There isn't any design guidelines for multitouch multiuser application on large format displays
  • We need some controls to enable a multitouch multiuser experience

About the need of some design guidelines for multitouch multiuser development on large format displays, I will be very soft now saying that you can refer to the design guidelines you can refer to the Microsoft Surface 2.0 Design and Interaction Guide to get some direction and rules on your multitouch multiuser development

In a future article I will try to cover only this aspect of the problem.

About the lack of some controls to enable multitouch multiuser development, if we look in depth at the Surface SDK 2.0 and at the Windows Store API we can notice that:

The input stack is noticeably changed between Windows 7 and Windows 8, in the actual Windows Store API all input events comes from one source and all that extension methods that was implemented in the Surface SDK 2.0 such as the touch orientation are now part of the core API.

Drag and drop is also built in.

All the standard object such us button, combo box are touch enabled in the Windows Store API.

All list control are touch enabled and elasticity enabled.

What we need are some proper object of the Surface SDK that we can't find anywhere else, that control are:

  • ScatteView
  • ScatterView Item
  • Library Bar
  • Library Stack
  • Library Control

You can find a replacement of the ScatterView / ScatterView Item in a library I updated some time ago on codeplex, multitouch behavior here you can find an implementation of the scatterview via Windows behavior.

About Library controls I'm working on a version of that controls for Windows 8 after that you will have everything you need to create you multitouch multiuser experience for large format displays on Windows 8.

Intel’s Perceptual Computing Vision

Yesterday at CES2014 in Las Vegas Mooly Eden, Intel's Senior Vice President and General Manager for Perceptual Computing, showed Intel's vision to make computing more immersive and enable human-like natural interactions with devices.
Using Intel RealSense 3-D camera technology in combination with Metaio's augmented reality tools, Intel is looking forward to blurring the virtual and real worlds further than ever before. For example, children will be able to play with their favorite toys and customize their experiences with digital interactions in creative new ways.

Mooly Eden, holds the Intel RealSense 3-D camera, the world's first and smallest integrated user facing 3-D camera which enables devices to see depth, much like the human eye.

 

3D camera is equipped with the Intel RealSense Software Development Kit (SDK) will be released in the first half of 2014. It will be an evolution of the Intel® Perceptual Computing SDK, which was released in 2012.
The Intel® RealSense SDK will include voice recognition in more than 9 languages; background subtraction, a capability that enables developers to add green-screen-like functionality to applications; close-range hand and finger tracking that permits users to control their computing devices with mid-air hand and finger gestures; and face analysis, which identifies users and tracks their facial features across the camera's field of view.
Once the addition of the 3-D tracking and recognition engine by Metaio is completed, the Intel RealSense Computing SDK will offer developers advanced augmented reality features using depth data from the integrated Intel RealSense 3-D camera in computing devices. Below you will find Mooly Eden'speech at CES "Computing is Everywhere" for further information.

 

You can find the video here

 

Insights: Metaio to Integrate 3-D Augmented Reality into Intel® RealSense™ Computing SDK

Consuming RESTful services on Windows Phone – An alternative typed approach

I've just adapted the sample described on my previous article Consuming RESTful services on Windows Store apps – An alternative typed approach to target Windows Phone.

Code and architecture are same, the only difference is the object used to do asynchronous web request. I was using the CSWP8AwaitWebClient in order to make async web request

You can download the full sample on MSDN Code Gallery.

Consuming RESTful services on Windows Store apps – An alternative typed approach

On one of my last project, I was responsible of developing both services and clients (Windows Store and Windows Phone) for an application of one of our customer.

We came out with a solution that we like so I would like to share implementation hoping that it could help in your development.

You can download the full sample on MSDN Code Gallery.

On server side, services exposed to portable clients are RESTful implementing JSON serialization for cross platform compatibility and to save bandwidth

On client, there are few ways to consume services:

  • By adding a service reference to the project
  • By using RestSharp
  • By implementing by hand every call to the service using Windows.Web.Http.HttpClient object

As enterprise developer, I'm usual to consume services thanks to proxies so that all the serialization/deserialization, server request and all what is related to the service logic would be encapsulated on the proxy so that the client developer haven't to care about all that stuff and can concentrate his effort on the client development.

Well, but how to achieve this result?

At glace we need of three layers:

  • A metadata/model layer where to store all types definitions (TypedProxy.W8.Model)
  • A Presentation layer (TypedProxy.W8.UI)
  • A proxy layer where to encapsulate all the logics of communication, serialization etc (TypedProxy.W8.Proxies)

The model layer will be visible by both the presentation and the proxy layer.

Presentation layer will see (will reference) proxy layer

Solution's Layer diagram

 

In that way I can imagine to have a Customer defined in the model layer and a CusomerService defined in the proxy layer so that if we need the list of all customers in the presentation layer we can write something like this:

CustomerService proxy = new CustomerService();

ObservableCollection<Customer> customers = new ObservableCollection<Customer>();

customers = proxy.GetAllCustomer();

 

Ok, let's implement it.

I will try to keep implementation as simple as possible focusing on the proxy layer.

RESTful Service

First of all, we need a REST service. We can implement it by using the ASP.Net Web API.

A simple service exposing a method would be enough. You can check it in the solution TypedProxy.Service.

Here we will modify the WebApiConfig class in the App_Start folder to enable accessing the controller and it's acctions in the simplest way possible:

config.Routes.MapHttpRoute(

name: "DefaultApi",

routeTemplate: "api/{controller}/{action}"

);

We also need to remove the XML serialization from the configuration I that way service will serve only JSON response:

var appXmlType = config.Formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");

config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);    

To complete the service we need a simple controller, CustomerController exposing a method GetAll that will return all customers.

public class CustomerController : ApiController

{

public IEnumerable<CustomerModel> GetAll()

{

// for demonstration purpose response is being delayed

Thread.Sleep(5000);

return Helpers.GetAll();

}

}

Service will delay response for demonstration purpose so on the client we will feel the delay between the request an the response

Helpers is a little static class simulating the database access that will return all customers.

Now let's inspect the TypedProxy.Client.W8 solution.

 

Proxy

Solution is based on three project

  • A metadata/model layer where to store all types definitions (TypedProxy.W8.Model)
  • A Presentation layer (TypedProxy.W8.UI)
  • A proxy layer where to encapsulate all the logics of communication, serialization etc (TypedProxy.W8.Proxies)

TypedProxy.W8.Model contains Customer type

TypedProxy.W8.UI to keep things as simple as possible is based on a single page with a button that will call the proxy in an asynchronous way.

And now the core of this sample: proxy implementation.

First of all, I suppose that you have a number of service and a number of method for each service to call so it's natural to have a base class where to store the deserialization / request implementation so that all derived classes can use that methods.

How to call a service from a Windows Store App? Well is obvious by using the Windows.Web.Http. HttpClient object.

But I want to centralize the point where to use this object in a single place so I will place it in the base class:

public abstract class ServiceClientBase

{

 

public ServiceClientBase()

{

}

 

protected async Task<string> DownloadJsonAsyc(Uri uri)

{

string retVal = string.Empty;

try

{

HttpClient http = new HttpClient();

http.DefaultRequestHeaders.Add("accept", "Application/JSON");

retVal = await http.GetStringAsync(uri);

}

catch

{

// TODO: Log exceprion

}

 

return retVal;

}

}

 

Now I can create my CustomerService proxy:

public class CustomerService : ServiceClientBase, ICustomerService

{

public async Task<ObservableCollection<Customer>> GetAllCustomer()

{

string result = await DownloadJsonAsyc(new Uri("http://localhost:6920/api/Customer/GetAll"));

}

}

As you can see custom method invokes the base method to communicate with server and for every other method / proxy you will add you will ever inherit from the base class also you will ever invoke the same base method.

Here we go, request are centralized.

Now we have to centralize the deserialization of result by implementing another method on the base class:

public abstract class ServiceClientBase

{

public ServiceClientBase()

{

}

 

protected T DeserializeJson<T>(string json) where T : class

{

T type;

DataContractJsonSerializer ser = new DataContractJsonSerializer(typeof(T));

 

using (MemoryStream ms = new MemoryStream(Encoding.UTF8.GetBytes(json)))

{

try

{

ms.Position = 0;

type = ser.ReadObject(ms) as T;

}

catch

{

// TODO: Log exception

type = default(T);

}

}

 

return type;

}

}

 

Deserialization done! If you have to deserialize a value type code is a bit different, if you wouldn't be able to get by your own just ping me.

Now we have only to apply it to our ClienService method

public class CustomerService : ServiceClientBase, ICustomerService

{

public async Task<ObservableCollection<Customer>> GetAllCustomer()

{

//await Task.Delay(2000);

string result = await DownloadJsonAsyc(new Uri("http://localhost:6920/api/Customer/GetAll"));

return DeserializeJson<ObservableCollection<Customer>>(result);

}

}

Here we go. We have our async proxy redy to use and to be replicated for each service / method we need to call.

 

Testing the solution

In order to test the solution you have to launch the service TypedProxy.Service and check that site is hosted on the same tcp port of the client.

Once you started the service a browser window will appear with the hosting site of the service, here you can verify the tcp port.

On the client you can look at the CustomerService class in the proxy and check the tcp port adjusting it with the one of the service if they aren't already same.

Now you can launch client and by opening the app bar (win+Z if you don't have a touch device) and pressing the refresh button you will see the grid being populated by data coming from server.

 

Conclusion

This is an alternative approach of calling services from Windows Store Apps that I hope could help you in the day by day preprogramming.

It is also full applicable to Windows Phone 8 and I will show you in a future post.

 

Ultimi Post

Discalmer

Articles and content of this blog aren't and shouldn't be interpreted as professional advice or opinions. Author writes on a personal basis and as part of their own research, experimentation and knowledge. Opinions expressed aren't in any way attributable to professional affiliations / institutional thereof or to opinions that the author express as part of their roles / positions that may be quite different from that reported here.