Tag Archives: .net

.net, cloud computing, microsoft, silverlight, software development, visual studio

Common sense on Windows 8, Silverlight and .NET

31 Comments

I am wary about writing another post on this subject in the absence of any further news, but since there is a lot of speculation out there I thought it would be worth making a few further observations.

Will Windows 8 support Silverlight and/or some other variety of .NET in its new touch-centric mode? I will be astonished if it does not. Aside from other considerations, this is an essential unifying piece between the Windows Phone 7 developer platform and the Windows 8 developer platform, which from what we have seen have a similar user interface. For further evidence, try an internet search for “Jupiter” and “appx”.

Why isn’t Microsoft already shouting about this? A good question. Part of the answer is that Microsoft wants to get developers enthused about the forthcoming build conference in September, and is holding back information.

Another part of the answer is that Windows historically has kept .NET as a layer above the operating system, rather than as part of it. We saw this in Windows 7, where to take advantage of new features like jump lists or thumbnail toolbars, .NET developers had to use a supplementary Windows API Code Pack. The Windows team delivered only native code or COM APIs.

Admittedly, there are differences this time around. The Windows team is not just delivering native code APIs, but also an HTML and JavaScript API. This is a break with the past, hence the talk of a new platform.

When it comes to desktop applications, would not Silverlight or something .NET based be a better choice than HTML5? I can see both sides of this. On one side is all the effort Microsoft has invested in .NET and Silverlight over the past decade. As I’ve noted before, I see Silverlight as what client-side .NET should have been from the beginning, lightweight, secure, simple installation, but with support for C# and much of the .NET Framework which developers know so well.

On the other hand, I can see Microsoft wanting to tap into the wave of HTML5 development and to make it easy for web developers to build apps for Windows 8.

In the end, developers will most likely have the choice. That puts pressure on Microsoft’s developer division to provide strong tools for two different development models; but I think that is what we will get.

Is .NET itself under threat? As far as I am aware, Microsoft has no plan “B” in terms of web and application server technology, and its Azure cloud is largely a .NET platform though there are are efforts to support other things like PHP and Java. Further, this aspect of the Microsoft Platform is under Server and Tools which is 100% behind .NET as far as I can tell. We have also seen Silverlight crop up in the user interfaces for new server products like InTune and System Center. On the server then, there is no evidence for .NET doubts at Microsoft; and considering the trend towards cloud+device computing the server is now at the heart of most business application development.

That said, Microsoft has challenges in sustaining .NET momentum. It cannot afford to fail with Azure, yet other platforms such as Amazon EC2 have greater developer mindshare as cloud computing platforms. VMWare with its Java-based Spring framework is another key competitor. Microsoft was late to the server virtualisation party with Hyper-V. I also see declining market share for IIS versus Apache in Netcraft’s statistics, although these figures are distorted by millions of little-used domains that get shunted from one platform to another by major hosting providers.

Further, it seems to me that the fortunes of .NET on the server cannot be completely separated from what happens on the client. One of the attractions of .NET is the integration between client and server, with Visual Studio as the tool for both. Windows has lost momentum to Apple in mobile, in tablets, and in high-end laptops, making Windows-only clients less attractive. In that context, the decision of the Windows team to favour HTML5 over .NET is a blow, in that it seems to concede that the future client is cross-platform, though I expect there will be some sort of outcry when we see all the proprietary hooks Microsoft has implemented to get HTML5 apps integrated into Windows 8.

Therefore these really are difficult times for .NET. I do not count Microsoft out though; it still dominates business computing, and amongst consumers the Xbox may prove an important new platform as Tom Warren notes.

While I have reservations about Windows 8, it does demo nicely as a new touch-centric operating system and Microsoft surely has chances in the corporate world with new-style tablets that integrate with its system management tools and which run Microsoft Office.

Finally, the angst over the role of .NET in Windows 8 shows that many developers actually like the platform, including Visual Studio, the C# language, the .NET Framework, and XAML for building a rich user interface.

.net, microsoft, professional, software development

Full circle at Microsoft: from the early days of .NET to the new Chakra JavaScript engine

11 Comments

A discussion with a friend about the origins of Microsoft’s .NET runtime prompted a little research. How did it come about?

A quick search does not throw up any detailed accounts. Part of the problem is that much of it is internal Microsoft history, confidential at the time.

One strand, mentioned here, is Colusa’s OmniVM:

