Visual Studio Code, .Net Core and UI library

I’ve just checked Visual Studio Code on Windows and Mac. Great application with great responsive UI. On Windows, UI is made with Chromium (chromiumcontent.dll). I will check on Mac too.

One can wonder why Chromium is used instead of Spartan’s EdgeHtml. We can suppose it’s a matter of time but we can also argue that Chromium is cross platform, permitting code simplification. This leads us to the following question: can EdgeHtml be a viable alternative if not available at least on Mac Osx and Linux? And if EdgeHtml escapes from Windows to reach other platforms, it could be a excellent UI library candidate for .Net Core, perhaps better than a Xaml port.

When Microsoft uses HtmlEdge for the name of it’s next html renderer, I immediately hope to see a link with the excellent Edge.js: a good CLR implementation, a good html renderer and a good binding between .Net and javascript available on Windows, Mac and Linux. A dream…

Introducing Visual Studio Code, Visual Studio 2015 RC, Application Insights Public Preview and .NET Core Preview for Linux and Mac – Somasegar’s blog – Site Home – MSDN Blogs.

Supporting only json in Web API

How to either replace every formatter by a single one or to replace IContentNegotiator with a non negociating one (better solution). Supporting only JSON in ASP.NET Web API – the right way – StrathWeb StrathWeb.

Also include an interesting link to Everything you want to know about ASP.NET Web API content negotiation.

Bridges between Win runtime APIs and managed desktop apps

How to use WinRT APIs from managed desktop apps: Managed desktop apps and Windows Runtime – Windows app development. This way is simple. Some available API are packaged in facade assemblies that can be consumed from desktop apps as reference. COM sharing is also detailed.

How to use desktop hosted server from Windows store apps: Brokered Windows Runtime Components for side-loaded Windows Store apps. This way is more restrictive. First, only side-loaded windows store apps can benefits from this mechanism. Then, server must be hosted in special .Net 4.5 assemblies, and last, contracts must be written as winRT components with several limitations:

  • 64 bits restrictions,
  • obligation of providing interface only used by internal mechanism,
  • too much manual winmd file generation,
  • lost of “this field must have such value if you want to avoid strange error message or undefined behavior”,
  • exchanged method parameters must favor bulk transfert using Array of struct (marshalled once) instead of using List<class> where each Next and each property get is a cross-process transfert involving marshalling.

“Samsung Should be Broken Up, I Have the Evidence”

An interesting analysis of Samsung’s failure to listen to its consumers: Samsung Should be Broken Up, I Have the Evidence.

The conclusion which is “Samsung: too big to fail, too big to succeed.” could also be applied to some other high tech company.

When we think that Microsoft have made big efforts to not be broken up by U.S. Department of Justice, one wonders if it was a good thing.

Apple have been able to remain small enough (all things considered) to prevent “silos” effect. The perfect match: highly profitable but small enough to work as a sole team.