Category Archives: software development

.net, development, microsoft, mobile, software development, visual studio, windows

Xamarin 3.0 brings iOS visual design to Visual Studio, cross-platform XAML, F#, NuGet and more

May 28, 2014 onlyconnect 3 Comments

Xamarin has announced the third version of its cross-platform tools, which use C# and .NET to target multiple platforms, including iOS, Android and Mac OS X.

Xamarin 3.0 is a big release. In summary:

Xamarin Designer for iOS

Using a visual designer for iOS Storyboard projects, you can create and modify a GUI in both Visual Studio and Xamarin Studio (Xamarin’s own IDE). The designer uses the native Storyboard format, so you can open and modify existing files created in Xcode on the Mac. The technology here is amazing, since you iOS controls are rendered remotely on a Mac, and transmitted to the designer on Windows. See here for a quick hands-on.

Xamarin Forms

Xamarin has created the cross-platform GUI framework that it said it did not believe in. It is based on XAML though not compatible with Microsoft’s existing XAML implementations. There is no visual designer yet.

Why has Xamarin changed its mind? It was pressure from enterprise customers, from what I heard from CEO Nat Friedman. They want to make internal mobile apps with many forms, and do not want to rewrite the GUI code for every mobile platform they support.

Friedman made the point that Xamarin Forms still render as native controls. There is no drawing code in Xamarin Forms.

“The challenge for us in building Xamarin forms was to give people enhanced productivity without compromising the native approach. The mix and match approach, where you can mix in native code at any point, you can get a handle for the native control, we’re think we’ve got the right compromise. And we’re not forcing Xamarin forms on you, this is just an option,”

he told me.

Again, there is a quick hands-on here.

F# support

F# is now officially supported in Xamarin projects. This brings functional programming to Xamarin, and will be warmly welcomed by the small but enthusiastic F# community (including, as I understand it, key .NET users in the financial world).

Portable Class Libraries

Xamarin now supports Microsoft’s Portable Class Libraries, which let you state what targets you want to support, and have Visual Studio ensure that you write compatible code. This also means that library vendors can easily support Xamarin if they choose to do so.

NuGet Packages

The NuGet package manager has transformed the business of getting hold of new libraries for use in Visual Studio. Now you can use it with Xamarin in both Visual Studio and Xamarin Studio.

Microsoft partnership

Perhaps the most interesting part of my interview with Nat Friedman was what he said about the company’s partnership with Microsoft. Apparently this is now close both from a technical perspective, and for business, with Microsoft inviting Xamarin for briefings with key customers.

.net, android, apple, development, microsoft, mobile, professional, software development, visual studio, windows

Hands on with Xamarin 3.0: a cross-platform breakthrough for Visual Studio

May 28, 2014 onlyconnect

Today Xamarin announced version 3.0 of its cross-platform mobile development tools, which let you target Android and iOS with C# and .NET. I have been trying a late beta preview.

In order to use Xamarin 3.0 with iOS support you do need a Mac. However, you can do essentially all of your development in Visual Studio, and just use the Mac for debugging.

To get started, I installed Xamarin 3.0 on both Windows (with Visual Studio 2013 installed) and on a Mac Mini on the same network.

Unfortunately I was not able to sit back and relax. I got an error installing Xamarin Studio, following which the installer would not proceed further. My solution was to download the full DMG (Mac virtual disk image) for Xamarin Studio and run that separately. This worked, and I was able to complete the install with the combined installer.

When you start a Visual Studio iOS project, you are prompted to pair with a Mac. To do this, you run a utility on the Mac called Xamarin.IOS Build Host, which generates a PIN. You enter the PIN in Visual Studio and then pairing is active.

Once paired, you can create or open iOS Storyboard projects in Visual Studio, and use Xamarin’s amazing visual designer.

Please click this image to open it full-size. What you are seeing is a native iOS Storyboard file open in Visual Studio 2013 and rendering the iOS controls. On the left is a palette of visual components I can add to the Storyboard. On the right is the normal Visual Studio solution explorer and property inspector.

The way this works, according to what Xamarin CEO Nat Friedman told me, is that the controls are rendered using the iOS simulator on the Mac, and then transmitted to the Windows designer. Thus, what you see is exactly what the simulator will render at runtime. Friedman says it is better than the Xcode designer.

“The way we do event handling is far more intuitive than Xcode. It supports the new iOS 7 auto-layout feature. It allows you to live preview custom controls. Instead of getting a grey rectangle you can see it live rendered inside the canvas. We use the iOS native format for Storyboard files so you can open existing Storyboard files and edit them.”

I made a trivial change to the project, configured the project to debug on the iOS simulator, and hit Start. On the Mac side, the app opened in the simulator. On the Windows side, I have breakpoint debugging.

Now, I will not pretend that everything ran smoothly in the short time I have had the preview. I have had problems with the pairing after switching projects in Visual Studio. I also had to quit and restart the iOS Simulator in order to get rendering working again. This is an amazing experience though, combining remote debugging with a visual designer on Visual Studio in Windows that remote-renders design-time controls.