OmniVM was based on research carried out by Steven Lucco at Carnegie Mellon University. Steven co-founded Colusa Software in February 1994 in Berkeley, California. Omniware was released in August 1995. Colusa started working with Microsoft in February 1996. Microsoft acquired Colusa Software on March 12, 1996. Steven is currently a senior researcher at the Microsoft Bay Area Research Center.

OmniVM was appealing to Microsoft because Colusa had already created Visual Basic and C/C++ development environments for the VM. The VM was also claimed to be capable of running Java.

Microsoft took to calling the VM by the name of CVM, presumably for Colusa Virtual Machine. Or perhaps this is where the code name Cool came into being. Other names used at Microsoft include Universal Virtual Machine (UVM), and Intermediate Language (IL).

Microsoft’s Jason Zander, commenting to a story on this blog, does not mention OmniVM:

The CLR was actually built out of the COM+ team as an incubation starting in late 1996. At first we called it the "Component Object Runtime" or COR. That’s why several of the unmanaged DLL methods and environment variables in the CLR start with the Cor prefix.

Still, the timing pretty much matches. If Lucco came to Microsoft in 1996, he could have been part of an incubation project starting later that year.

In June 1999 Microsoft previewed the Common Executable Format for Windows CE:

A demonstration on Common Executable Format (CEF), a new compiler target within the Visual C++® development system for Windows CE, was also presented. This compiler enables cross-processor portability within a category of devices, such as Palm-size PCs or Handheld PCs. A single program executable under CEF is translated to the native code on either the host PC or the device, as desired. This capability eliminates the need for developers to recompile an application for every possible processor on a given Windows CE-based appliance before bringing it to market, thus enabling them to support every version of a device (Palm-size or Handheld PC) quickly and easily.

In 2000 I interviewed Bob Powell, then at Stingray, who told me this in relation to .NET:

There was an early version of the system for Windows CE called the Common Executable Format (CEF). The Pocket PC, which uses around seven different processor types, and which has many different versions of the operating system, is a deployment nightmare. This problem was addressed by the CEF, which was a test case. What is now in the IL is a more refined version of that.

Hmm, now that Windows is coming to ARM alongside x86, this sounds like it could be useful technology … though despite obvious similarities, I don’t think CEF was really an early version of the CLR. Maybe the teams communicated to some extent.

Now this is interesting and brings the story up to date. Lucco is still at Microsoft and apparently his team built Chakra, the new JavaScript engine introduced in Internet Explorer 9:

image

Steven E. Lucco is currently the chief architect for the Microsoft Browser Programmability and Tools (BPT) team. BPT builds the Internet Explorer’s Chakra Javascript script engine, as well as the Visual Studio tools for creating scalable, efficient Web client applications.

Right now, these are dark days for .NET, because Microsoft now seems to be positioning HTML and JavaScript as the new universal runtime.

It seems that the man who perhaps began the .NET Runtime is also at the centre of the technology that might overtake it.

Update: this post has prompted some discussion and the consensus so far is that the OmniVM acquisition probably had little to do with the technology that ended up as .NET. The one thing that is beyond doubt is that the COM team created the .NET CLR as Zander reported. I actually spoke to Zander at TechEd recently and we touched on his early days at Microsoft working with Scott Guthrie:

I was actually one of the original CLR developers. When Scott and I first started working together, he invented ASP.NET and my team invented the CLR.

The history is interesting and if the relevant people at Microsoft are willing to talk about it in more detail it is something I would love to write up – so if that is you, please get in touch!

.net, apple, google, internet, javascript, microsoft, mobile, professional, silverlight, software development, visual studio, Web, windows

Considering Windows 8 as an HTML platform

4 Comments

Amongst all the fuss about whether Microsoft is deprecating Silverlight or even client-side .NET, it is easy to lose sight of the other angle on this. What are the implications of Microsoft embracing HTML and JavaScript as a new first-class Windows development platform? Here’s the quote again:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface.

When Microsoft introduced IE9 with hardware-accelerated graphics, support for some key parts of HTML 5, and a new fast JavaScript engine, it was not only trying to recover ground in the browser wars. It also had in mind a new application runtime for Windows, for desktop as well as for web applications.

In order to achieve this, we can expect more hooks between the browser engine and the local operating system. There is potential security risk, but Microsoft of all companies will be sensitive to this and I would expect it to get the security right. The further implication is that some parts of a Windows HTML application will be Windows-specific. It is an “Embrace and extend” strategy, as I noted in this Register article back in September last year when former Silverlight product manager Scott Barnes broke the story of how the Windows team at Microsoft was favouring HTML and JavaScript above .NET.

