If you take a look at my Twitter, I have many examples of me showing passion for Windows On ARM. Ever since I started using my ASUS NovaGo that I won at the 2018 Microsoft Build Conference (this totally had to be fate), I’ve been obsessed with finding practical uses for a device running an ARM64 version of Windows 10 that escaped beyond the bounds of mimicking the exact activities I would do from my phone and more like a typical computer.
As a developer and someone who loves tinkering with things, I wanted to see what this platform can truly do. Naturally, I did the obvious thing and installed Visual Studio 2019, but was quickly reminded that everything is running through an x86 emulation layer. That meant the act of compiling a .NET Core app was happening from an x86 application. That didn’t make me feel too accomplished. Luckily, I was still able to use .NET Core on ARM64 via WSL – which runs amazingly, but I still wanted to be able to build natively in Windows.
So, what did I do to ease my pain? I figured out a way to compile .NET Core for Windows ARM64!
This post is the December 8th entry in Matthew Groves’ The Third Annual C# Advent Series. Check out the other blog posts!
When I first heard of Blazor, it filled me with tons of excitement. If any of you are like me, then you’re a .NET developer who takes on the wild backend code and leaves the complex frontend code to the brilliant UI/UX developers who have done extensive work with JavaScript. With this framework, we can create client-side UI that interacts with the browser mostly without the need to write JavaScript. Another great thing about Blazor is that we can create reusable UI elements using Razor Components. Let’s create a simple wizard component.
Google’s open-source Chromium browser has been gaining a lot of interest from me, as I’ve been trying to build it for ARM64 since January. This past month, I’ve FINALLY accomplished making an ARM64 native build – which is very exciting due to the slowness of x86 translation. If you’re reading this I’m sure you want to know how to build it yourself. Luckily Google has provided some awesome documentation for compiling, but I’m going to skip past the parts that may confuse others. Let’s get to it!
This post is the December 9th entry in the 2018 C# Advent Series. Shout out to Matt for adding me on the roster!
As .NET developers, we will likely run into situations where a client or organization requests an a means for accessing sensitive data. The front-end interface may be a web interface, desktop client, or even a mobile application. These front-ends will access a back-end REST service that pulls in numerous objects from a data source.
How do we secure data access? The easiest answer is to make sure each data request is authenticated with tokens received from an identity framework. To demonstrate a simple way this can be achieved, I'm going to walk-through configuring IdentityServer4 to secure an API that will be consumed by an iOS application built with Xamarin Forms.
In April, Microsoft released a preview of a framework for Windows Store apps that would convert .NET assemblies into the compiled native binaries of the target architecture (x64/ARM for now) in order for application optimization. This tool was named, .NET Native.
To those who are used to grabbing their packaged .XAP file from the Debug/Release directory, things have change with Windows Phone 8.1 (non-silverlight) apps. Instead, we are presented with two ways to create appx packages. This thread will focus on how to use the command line tools rather than use the Visual Studio
As I explained in my previous post, IE 11 doesn’t work out of the box with SharePoint 2013. It seems that my excitement was short lived with the “fix” from the previous post. I didn’t realize that although I took my domain out of Compatibility View, I still happened to have “Display Intranet sites in compatibility view” checked. I found this out from a co-worker as I had to deal with another IE 11 issue. This news bummed me out and led me to a few failed attempts at addressing this issue (writing an HTTPModule and trying to use reflection in order to change the user agent from the request, modifying the navigator object in JavaScript to change the getter method for the userAgent). Luckily, my fix doesn’t mean I necessarily have to throw my changes away from the previous post.
As many of you have noticed, IE11 just doesn’t work correctly with SharePoint 2013:
- Edit Page doesn’t place the page in Edit mode (especially on custom page layouts)
- If you do happen to use a built-in page layout, any webparts added are unable to be customized
- The calendar view doesn’t look right
- The calendar overlay button on the calendar view is disabled
I’ve wondered why Microsoft failed to include IE11 browser support even after SharePoint 2013 SP1, but rather than sit and wonder I decided to take action.
I’ve recently encountered a bit of frustration when dealing with the people picker and publishing workflow in IE 10/11. I decided to dig around and find what was causing such issues (other than Microsoft failing to make SharePoint 2010’s IE compatibility future-proof). First thing I tried was setting the document emulation to IE9 and that worked for the workflow issue, but failed for the people picker dialog. Through trial and error, I’ve determined that IE8 emulation is what’s needed for the people picker dialog to work. How do I put this all together without putting the ENTIRE domain in compatibility view? The X-UA-Compatible header is the answer.
Within the past few days, Microsoft has been rolling out the Windows Phone 8.1 SDK to certain individuals. The SDK happened to be leaked also within this time period which led to the discovery of more features. The features that have been shown are really nice, but that’s not the end of it. With the help of my friend @jessenic, we present even more new features to look out for:
During a long day of coding at work, I’ve been presented with a dilemma while writing code to execute JavaScript CSOM from a JSLink in a CustomAction. The code only executed if the page request was fresh from the address bar or refreshed, but didn’t when I clicked on a link to another page.