Still, time to look at another key new feature in Xamarin 3: Xamarin Forms. This is none other than our old friend XAML, implemented for iOS and Android. The Mono team has some experience implementing XAML on Linux, thanks to the Moonlight project which did Silverlight on Linux, but this is rather different. Xamarin forms does not do any custom drawing, but wraps native controls. In other words, it like is the Eclipse SWT approach for Java, and not like the Swing approach which does its own drawing. This is keeping with Xamarin’s philosophy of keeping apps as native as possible, even though the very existence of a cross-platform GUI framework is something of a compromise.

I have not had long to play with this. I did create a new Xamarin Forms project, and copy a few lines of XAML from a sample into a shared XAML file. Note that Xamarin Forms uses Shared Projects in Visual Studio, the same approach used by Microsoft’s Universal Apps. However, Xamarin Forms apps are NOT Universal Apps, since they do not support Windows 8 (yet).

In a Shared Project, you have some code that is shared, and other code that is target-specific. By default hardly any code is shared, but you can move code to the shared node, or create new items there. I created XamFormsExample.xaml in the shared node, and amended App.cs so that it loads automatically. Then I ran the project in the Android emulator.

I was also able to run this on iOS using the remote connection.

I noticed a few things about the XAML. The namespace is:

xmlns="http://xamarin.com/schemas/2014/forms"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"

I have not seen this before. Microsoft’s XAML always seems to have a “2006” namespace. For example, this is for a Universal App:

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml

However, XAML 2009 does exist and apparently can be used in limited circumstances:

In WPF, you can use XAML 2009 features, but only for XAML that is not WPF markup-compiled. Markup-compiled XAML and the BAML form of XAML do not currently support the XAML 2009 language keywords and features.

It’s odd, because of course Xamarin’s XAML is cut-down compared to Microsoft’s XAML. That said, I am not sure of the exact specification of XAML in Xamarin Forms. I have a draft reference but it is incomplete. I am not sure that styles are supported, which would be a major omission. However you do get layout managers including AbsoluteLayout, Grid, RelativeLayout and StackLayout. You also get controls (called Views) including Button, DatePicker, Editor, Entry (single line editor), Image, Label, ListView, OpenGLView, ProgressBar, SearchBar, Slider, TableView and WebView.

Xamarin is not making any claims for compatibility in its XAML implementation. There is no visual designer, and you cannot port from existing XAML code. The commitment to wrapping native controls may limit prospects for compatibility. However, Friedman did say that Xamarin hopes to support Universal Apps, ie. to run on Windows 8 as well as Windows Phone, iOS and Android. He said:

I think it is the right strategy, and if it does take off, which I think it will, we will support it.

Friedman says the partnership with Microsoft (which begin in November 2013) is now close, and it would be reasonable to assume that greater compatibility with Microsoft XAML is a future goal. Note that Xamarin 3 also supports Portable Class Libraries, so on the non-visual side sharing code with Microsoft projects should be straightforward.

Personally I think both the Xamarin forms and the iOS visual designer (which, note, does NOT support Xamarin Forms) are significant features. The iOS designer matters because you can now do almost all of your cross-platform mobile development within Visual Studio, even if you want to follow the old Xamarin model of a different, native user interface for each platform; and Xamarin Forms because it enables a new level of code sharing for Xamarin projects, as well as making XAML into a GUI language that you can use across all the most popular platforms. Note that I do have reservations about XAML; but it does tick the boxes for scaling to multiple form factors and for enormous flexibility.

apple, development, microsoft, mobile, professional, software development

Hands on with Cordova in Visual Studio

May 15, 2014 onlyconnect

At TechEd this week, Microsoft announced Apache Cordova support in Visual Studio 2013. A Cordova app is HTML and JavaScript wrapped as a native app, with support for multiple platforms including iOS and Android. It is the open source part of Adobe’s PhoneGap product. I downloaded the preview from here and took a quick look.

There is a long list of dependencies which the preview offers to install on your behalf:

and

The list includes the Java SDK, Google Chrome and Apple iTunes. The documentation explains that Java is required for the Android build process, Chrome is required to run the Ripple emulator (so you could choose not to install if you do not require Ripple), and iTunes is required for deploying an app to an iOS device, though a Mac is also required.

The license terms for both Chrome and iTunes are long and onerous, plus iTunes is on my list of applications not to install on Windows if you want it to run fast. Chrome is already installed on my PC, and I unchecked iTunes.

Next, I ran Visual Studio and selected a Multi-Device Hybrid App project (I guess “Cordova app” was rejected as being too short and simple).

An annoyance is that if you use the default project location, it is incompatible because of spaces in the path:

The project opened, and being impatient I immediately hit Run.

When you build, and debug using the default Ripple emulator (which runs in Chrome, hence the dependency), Visual Studio grabs a ton of dependencies.

and eventually the app runs:

or you can debug in the Android emulator:

A good start.

Microsoft has some sample projects for AngularJS, BackboneJS and WinJS. This last is intriguing since you could emulate the Windows Phone look and feel (or something like it) on Android on iOS, though it would look far from native.