The rationale for this is two-fold. First, I’m guessing that Microsoft thinks it will work better. Although .NET client apps are now commonplace, especially for custom business applications, problems like slow start-up and heavy memory requirements never really went away, though I would argue that in Silverlight they are almost eliminated.

Second, HTML and JavaScript is a universal programming platform. With the new model, any developer who can code a web page can also code a Windows app. Corporate VP Michael Angiulo said at Computex in Taipei:

Windows 8’s new application platform … is based on HTML 5, JavaScript and CSS, the most widely understood programming languages of all time. These languages form the backbone of the web, so that on day 1 when Windows 8 ships hundreds of millions of developers will already know how to build great apps for Windows 8.

These are both compelling arguments. Nevertheless, there are several reasons why making Windows an HTML platform might not be the instant hit that Microsoft will be hoping for. Here are a few:

  • Microsoft’s Visual Studio is .NET oriented. It does have a web design tool, Expression Web, which is OK but still falls short compared to Adobe Dreamweaver. Web designers tend to use Dreamweaver anyway, thanks to Mac compatibility and integration with other Adobe tools. Even Dreamweaver is not great as an application development tool, as opposed to a web design tool. Tooling is a problem, and it is fair to say that whatever goodies Microsoft comes up with in this area will likely be a step back compared to what it already has for C# or C++.
  • Standards are a mixed blessing if you are trying to sell an operating system. If Microsoft does such a good job of standards support that the same apps run with minor tweaks on an iPad and on Android, users may do just that. If Microsoft encumbers the standards with too many proprietary extensions, the universality of the platform is lost.
  • Windows plus HTML and JavaScript sounds a lot like Palm/HP WebOS, which has gained favourable reviews but has yet to take off in terms of sales. Otherwise, Palm would not have been taken over by HP.
  • The question of whether HTML and JavaScript will really take over app development is open. I certainly hear voices saying so. I interviewed Nitobi’s president André Charland, in charge of PhoneGap, and he makes a good case. On the other hand, App development today is still dominated by platform-specific development, Objective C for Apple iOS and Java on Dalvik, the Google Android virtual machine.
  • The standard in HTML/JavaScript app platforms is not Microsoft’s Internet Explorer, but WebKit, as used in iOS and in Google Android and Chrome. Microsoft did great work in standards support in IE9, but so far it has not stopped its browser share decline. Worldwide figures from StatCounter show Internet Explorer in continuing slow decline overall, and Chrome still growing and set to overtake Firefox in a year or so.

In other words, there is little evidence that embracing HTML and JavaScript as an app platform will ensure success for Windows 8.

That said, other factors count for more. Developers will go where their customers are, and if Microsoft turns out a version of Windows that wins substantial market share in the emerging tablet market as well as on traditional notebooks, the new platform will be a hit.

The risk though is that the market will continue to perceive Windows as an OS for desktop and laptop, and look to iOS or Android for mobile and touch devices. The dual personality of Windows 8 may count against it, if it means devices that are compromised by having to support both user interface models.

.net, development, internet, microsoft, silverlight, software development, visual studio, windows, windows 7

Microsoft refuses to comment as .NET developers fret about Windows 8

53 Comments

There is a long discussion over on the official Silverlight forum about Microsoft’s Windows 8 demo at D9 and what was said, and not said; and another over on Channel 9, Microsoft’s video-centric community site for developers.

At D9 Microsoft showed that Windows 8 has a dual personality. In one mode it has a touch-centric user interface which is an evolved version of what is on Windows Phone 7. In another mode, just a swipe away, it is the old Windows 7, plus whatever incremental improvements Microsoft may add. Let’s call it the Tiled mode and the Classic mode.

Pretty much everything that runs on Windows today will likely still run on Windows 8, in its Classic mode. However, the Tiled mode has a new development platform based on HTML and JavaScript, exploiting the rich features of HTML 5, and the fast JavaScript engine and hardware acceleration in the latest Internet Explorer.

Although D9 is not a developer event, Microsoft did talk specifically about this aspect. Here is the press release:

Today, we also talked a bit about how developers will build apps for the new system. Windows 8 apps use the power of HTML5, tapping into the native capabilities of Windows using standard JavaScript and HTML to deliver new kinds of experiences. These new Windows 8 apps are full-screen and touch-optimized, and they easily integrate with the capabilities of the new Windows user interface. There’s much more to the platform, capabilities and tools than we showed today.

Program Manager Jensen Harris says in the preview video:

We introduced a new platform based on standard web technologies

Microsoft made no mention of either Silverlight or .NET, even though Silverlight is used as the development platform in Windows Phone 7, from which Windows 8 Tiled mode draws its inspiration.

The fear of .NET developers is that Microsoft’s Windows team now regards not only Silverlight but also .NET on the client as a legacy technology. Everything will still run, but to take full advantage of Tiled mode you will need to use the new HTML and JavaScript model. Here are a couple of sample comments. This:

My biggest fears coming into Windows 8 was that, as a mostly WPF+.NET developer, was that they would shift everything to Silverlight and leave the FULL platform (can you write a Visual Studio in Silverlight? of course not, not designed for that) in the dust. To my utter shock, they did something much, much, much worse.

and this:

We are not Windows developers because we love Windows. We put up with Windows so we can use C#, F# and VS2010. I’ve considered changing the platform many times. What stops me each time is the goodness that keeps coming from devdiv. LINQ, Rx, TPL, async – these are the reasons I’m still on Windows.

Underlying the discussion is that developers have clients, and clients want applications that run on a platform with a future. Currently, Microsoft is promoting HTML and JavaScript as the future for Windows applications, putting every client-side .NET developer at a disadvantage in those pitches.

What is curious is that the developer tools division at Microsoft, part of Server and Tools, has continued to support and promote .NET; and in fact Microsoft is soon to deliver Visual Studio LightSwitch, a new edition of Visual Studio that generates only Silverlight applications. Microsoft is also using Silverlight for a number of its own web user interfaces, such as for Azure, System Center and Windows InTune, as noted here.

Now, I still expect that both Silverlight and native code, possibly with some new XAML-based tool, will be supported for Windows 8 Tiled mode. But Microsoft has not said so; and may remain silent until the Build conference in September according to .NET community manager Pete Brown:

You all saw a very small technology demo of Windows 8, and a brief press release. We’re all being quiet right now because we can’t comment on this. It’s not because we don’t care, aren’t listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I’m not aware of any plans) to say more right now. I’m very sorry that there’s nothing else to share at the moment. I know that answer is terrible, but it’s all that we can say right now. Seriously.

While this is clearly not Brown’s fault, this is poor developer communication and PR from Microsoft. The fact that .NET and Silverlight champion Scott Guthrie is moving to Windows Azure is no comfort.

The developer division, and in fact the whole of Server and Tools, has long been a bright spot at Microsoft and among its most consistent performers. The .NET story overall includes some bumps, but as a platform for business applications it has been a remarkable success. The C# language has evolved rapidly and effectively under the guidance of Technical Fellow Anders Hejlsberg. It would be bewildering if Microsoft were to turn its back on .NET, even if only on the client.

In fact, it is bewildering that Microsoft is being so careless with this critical part of its platform, even if this turns out to be more to do with communication than technical factors.

From the outside, it still looks as if Microsoft’s server and tools division is pulling one way, and the Windows team the other. If that is the case, it is destructive, and something CEO Steve Ballmer should address; though I imagine that Steven Sinofsky, the man who steered Windows 7 to launch so successfully, is a hard person to oppose even for the CEO.

Update: Journalist Mary Jo Foley has posted on what she “hears from my contacts” about Jupiter:

Jupiter is a user interface library for Windows and will allow developers to build immersive applications using a XAML-based approach with coming tools from Microsoft. Jupiter will allow users a choice of programming languages, namely, C#, Visual Basic and C++.

Jupiter, presuming her sources are accurate, is the managed code platform for the new Windows shell – “Tiled mode” or “Tailored Apps” or “Modern Shell – MoSH”; though if that is the case, I am not sure whether C++ in this context will compile to managed or unmanaged code. Since Silverlight is already a way to code using XAML, it is also not clear to me whether Jupiter is in effect a new Windows-only version of Silverlight, or yet another approach.

.net, microsoft, mono, open source, professional, silverlight, software development

Mono splits from Novell/Attachmate to form basis of new company

1 Comment

Mono is an open source implementation of .NET, formerly sponsored by Novell, and its future following Novell’s acquisition by Attachmate has been the subject of speculation.