The preview is not feature-complete. The only supported device targets are Android 4.x, IOS 6 and 7, Windows 8.x Store apps, and Windows Phone 8.x. Windows Phone debugging does not work in this preview.

.net, cloud computing, microsoft, mobile, software development

Office, Azure Active Directory, and mobile: the three pillars of Microsoft’s cloud

May 12, 2014 onlyconnect

When Microsoft first announced Azure, at its PDC Conference in October 2008, I was not impressed. Here is the press release, if you fancy a look back. It was not so much the technology – though with hindsight Microsoft’s failure to offer plain old Windows VMs from the beginning was a mistake – but rather, the body language that was all wrong. After all, here is a company whose fortunes are built on supplying server and client operating systems and applications to businesses, and on a partner ecosystem that has grown up around reselling, installing and servicing those systems. How can it transition to a cloud model without cannibalising its own business and disrupting its own partners? In 2008 the message I heard was, “we’re doing this cloud thing because it is expected of us, but really we’d like you to keep buying Windows Server, SQL Server, Office and all the rest.”

Take-up was small, as far as anyone could tell, and the scene was set for Microsoft to be outflanked by Amazon for IaaS (Infrastructure as a Service) and Google for cloud-based email and documents.

Those companies are formidable competitors; but Microsoft’s cloud story is working out better than I had expected. Although Azure sputtered in its early years, the company had some success with BPOS (Business Productivity Online Suite), which launched in the UK in 2009: hosted Exchange and SharePoint, mainly aimed at education and small businesses. In 2011 BPOS was reshaped into Office 365 and marketed strongly. Anyone who has managed Exchange, SharePoint and Active Directory knows that it can be arduous, thanks to complex installation, occasional tricky problems, and the challenge of backup and recovery in the event of disaster. Office 365 makes huge sense for many organisations, and is growing fast – “the fastest growing business in the history of the company,” according to Corporate VP of Windows Server and System Center Brad Anderson, speaking to the press last week.

Brad Anderson, Corporate VP for Windows Server and System Center

The attraction of Office 365 is that you can move users from on-premise Exchange almost seamlessly.

Then Azure changed. I date this from May 2011, when Scott Guthrie and others moved to work on Azure, which a year later offered a new user-friendly portal written in HTML5, and Windows Azure VMs and web sites. From that moment in 2012, Azure because a real competitor in cloud computing.

That is only two years ago, but Microsoft’s progress has been remarkable. Azure has been adding features almost as fast as Amazon Web Services (AWS – and I have not attempted to count), and although it is still behind AWS in some areas, it compensates with its excellent portal and integration with Visual Studio.

Now at TechEd Microsoft has made another wave of Azure announcements. A quick summary of the main ones:

Azure Files: SMB shared storage for Azure VMs, also accessible over the internet via a REST API. Think of it as a shared folder for VMs, simplifying things like having multiple web servers serve the same web site. Based on Azure storage.
Azure Site Recovery: based on Hyper-V Recovery Manager, which orchestrates replication and recovery across two datacenters, the new service adds the rather important feature of letting you use Azure itself as your space datacenter. This means anyone could use it, from small businesses to the big guys, provided all your servers are virtualised.
Azure RemoteApp: Remote Desktop Services in Azure, though currently only for individual apps, not full desktops
Antimalware for Azure: System Center Endpoint Protection for Azure VMs. There is also a partnership with Trend Micro for protecting Azure services.
Public IPs for individual VMs. If you are happy to handle the firewall aspect, you can now give a VM a public IP and access it without setting up an Azure endpoint.
IP Reservations: you get up to five IP addresses per subscription to assign to Azure services, ensuring that they stay the same even if you delete a service and add a new one back.
MSDN subscribers can use Windows 7 or 8.1 on Azure VMs, for development and test, the first time Microsoft has allows client Windows on Azure
General availability of ExpressRoute: fast network link to Azure without going over the internet
General availability of multiple site-to-site virtual network links, and inter-region virtual networks.
General availability of compute-intensive VMs, up to 16 cores and 112GB RAM
General availability of import/export service (ship data on physical storage to and from Azure)

There is more though. Those above are just a bunch of features, not a strategy. The strategy is based around Azure Active Directory (which everyone gets if they use Office 365, or you can set up separately), Office, and mobile.

Here is how this works. Azure Active Directory (AD), typically synchronised with on-premise active directory, is Microsoft’s cloud identity system which you can use for single sign-on and single point of control for Office 365, applications running on Azure, and cloud apps run by third-parties. Over 1200 software as a service apps support Azure AD, including Dropbox, Salesforce, Box, and even Google apps.

Azure AD is one of three components in what Microsoft calls its Enterprise Mobility Suite. The other two are InTune, cloud-based PC and device management, and Azure Rights Management.

InTune first. This is stepping up a gear in mobile device management, by getting the ability to deploy managed apps. A managed app is an app that is wrapped so it supports policy, such as the requirement that data can only be saved to a specified secure location. Think of it as a mobile container. iOS and Android will be supported first, with Office managed apps including Word, Excel, PowerPoint and Mobile OWA (kind-of Outlook for iOS and Android, based on Outlook Web Access but delivered as a native app with offline support).