Today Mono leader Miguel de Icaza has revealed new plans. In a blog post, he announces Xamarin, a new company focused on Mono. This company will build new commercial .NET tools for Apple iOS and Google Android, to enable .NET development on those platforms. Note that they will not be called MonoTouch and MonoDroid, the Novell offerings for this, but will be “source compatible”. I am sure there are brand and intellectual property ownership issues here; but de Icaza is no stranger to negotiating tricky issues of this kind, bearing in mind Mono’s relationship with Microsoft .NET. However I am not sure why the new company cannot acquire the existing brands, since it seems that Attachmate will no longer be able to support them.

The plans are not exactly new, but have been forced by Attachmate’s decision to lay off the entire Mono team:

We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers.

Apparently Xamarin has “angel funding” but is looking for more.

The advent of MonoTouch and MonoDroid has been good for Mono, since it gives the project a stronger business model than it had previously. These mobile platforms are hot, and the ability to code for them in C# is great for Microsoft Platform developers. This factor could enable Xamarin to succeed.

On the other hand, Novell’s name gave Mono enterprise credibility as well as the backing of a large company, and these it now lacks.

The curious thing is that Mono is valuable to Microsoft. The company seems at times to hate Mono, because it removes the need for Windows, and at other times to love it, because it extends the breadth of .NET to include Linux and now iOS and Android. Microsoft gave some sort of official status to Moonlight, the Mono implementation of Silverlight, though the company’s support for Moonlight has always seemed hesitant.

So can we expect now that the company which can afford $8.5 billion for Skype, could expend a few million in support of Xamarin? Or will it stand by and hope that Mono fades away?

I have no idea, though I would like to see both Mono and Xamarin succeed. It is no threat to Microsoft, but does take .NET to places that Microsoft will never support. Without Mono, C# is merely a language for programming Windows.

apple, gadgets

Google seeks to automate the home

Google made a bunch of announcements at its Google I/O keynote today. It showed off the next version of Android, called “Ice Cream Sandwich”; it announced its Music Beta, a service which looks a lot like Amazon’s Cloud Player, in which you upload your music collection to the cloud; it announced movie rentals.

The most intriguing announcements though were about how Android devices will be able to connect to other devices in future. The Open Accessory API lets manufacturers create devices which talk to Android over USB, and in future over Bluetooth, in a standard manner. The idea is that if you have an Android-compatible device – Google demoed an exercise bike – you can attach your smartphone and do some clever stuff, such as controlling it, analysing its data, or whatever is appropriate.

A related idea is called Android@Home. Google has developed a new lightweight wireless protocol which will let manufacturers create household devices that can communicate with Android:

We previewed an initiative called Android@Home, which allows Android apps to discover, connect and communicate with appliances and devices in your home.

image

The automated home is a grand concept where almost any device, from a light to a coffee maker to a fridge or a door becomes available to control and program. However, the examples Google gave were not exciting: playing a CD by waving it at a player, coding an alarm clock to turn the light on gradually. Big deal.

It is not really a new concept. Sun had ideas to develop Java as a universal runtime and language to automate the home. Microsoft has similar thoughts, maybe using the .NET Micro Framework. So far none of these efforts have come to much – will Google’s initiative be different?

Probably not; but there is something else going on here. I travel a bit, and it is now common to find an iPod dock in your hotel room. If you have an Ipod or iPhone you just plug in and go; if you have a non-Apple device, you are out of luck. That is a kind of pressure exerted on every guest, a hint that they might be better off with an Apple device.

Google wants to do the same for a variety of other devices, but with respect to Android. Here is a refrigerator, and by the way, if you have an Android device you can do this other clever stuff like, I don’t know, alerting you if the temperature goes too high, or letting you peek at the contents from your smartphone so you can see if you need to buy milk.

Same with the Open Accessory API. If Google can sign up enough manufacturers, it will be increasingly difficult for non-Android devices to compete.

That said, we did not hear much about Google TV at today’s keynote. Why? Because it has flopped; a reminder that not all Google’s efforts succeed.

.net, adobe, apple, flash, google, mono, professional, software development

Adobe AIR 2.6, MonoMac 1.0, cross-platform is not dead yet

It is a busy time for cross-platform toolkits. Adobe has released AIR 2.6, and reading the list of what’s new you would think it was mainly for mobile, since the notes focus on new features for Apple iOS, though AIR is also a runtime for Windows, Linux and desktop Mac. New features for iOS include GPU rendering – a form of hardware accelerated graphics – access to the camera, microphone, and camera roll, and embedded Webkit for apps that use web content. On Google Android, you can now debug on devices connected via USB.

There is also a new feature called “owned native windows” which lets you have a group of windows that remain together in the Z order – this lets you have things like floating toolbars without odd results where toolbars get hidden underneath other applications.

Asynchronous decoding of bitmaps is another new feature, allowing images to be processed in the background. This seems like a stopgap solution to overcome the lack of mullti-threading in AIR, but useful nonetheless.

Since the Flash runtime does not run on iOS, Adobe has a packager that compiles an AIR application into a native app. This is now called the AIR Developer Tool or ADT. You can use the ADT to target Windows, Linux or Android as well; however platforms other than iOS still need the AIR runtime installed.

Adobe is dropping support for the original iPhone and the iPhone 3G. iPhone 3GS or higher is needed.

If you want to build a cross-platform app but prefer .NET to Adobe’s Flash and ActionScript, the Mono folk have what you need. I’d guess that the Mono team has a small fraction of the resources of Adobe; but nevertheless it has delivered MonoTouch for iOS and is working on MonoDroid for Android. Just completed in its 1.0 version is MonoMac, for building Cocoa applications on Apple OSX. Mono is not fully cross-platform, since the GUI framework is different on the various platforms, but you do get to use C# throughout.

I am happy to agree that true native code is usually a better solution for any one platform; but at a time when the number of viable platforms is increasing the attraction of cross-platform has never been greater.

development, microsoft, professional

Microsoft’s code-first Entity Framework 4.1 nearly done

2 Comments

Microsoft has announced the release candidate of Entity Framework 4.1, the data persistence library for .NET, with a go-live licence. The final release to the web is expected in around one month’s time.

The big new feature is code-first, where you do not need to define a database schema or even a database model. You simply write classes that define objects you want to store, and the framework handles the work of defining the database for you.

Note that according to this article on MSDN:

The Entity Framework is Microsoft’s recommended data access technology for most types of applications.

Of course Microsoft has a long history of data access APIs and keeping up with the latest recommendation over the years has been a challenge. That said, the low-level ADO.NET data API has been in place since the first release of the .NET framework and has evolved rather than been replaced. There has been some confusion over LINQ to SQL versus Entity Framework; but note that LINQ (Language Integrated Query) works with Entity Framework as well.

So what is code-first? A good starting point is VP Scott Guthrie’s post from July last year, where he walks through a complete example using his Nerd Dinner theme. He writes classes to define two entities, Dinner and RSVP. Then he writes the following code:

image

Having defined this NerdDinners class inheriting from DbContext, he can go ahead and write a complete database application.

At this point there is still no database. In the simplest case though, you can just add a database connection to the project with the same name as the DbContext class – in this case, “NerdDinners”. The Entity Framework will use this connection, define a database schema for you, and save and retrieve objects accordingly.

The magic under the hood is an example of convention over configuration. That is, the framework will generate code and schema according to assumptions it makes based on the names used in your classes. For example, it picks up the field named DinnerID and makes it a primary key; and seeing a collection of RSVP objects called RSVPs in the Dinner class, the framework creates a relationship between the two generated tables. You can override the default behaviour with code mapping rules. There is also provision for updating the schema if you need to add or modify the fields, though this is a point of uncertainty in Guthrie’s post.

It looks fantastic; though there are a few caveats. One is that Microsoft tends to assume use of its own database managers, SQL Server or for simple cases, SQL Server CE. That said, there are drivers for other databases; for example devart has code-first drivers for Oracle, MySQL, PostgreSQL and SQLite.

Another point is that there is a trade-off when working at such a high level of abstraction. There is less code for you to write, but a large amount of generated code, which can make debugging or optimizing an application harder. This is a familiar trade-off though; and you could say that hand-rolled SQL is no different in principle from hand-rolled assembly code; you can get fantastic results but the amount of effort and skill required is greater, as is the risk of errors if you get it slightly wrong.

The Mono team has said that it does not intend to implement Entity Framework currently; there is a summary of work needed here. If you want to write .NET code that ports easily to Mono it is best avoided.

Are you using Entity Framework in new .NET projects? I would be interested to hear from .NET developers what approach you take to data persistence.

.net, development, internet, microsoft, professional, visual studio

What’s the story with IE9 and embedded Internet Explorer?

1 Comment