Businesses will be able to wrap their own applications as managed apps.

Microsoft is also adding Cordova support to Visual Studio. Cordova is the open source part of PhoneGap, for wrapping HTML and JavaScript apps as native. In other words, Visual Studio is now a cross-platform development tool, even without Xamarin. I have not seen details yet, but I imagine the WinJS library, also used for Windows 8 apps, will be part of the support; yes it works on other platforms.

Next, Azure Rights Management (RMS). This is a service which lets you encrypt and control usage of documents based on Azure AD users. It is not foolproof, but since the protection travels in the document itself, it offers some protection against data leaking out of the company when it finds its way onto mobile devices or pen drives and the like. Only a few applications are fully “enlightened”, which means they have native support form Azure RMS, but apparently 70% of more of business documents are Office or PDF, which means if you cover them, then you have good coverage already. Office for iOS is not yet “enlightened”, but apparently will be soon.

This gives Microsoft a three-point plan for mobile device management, covering the device, the applications, and the files themselves.

Which devices? iOS, Android and Windows; and my sense is that Microsoft is now serious about full support for iOS and Android (it has little choice).

Another announcement at TechEd today concerns SharePoint in Office 365 and OneDrive for Business (the client), which is getting file encryption.

What does this add up to? For businesses happy to continue in the Microsoft world, it seems to me a compelling offering for cloud and mobile.

.net, development, open source, software development, visual studio

Microsoft’s new open source direction for C# and .NET (and native compilation too): Anders Hejlsberg explains

May 1, 2014 onlyconnect 2 Comments

At the April 2014 Build conference Microsoft made some far-reaching announcements about its .NET platform and the C# programming language. Yes, there was talk of C# 6.0, the next version, but the real changes are more profound. Specifically:

C# and Visual Basic have a new compiler, itself written in C#, code-named Roslyn. Roslyn is not just a new compiler; Microsoft now calls it the “.NET Compiler Platform”.

There is a new commitment to open source for .NET projects. Microsoft formed the .NET Foundation to oversee existing open source projects, including ASP.NET, Entity Framework, the Azure .NET SDK, and now Roslyn as well. “When it comes to development projects we are going to operate from the premise that open source is the default. Unless there are reasons why it does not work,” said C# lead architect Anders Hejlsberg.

Note that open source does not mean chaos. It does mean that you can fork the project if you want – the Roslyn license is Apache 2.0 – but getting Microsoft to accept new features you have contributed will not be trivial. Hejlsberg makes the point that language features are easy to add, but impossible to take away, so extreme care is necessary.

Microsoft is also supporting cross-platform C# to a greater extent than it has done in the past. The most obvious sign of this is its cooperation with Xamarin, which provides C# compilers for iOS and Android. Xamarin’s Miguel de Icaza got a top billing at Build, and is also involved in the .NET Foundation.

There is more though. The idea of standardised C# is re-emerging:

“The last ECMA standard was C# 2.0. There wasn’t a lot of demand for it, but that demand has recently risen and we have re engaged with the ECMA community to produce a standard for C# 5.0,” said Hejlsberg.

This bears some unpacking. Why was there little demand for ECMA C#? Partly I would guess from the assumption the C# was firmly in Microsoft’s grip, with Java the obvious choice for cross-platform development. The main interest was from the Mono folk (Miguel de Icaza again), which implemented .NET for Linux and the Mac with some success, but nothing to disturb Java’s momentum.

The focus now though is on mobile, and interest in C# is stronger, mainly from Microsoft-platform developers reaching beyond Windows. There is also Unity, which uses C# as a scripting language for developing games for multiple platforms, including iOS, Android, Windows, Mac, Linux, Xbox, PS3 and Wii – PS4 is coming very soon.

Microsoft has now consciously embraced multiple platforms, as evidenced by Office for iOS as well as the Xamarin collaboration. “We want C#developers to build great applications across different form factors and different device platforms,” said Jay Schmelzer Director of Program Management for Visual Studio.

You might observe that this position has been forced on the company by the rise of iOS and Android, a view which likely has some merit, but the impact it has on C# and .NET itself is still real.

I asked Hejlsberg to unpack the difference between the Roslyn project and C# 6.0, bearing in mind that both are covered on the Roslyn open source site; you can see the current status of C# 6.0 and the next Visual Basic here.

Roslyn is the name for the project that encompasses the new C#compiler and the new VB compiler and the new language services that they share. C# 6.0 is the name of the next version of the C #language which will have a specification and which will have an implementation. We are implementing C# 6.0 on the Roslyn platform. We are not going to continue to evolve our old C++ C# compiler – the C# compiler was originally written in C++ and has been evolved up through C# 5.0. That is where we are going to retire that code base, and going forward versions of C# will be built on Roslyn and therefore will be built open source. Unlike previously where, boom. C# came down from the sky with a set of features, it is going to happen more organically now, people will submit pull requests, open up issues, and you will see us work on these features. You will see them from inception to fruition.