There is a certain amount of fuss over the fact that Apple’s latest mobile Safari does not give full performance when either embedded in another application, or pinned to the home screen.

It would help if Apple were more forthcoming on the issue; but in general you cannot assume that embedded browser components will behave the same way as the full browser, even when they share common libraries.

I did some quick experimentation with the released Internet Explorer 9 and the .NET Webbrowser control. First, I tried the SunSpider JavaScript benchmark. I had to use version 0.9 since the latest one gives an error in the Webbrowser control. No great surprise: the embedded version was substantially slower. I ran the tests separately, and for the .NET application I ran in release mode outside Visual Studio. IE9 completed in 314.6ms, the Webbrowser control in 578.2ms.

image

While that may seem a bad result for embedded IE, it could be much worse. Unfortunately I did not think to run this test before installing IE9, so I dual-booted into a Windows install that still has IE8 and ran the exact same application. At 6175ms it was more than ten times slower. It was slightly quicker in standalone IE8, but not by much.

image

Next I tried the Fish Tank demo, which tests hardware graphic acceleration.

image

There were two notable facts about my result here. First, the Webbrowser control reports itself as Internet Explorer 7. Second, the frame rate for the two instances was nearly identical. In practice it varied slightly and some of the time the standalone IE9 was fractionally faster, but still close. By way of reference, Apple’s Safari was around 10 times slower.

Update: embedded IE is slower on the Fish Tank than I first realised. 60fps is a kind of maximum for the demo. Embedded IE9 slows to 45fps with 50 fish, whereas full IE9 does not drop below 60fps until 500 fish on my system. It does makes the fans whir though!

My guess is that Microsoft is more concerned about compatibility than performance, when it comes to embedded IE. However, clearly there is significant benefit from IE9 even when embedded.

How can you get embedded IE not to report itself as IE7 and to use full standards mode by default? If it is like IE8, this can only be done on a per-application basis via setting a registry key. That is awkward for developers, who would prefer an API call to set this. I am not sure if there is any change for IE9.

.net, apple, google, microsoft, mobile, mono, open source, professional, silverlight, software development

Mono project: no plans for cross-platform WPF

Miguel de Icaza’s report from the Game Developer Conference is upbeat, rightly so in my view as usage of Mono is continuing to build, not only in game development with Unity, a development tool that uses Mono as its scripting engine, but also for mobile development for Apple’s iOS with Monotouch and for Android with Monodroid. These mobile toolkits also give Mono a stronger business model; many sites use Mono for serving ASP.NET applications on Linux, but without paying or contributing back to the project.

Mono is an open source implementation of C# and Microsoft’s .NET Framework.

That said, it is interesting that Mono is still struggling with an issue that has been a problem since its first days: how to implement Microsoft’s GUI (Graphical User Interface) framework on other platforms. Mono does have Gtk# for Windows, Mac and Linux, but this does not meet the goal of letting developers easily port their Visual Studio client projects to Mono. There is also an implementation of Windows.Forms, but de Icaza mentions that “our Windows.Forms is not actively developed.”

Apparently many tools vendors asked the Mono team at GDC when Windows Presentation Foundation (WPF) would be implemented for Mono. WPF is the current presentation framework for Microsoft.NET, though there is some uncertainty about where Microsoft intends to take it. I remember asking de Icaza about this back in 2003, when the WPF framework was first announced (then called Avalon); he said it was too complex and that he did not plan to implement it.

This is still the case:

We have no plans on building WPF. We just do not have the man power to build an implementation in any reasonable time-frame.

That said, Mono has implemented Silverlight, which is based on WPF, and there are some signs that Microsoft might merge WPF and Silverlight. What would the Mono team do then?

Miguel de Icaza says:

Silverlight runs on a sandbox, so you can not really P/Invoke into native libraries, or host DirectX/Win32 content inside of it.
There are other things missing, like menubar integration and things like that.

Of course, this is no longer true on Windows: Platform Invoke is coming in Silverlight 5.

Perhaps the Mono team will knuckle down and implement Silverlight with desktop integration, which would be good for cross-platform Silverlight and compatibility with Microsoft .NET.

Then again, it seems to me that Mono is increasingly divergent from Microsoft .NET, focusing on implementing C# in places that Microsoft does not touch, such as the mobile platforms from Apple and Google.

That is actually a sign of health; and you can understand why the Mono team may be reluctant to shadow Microsoft’s every move with Silverlight and WPF.