“The C# team, the Roslyn team, the VB team, their day to day workplace now is the open source site. That is where they check-in code. It is a community in the making.

Even that is not all. At Build, Microsoft also announced .NET Native, which is a native compiler for C# and Visual Basic, now in preview for x64 Store apps. What is the difference between .NET Native and the existing NGen native compiler for .NET? Over to Hejlsberg:

NGen is the native feature that we currently support. NGen is really, “I’m going to JIT [Just in time compile] your code and then snapshot all the data structures and dump them in a file so that I can quickly rebuild that file later when you run this particular application”. But it is the same code generator and all the same features, and JIT is still there. NGen is really a way to pre-cache the JIT output and therefore get better performance, but it adds to the size of your app because you still have all the assemblies and metadata and then the NGen image as well.

.NET Native is a completely different approach. Instead of the JIT we use the backend from the C++ compiler. You can think of it as a linker that takes as input assemblies, and as output produces a PE [Portable Executable] executable. In the process this linker or code generator will analyse all the IL [Intermediate Language] that goes into the application and it will apply a thing known as tree-shaking where it eliminates all of the code that will never execute based on known execution roots.

In other words, the public static main of your program and also whatever pieces of your app that you designate as reflectable, they also become roots. Based on that we produce an optimised exe, and into that exe we link the pieces of the framework that you are referencing. We link in a garbage collector [GC], and it looks to the operating system just like an exe. When you run it, it runs a local GC in there and it is as efficient really as C++ code.

There are some restrictions associated with .net native, mainly that you can’t just willy-nilly reflect on the whole world. You can’t just generate new code and ask for that to be jitted because they may not be a JIT compiler. We are considering allowing you to link in a JIT compiler, but there are certain execution environments which don’t permit jitting, like Xbox. If you use reflection in your lap you have to tell us what to keep reflectable, because otherwise we will optimise it away.

According to Schmelzer:

The preview out today is scoped to Store app x64 and ARM. We haven’t run into any technical limitation that shows it can’t be done across the breadth, it is just a matter of request and need.

Open source, native code compilation, and an innovative compiler: it adds up to huge changes for C# and .NET, positive ones as far as I can tell.

The Xamarin connection is intriguing though. Developers in general admire the technology as far as I can tell, but it is expensive, and paying out for a Xamarin subscription on top of maybe MSDN for Visual Studio is too much for some smaller organisations and does not encourage experimentation. Might Microsoft acquire Xamarin and build Visual Studio into an IDE targeting all the major mobile platforms, but with special hooks to Azure-hosted services?

That prospect makes sense to me, though it would be a shame if the energetic Xamarin culture became bogged down in big-company bureaucracy. Currently though: no news to report.

microsoft, professional, software development

Brief reflections on 50 years of BASIC

May 1, 2014 onlyconnect 2 Comments

Beginner’s All-Purpose Symbolic Code (BASIC) has turned fifty, as reported on The Reg and by Jack Schofield on ZDNet. A great moment in computer history, or would we have been better off without it?

My first computer (a Commodore PET) ran Basic from ROM, and without it you could do nothing, though developers bypassed it by using the POKE command to write low-level instructions into memory. The language is meant to be forgiving (as far as a computer language can be) and English-like, at the expense of being a little more verbose. It is case-insensitive and does not require braces or semi-colons to indicate blocks or lines of code, which makes programming look less intimidating for beginners.

I graduated onto an Atari ST, for which there was an excellent Basic implementation called GFA Basic, fast and capable. This was great for writing utilities, though, though serious programming tended to use one of several strong C compilers: Lattice C, Mark Williams C, HiSoft C come to mind.

Basic also had a role, even on the ST, as a macro language for applications. For example, the Superbase database manager used a version of Basic.

The company most strongly associated with Basic though is Microsoft. A version of Basic came with MS-DOS.

Microsoft also supported Basic for professional development. Microsoft Basic Professional Development System 7.x was a well-regarded development tool for business applications, though commercial shrink-wrap software tended to be written in C or C++.

That trend followed through to the Windows graphical environment. Visual Basic (VB), which made it easy to code Windows applications, was perhaps the most significant Basic release in terms of its impact, especially when it reached version 3.0 with full database support. Its popularity was such that many developers felt wounded when Microsoft discontinued Visual Basic 6.0, a direct successor, in favour of Visual Basic .NET which is something incompatible and different.

Further, VB 6.0 or something very like it lives on today, in the form of Visual Basic for Applications as found in all recent versions of Microsoft Office.

Despite this, Basic is in decline. Most of the professional developers I meet at events like Build use C# in preference to Visual Basic, there being little reason not to. C# is the premier language of .NET, and Visual Basic gets in the way if you want to keep up with latest .NET developments. Xamarin, which lets you code in .NET for iOS and Android, supports C# but not Visual Basic. Once you come to terms with semi-colons, braces and case-sensitivity, there is no real advantage to Visual Basic and C# is no more difficult.

I do see Visual Basic still used in education though, as well as by some developers who either prefer the language or are so used to it that they see no need to change; and to be fair, Xamarin aside, there is little if anything you can do in C# that you cannot also do in VB and the output is more or less the same.

The Roslyn project, which will be part of the next version of C# and probably in the next release of Visual Studio, lets you paste C# code as VB and vice versa.

Nevertheless, I believe we will see further decline in Basic usage, especially as it is little used outside Microsoft’s platform.

Would it have been better if Microsoft has not adopted Basic so wholeheartedly? There are some problems with Basic, though it is possible to write excellent code in Basic just as you can write poor code in C#, Python, C, or other more fashionable languages. Some issues:

Early versions of Basic encouraged badly structured programming with keywords like GOTO and GOSUB resulting in intricate loops that were hard to follow or debug.
Basic abstracts how software works to such an extent that you do not learn some important programming concepts such as pointers, addresses, memory allocation.
There is no natural progression from Basic to the C-like languages which dominate computing (C,C++,JavaScript,C#).
Visual Basic encourages developers to mix GUI code and business logic in the same files, as well as building user interfaces that tend not to scale well.
Small and declining professional use means that Basic is less useful than many other languages in the job market.

That said, Basic powers many excellent business applications as well as introducing many to the wonders of programming, and deserves our respect.

software development, visual studio, windows

XAML and C#, or HTML and WinJS for Windows Store, Universal and cross platform apps?

April 28, 2014 onlyconnect 4 Comments

Microsoft designed the Windows Runtime (WinRT, the engine behind the controversial touch-friendly “Metro” user interface in Windows 8) to support three development platforms. These are C++ with XAML (for most GUI apps) or DirectX (for fast games); or C# and XAML; or HTML and JavaScript using the WinJS library for access to Windows-specific functions.

Microsoft’s line is that all three approaches are fine to use, with little performance difference other than that C++ avoids an interop layer. Of course if you have any arbitrary code that runs faster in C++ than in C#, then you will still see that difference in the WinRT environment.

It is also obvious that if you are an HTML and JavaScript expert but know nothing of C# or XAML, you should use WinJS; similarly if you have a lot of C# code to port and know nothing of HTML or JavaScript, C# and XAML chooses itself.

But what if you approach the decision from a neutral perspective. I am going to leave aside the C++ option for the moment as it is more of a leap than C# versus JavaScript. Which is best?

On the WinJS side, a common misconception is that this library is only for Windows. At Build 2014 Microsoft announced that WinJS is now open source, and works on other browsers and devices:

The library has been extended to smaller and more mobile devices with the release of WinJS 2.1 for Windows Phone 8.1, which was announced today at //build. Now that WinJS is available for building apps across Microsoft platforms and devices, it is ready to extend to web apps and sites on other browsers and devices including Chrome, Firefox, iOS, and Android.

In order to sample this, I went along to try.buildwinjs.com on an iPad. All the things I tried quickly worked fine on iOS.

If you used WinJS to build an app, you could use PhoneGap or Cordova to package it as a native application for the iOS or Android app stores.

A further reflection on this is that some of the WinJS controls which you might have assumed are native WinRT controls instantiated from JavaScript are in fact implemented in CSS and JavaScript. That is an advantage for cross-platform, but does suggest that Microsoft has been busy duplicating the look and feel of XAML controls in HTML and JavaScript, which seems a lot of work and an approach which is bound to result in inconsistencies.

Another snag with this approach – leaving aside the questions of performance and so on which I have not investigated – is that you end up with the distinctive look and feel of a Windows 8 app, which is going to be surprising on these other devices.

C# also has cross-platform potential, thanks to the great work of Xamarin and not forgetting RemObjects C#. Note though that I wrote C# rather than XAML. There is no cross-platform XAML implementation other than the abandoned cross-platform Silverlight efforts, Silverlight for the Mac and Moonlight for Linux. Xamarin expects you to rewrite your UI code for each platform – which may in fact be a good thing, though more effort.

If you are focused on the Windows platform though, it seems to me that the pendulum is swinging away from WinJS and towards C# and XAML. Wordament is an interesting case. This is one of the better games for Windows 8, and also available for Windows Phone, iOS and Android. Originally this was implemented in HTML and JavaScript. The developers have blogged about the choices they made:

Wordament grew up very fast. It seemed like it went from an indie game with a handful of players to a full on Microsoft title with millions of users, on lots of platforms, almost overnight. In that transition we ended up writing lots of code. For instance, in the course of a year we had ports of the Wordament client written in JavaScript, Objective C, C++ and C#. Each one of these ports has its own special issues, build processes and maintenance challenges. At the time, we were still a two person team and Jason and I were struggling to continue to innovate on Wordament, while supporting the “in-market” code bases we had shipped. So we started looking for a solution that would allow us to share more code between all of the platforms we were targeting. Funnily enough, the answer was sitting in our own backyard: C#.

As we looked around at the state of “cross platform development” on Windows, Windows Phone, iOS and Android we started to realize that C# was an excellent choice to target all modern mobile devices. So we did just that. With the help of Visual Studio for Windows and Xamarin for iOS and Android, we started a project to build a single version of Wordament’s source code that could target all the platforms we ship on. This release on Windows 8 marks the end of that journey. All of our clients are now proudly built out of one source tree and in one language. Even our service, which runs on Windows Azure, is built in C#. This is a huge efficiency win for our team of four.

Notable also is that the forthcoming Office for WinRT, previewed at Build, is written in XAML and C++ (according to what I was told). This means XAML will get some love inside Microsoft, which is bound to be good for performance and features.

An advantage of the C# approach is simply that you get to use C#, which is well-liked by developers and with some compelling new features promised in version 6.0, many thanks to the Roslyn project – which also promises a smarter editor in Visual Studio.

What about XAML? This is harder to love. XML is out of fashion – too verbose, too many angle brackets – and the initial promise of a breakthrough in designer/developer workflow thanks to XAML and MVVM (Model – View – ViewModel, which aims to separate code from user interface design) now seems hollow. I am writing a game in XAML and C# and do not much enjoy the XAML part. One of the issues is that the editing experience is less satisfactory. If you make an error in the XAML, the design view simply blanks out with an “Invalid Markup” error. Further, the integration between the XAML and C# editors is a constant source of problems. Half the time, the C# editor seems to forget the variables declared in XAML, giving you lots of errors and no code completion until you next compile. Even when it is working, a rename refactor in the C# editor will not rename variable references that are within quotes in the XAML, for example property names that are the targets of animations.

On the plus side, XAML is amazing in what it can do when you work out how. The user interfaces it generates are rich, scalable and responsive. It is way better that the old Win32 GDI-based approach (also used in the Windows Forms .NET API), which is hard to get right for all the combinations of screen sizes and resolutions, and has odd dependencies on system font sizes and dialog units (don’t ask).

Despite the issues with XAML, C# and XAML (or C++ and XAML) is my own preference for targeting the new Windows platform, but I am interested in other perspectives on this.

development, microsoft, professional, software development, windows

Windows problems: new users cannot log in, SQL Server 2014 install fails

April 23, 2014 onlyconnect

Two issues I have seen recently:

1. A Windows 7 laptop which belonged to a developer and was being passed on to a new user. However, although you could create the new user, you could not log in as that user. The error was “User Profile Service service failed the logon. User profile cannot be loaded.”

I narrowed the problem down to an “Access denied” error when trying to create the profile, but we decided to restore Windows to factory settings (using recovery tools) since that was probably a better approach for the new user anyway – you never know what a developer may have tweaked or installed in Windows!

2. SQL Server 2014 Database Engine installation failing on Windows 8. The reported error: Could not find the Database Engine startup handle.

Annoyingly, you cannot attempt a repair install if you get this, since repair cannot run if there has not been a successful install in the first place. However this error does not rollback the installation, so you have the feature installed but not working. You have to remove the SQL Server feature using control panel, then you can retry. I got this on a couple of machines, tried a few things but failed, so used fresh VMs instead.

Others have run into this and there is a solution, which applies to both problems. They are actually the same, since SQL Server 2014 creates a new profile in the default install.

This solution means resetting the permissions on c:\users\default so that they are replaced with permissions inherited from the parent folder. This solution works; but it is not perfect, since these are the wrong permissions for the folder (too loose). Someone has done the job of finding the correct permissions for Windows 7. Applying all these is arduous though, and things may possibly have changed with updates since. In a production environment it would be better to narrow down the exact permission that is wrong, or to do a system restore.

If you are happy to risk it, navigate to c:\users in Windows Explorer and find the Default folder. This is hidden by default; you can make it visible using the View Options in Explorer; on the View tab choose Show hidden files, folders and drives. Next, right-click the c:\users\Default folder and choose Properties, then the Security tab, then Advanced, then click Change Permissions. Check the box:

Replace all child object permission entries with inheritable permission entries from this object

Click OK – it does not take long – and now new users can log in, and the SQL Server 2014 setup runs OK.

The problem seems to be common so it is likely that either an official update or a commonly-used third-party install is breaking these permissions. I would be glad to know what it is; it would also be good if Microsoft would build into Windows a feature that would restore default permissions for a system folder like this one.

Update: It may be sufficient to delete a single file. See this thread where event logs lead to a sqmdata…sqm file that, when deleted, fixed the issue. Check the Windows Application log for event 1509.

development, microsoft, software development, visual studio, windows

Notes on styling a Windows Store app ListView to vary item appearance according to the data

April 22, 2014 onlyconnect

Problem: You have a ListView containing data. You want to vary the appearance of items in the ListView according to the value of the data.

I spent some time on this in relation to a panel for a game I am writing. For example, you have a ListView containing numbers. How can you have negative numbers appear in red?

In desktop WPF (Windows Presentation Foundation) you could do this with Property Triggers but these are not supported in Store apps.

One way to do this is with a value converter. Add a class to your project called MyValueConverter. Make the class public, and inherit from Windows.UI.Xaml.Data.IValueConverter.

Right-click IValueConverter and choose Implement Interface to have Visual Studio create two stub methods, Convert and ConvertBack.

This class is going to return an object which will be applied to the Foreground property of a ListViewItem. The Convert method looks like this:

public object Convert(object value, Type targetType, object parameter, string language)

At runtime, the value argument will contain the item displayed in this row of the ListView. The targetType will match the type of the property we are setting, which in this case is a Brush object.

Now add an instance of MyValueConverter to MainPage.xaml (or App.xaml) as a resource. If there is no Page.Resources element, create it, and add an instance of MyValueConverter with the Key “NumberForegroundConverter”:

<Page.Resources>
<local:MyValueConverter x:Key="NumberForegroundConverter" />
</Page.Resources>

Next, select the ListView element in the XAML editor or designer. Right-click the selected element in the designer, and choose Edit Additional Templates – Edit Generated Item Container (ItemContainerStyle) – Edit a Copy …

Accept the default name of ListViewItemStyle1 and click OK.

This generates an element that defines the layout and appearance of items in the ListView. Currently it does not appear to do anything, since it is a copy of the default settings.

Find the element called <ListViewItemPresenter> which is nested within <ControlTemplate TargetType=”ListViewItem”>. No Foreground attribute for ListViewItemPresenter is generated, but we can add one:

Foreground="{Binding Converter={StaticResource NumberForegroundConverter}}"

If you now run the project, you will get an exception, because the methods in MyValueConverter do not yet have any code. Now we have to think about the type of the items in the ListView. In this example, I just typed some strings into the XML editor:

All the items are strings, so the Convert method can look like this:

String s = (String)value; //note this ONLY works if the item is always a string

if (float.Parse(s) < 0)
{
return new SolidColorBrush(Windows.UI.Colors.Red);
}
else
{
return new SolidColorBrush(Windows.UI.Colors.White);
}

We don’t care about the ConvertBack method so can use this code:

return Windows.UI.Xaml.DependencyProperty.UnsetValue;

It works but there are some issues. One oddity is that when you roll the mouse over a negative number, it looks the same as a positive number.

This is because we did a converter for the Foreground property but not for the SelectedForeground property. XAML in Store apps makes extensive use of themes, and themes include a lot of brushes.

Another issue, which may or may not impact your application, is that the converter code does not run again if you change the displayed item dynamically. That is, if you replace the item it updates OK, but if you update the existing item it does not.

A slightly more complex example will demonstrate this. Let’s say that rather than displaying strings, the ListView is displaying Widget quantities, where a negative number indicates backorders. The ListView is bound to an ObservableCollection<Widget>, and the Widget class implements INotifyPropertyChanged so that the ListView will update automatically when a Widget property changes. Note that the NumberForegroundConverter must be updated to accept a Widget value rather than a string.

Here is what happens if a Widget had a negative quantity when the ListView was first populated, but got dynamically updated to a positive value (some stock arrived):

Oops! Now the positive quantity is in red.

We can fix this by abandoning the converter, and instead giving the Widget class a Foreground property of its own, calculated to return Red for negative quantities and White for positive. Make sure it fires a NotifyPropertyChanged event when updated. Now the Foreground property in <ListViewItemPresenter> looks like this:

Foreground="{Binding Foreground}"

It works:

I used this approach in my game in order to implement an Enabled property that indicates items which are unselectable. This changes dynamically according to the state of the play.

Note that you are unlikely to want a Foreground property in your business objects, but could create a DisplayWidget class for the purpose.

I realise that these are not the only ways to create a ListView which styles items differently according to their values, but they may be the simplest. Other suggestions and comments are welcome.

Update: Mike Taulty has some comments and suggestions here.

.net, development, microsoft, software development, visual studio, windows

A quick hands-on with native code compilation for .NET

April 9, 2014 onlyconnect 4 Comments

I had a quick look at the .NET Native Preview. I am interested to see what the benefits might be. Note that currently the preview only supports 64-bit Windows Store apps.

Here is what is promised:

For users of your apps, .NET Native offers these advantages:

Fast execution times

Consistently speedy startup times

Low deployment and update costs

Optimized app memory usage

I created a small C# app that counts prime numbers using a simple approach. I created it first as a Universal App that does not use .NET Native, and then as a second app that does use .NET Native.

My initial results are disappointing. The time taken to count prime numbers is similar in both apps.

As a further test, I added code that adds the prime numbers found to a ListView control using an async task. The idea was to see if GUI interaction and multi-threading would be more revealing than simply crunching numbers in a tight loop. The apps takes much longer with this enabled, but again, there is nothing to choose between the two.

Did I really succeed in compiling the app to native code? I think so. Here are the contents of the AppX folder for the standard .NET executable:

and here for the native compiled executable – note the additional DLLs:

I am not actually surprised that there is no performance benefit in my example. JIT (just-in-time) compilation means that any .NET application is native code at runtime, though optimization might be different.

I have ended up with a much larger app to deploy, though the relative difference would be less, I imagine, with an app that contains more code.

I can also readily believe that start-up time will be better for a native compiled app, since there is no need for the JIT compiler. However my app is so small that this is not significant.

My question though is what kind of app will benefit most from native compilation? I would be interested to see guidance on this.

Of course it is also possible that later iterations of the technology will yield different results.

Tim Anderson's IT Writing