Category Archives: visual studio

development, java, microsoft, professional, software development, visual studio

Oxygene for Java released: develop for Android and Java runtime with Delphi language in Visual Studio

4 Comments

RemObjects has released Oxygene for Java, a new version of its Object Pascal compiler. Object Pascal is pretty much the Delphi language though with some additional features of its own. Previous versions target the .NET runtime, and a version of this is marketed by Embarcadero as Prism. The IDE for Oxygene is Microsoft’s Visual Studio. This new version targets both the Java Runtime and the Android Dalvik VM. The obvious target market is Delphi developers who now want to create apps for Android, or cross-platform Java applications.

I downloaded the trial and ran the supplied Hello World in the Android emulator … it works.

image

A few further notes from the RemObjects announcement. While only Visual Studio is supported initially, an Eclipse version is also in preparation. Oxygene directly consumes .JAR libraries so you can use both first and third-party libraries. There is also a tool called Oxidizer that lets you import Java language code, which will be converted to Oxygene Object Pascal.

A point to note is that Embarcadero has already announced that its cross-platform FireMonkey framework will support Android as well as Apple iOS. This means that developers who want to code for Android in the Delphi language will have two choices. It looks to me as if Oxygene will be more suitable if you want to stay close to the Android SDK, whereas FireMonkey has its own custom-drawn user interface widgets and effects and should come into its own if you want the same code to run on both iOS and Android.

Given that a skilled Delphi developer would probably learn Java fairly quickly, how much value is there in Oxygene for Java? I guess factors include how much more productive you can be in Oxygene and the value of sharing code across projects targeting different platforms, presuming that you do not want to run Java everywhere.

development, professional, software development, visual studio

What is the best programming language for a child progressing from Scratch?

8 Comments

Someone asked me what is the best programming language for a child to learn after starting (and having success) with Scratch.

Scratch is a visual programming language which actually runs on Smalltalk, though its users do not need to know this. Scratch 2.0 seems to be written in Adobe Flash so you can create and program projects in a web browser. As far as I can tell though, there is no obvious and natural progression from Scratch to a code-centric programming language.

I guess the first answer is not to move away from Scratch until you need to. You can do a lot with Scratch, as the many shared projects demonstrate.

Still, I agree that it makes sense to learn text-based programming before too long. What is the best one for a child to learn, not necessarily with computer science or a professional career in mind, but just to take the next step and create some cool games and applications?

I find myself leaning towards Microsoft’s C#. The reason is that there is a capable free version and  you can add XNA Game Studio for game development. C# is an excellent language and has some family resemblance to other languages including C, C++, Java and JavaScript, and Visual Studio is a strong IDE that is perhaps more approachable than say Eclipse or Netbeans.

Snags with C# are that Visual Studio only runs on Windows, the language is proprietary to Microsoft (though Mono is free and open source) and it is not ideal if you want to run on the Mac, or Google Android or Apple iPad.

That said, I could also make a case for Java, or JavaScript, or Python.

I would value suggestions though: what would you recommend to a teenager?

microsoft, mobile, nokia, professional, software development, visual studio

Developing for Windows Phone: what’s new

2 Comments

One thing that is easy to overlook in all the talk about Windows Phone, Nokia, and Microsoft’s prospects against iPhone and Android, is that the Windows Phone developer platform has substantially improved with the 7.1 SDK – the phone is 7.5 but the SDK is 7.1, just to confuse you.

Here are a few highlights from the list of what’s new:

Multitasking. Apps still do not continue to run when they do not have the focus. However, Microsoft has implemented several features to make it look as if they do. This includes background agents, background audio (another kind of agent), scheduled tasks, background file transfers, and fast application switching. Although apps do not execute in the background, they do stay in memory if free space allows, so that resume is near-instant.

Silverlight 4. The version of Silverlight implemented in Windows Phone is now Silverlight 4, though there are some differences between Silverlight on the desktop and Silverlight on the phone, including the fact that there is no Silverlight in the browser.

Apps that combine Silverlight and XNA. You can now render both XNA and Silverlight content in a single combined Windows Phone app.

image

Visual Basic and XNA. XNA was C# only in the initial release. No longer.

Better sensor support. You can now access the compass and gyroscope, and use a combined motion API.

Socket support. Use TCP and UDP socket protocols.

Network information. This is actually critical to creating well-behaved apps. New network information classes let you get network status and capabilities. You can also register for network availability change events.

Two-sided Live Tiles. Live Tiles in Windows Phone have two sides and flip automatically, effectively giving more space to show information.

Advertising SDK. Sign up to include ads from Microsoft Advertising in your app.

IE9 WebBrowser Control. You cannot embed your Silverlight app in the browser, but you can embed the WebBrowser control in your Silverlight app, now with IE9’s fast Javascript and HTML 5 features.

Local Database. A local database API is now included in Windows Phone. Sadly this is not Sqlite; I’m guessing it is a variant of SQL Server Compact Edition. You access and manipulate data with LINQ to SQL – no Entity Framework ORM (Object Relational Mapping) on the phone, though LINQ to SQL is also an ORM framework. There is no way other than LINQ to execute SQL locally.

New Launchers and Choosers. Launchers and Choosers let your app present picklists from data stored elsewhere in the phone. You can now choose an address, invite players to a game session, show a location on a map, or show map directions.

Read-only access to Contacts and Calendar.

Encrypted credential store. This enables you to store login details securely using a built-in API.

Programmatic access to the camera. This includes real-time access to the raw frames so you can create apps that use the camera.

Pictures and Search Extensibility. This lets your app interact with the Pictures hub and with the built-in search. Users who search Bing can launch your app from the results if there are matches.

New on-screen keyboards. There are now specialist keyboards for numbers and formulae.

Additional language support including East Asia. Overall there are 16 additional cultures available including font support.

Overall it adds up to a major update for developers. If you tried the first Windows Phone SDK and found too many annoyances, it might be worth a second look.

Is this the best mobile developer platform? I had this discussion today with Keith Varty, developer evangelist for Nokia. After rather enjoying a brief go with Xcode for iOS, I am not sure; there is no simple answer. It is certainly a candidate though: you get the excellent C# language, the mature Visual Studio IDE, and strong frameworks for both form-based and gaming applications. Then again you may miss those beautiful iOS controls.

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

Quick thoughts on Xcode and Objective C versus Microsoft’s tools

2 Comments

I have been trying out JetBrains’ AppCode which meant working in an Apple development environment for a time. I took the opportunity to implement my simple calculator app in iOS native code.

image

Objective C is a distinctive language with a mixed reputation, but I enjoy coding with it. I used Automatic Reference Counting (ARC), a feature introduced in Xcode 4.2 and OSX 10.7, iOS 5; ARC now also works with 10.6 and iOS 4. This means objects are automatically disposed, and I did not have to worry about memory management at all in my simple app. This is not a complete memory management solution (if there is such a thing) – if you use malloc you must use free – but it meant that the code in my app is not particularly verbose or complex compared to other languages. Apple’s libraries seem to favour plain English method names like StringByAppendingString which makes for readable code.

I was impressed by how easy it is to make an app that looks good, because the controls are beautifully designed. I understand the attraction of developing solely for Apple’s platform.

I also love the integrated source control in Xcode. You find yourself using a local Git repository almost without thinking about it. Microsoft could learn from that; no need for Team Foundation Server for a solo developer.

I did miss namespaces. In Objective C, if you want to remove the risk of name collision with a library, you have to use your own class prefix (and hope that nobody else picked the same one).

image

Interface Builder, the visual UI designer, is great but many developers do not use it, because coding the UI without it is more flexible. It is a shame that you have to make this choice, unlike IDE’s with “two way tools” that let you edit in code or visually and seamlessly keep the two in synch. I found myself constantly having to re-display windows like the Attributes Inspector though it is not too bad once you learn the keyboard shortcuts. The latest Interface Builder has a storyboard feature which lets you define several screens and link them. It looks useful, though when I played with this I found it difficult to follow all the linking lines the designer drew for me.

It is interesting to compare the Mac and iOS development platform with that for Windows. Microsoft promotes the idea of language choice, though most professional development is either C# or C++, whereas on Apple’s platform it is Objective C and Cocoa or you are on your own. Although Mac and Windows are of a similar age, Microsoft’s platform gives a GUI developer more choices: Win32, MFC, WTL, Windows Forms, Windows Presentation Foundation and Silverlight, and in Windows 8 the new WinRT.

I get the impression that Microsoft is envious of this single-minded approach and trying to bring it to Metro-style Windows 8, where you still have a choice of languages but really only one GUI framework.

That said, Visual Studio is an impressive tool and both C# and C++ have important features which are lacking in Objective C. I would judge that Visual Studio is the more productive tool overall, but Apple’s developer platform has its own attractions.

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

A simple example of async and await in C# 5

10 Comments

I have been playing with the Visual Studio 11 developer preview and exploring its asynchronous features, specifically the async and await keywords which are new to C# 5.0. These features have actually been available as a CTP (Community Tech Preview) since October 2010, but I had not found time to try it.

I like to keep examples as simple as possible. I have a Windows Forms application which has a long-running task to perform, and I do not want to lock the UI while it runs. Here is my long-running function:

 private int slowFunc(int a,int b)       
 {          
 System.Threading.Thread.Sleep(10000); 
 return a + b;
 }

Yes, it takes 10 seconds! I am going to click a button on a form, call the function, and show the result on a label control.

Now, here is how I might try to achieve the goal of not locking the UI using Visual Studio 2010 and C# 4.0:

 private void button1_Click(object sender, EventArgs e)
 {            
 this.button1.Enabled = false; //prevent re-entry 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2));
 this.label1.Text = "Result: " + someTask.Result.ToString(); //oops, blocks calling thread 
 this.button1.Enabled = true;       
 }

Oops, this did not work at all! The reason is that although I have gone to the trouble of creating a Task in order to run the slow function on a background thread, my work is undone when I call the Result property of the Task object – since this blocks the thread until the Task completes.

Here is how you can fix it in Visual Studio 2010 – remember, there is an easier way in C# 5.0 coming up soon:

 private void button1_Click(object sender, EventArgs e)        
 {
 this.button1.Enabled = false;          
 var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext(); //get UI thread context 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); //create and start the Task 
 someTask.ContinueWith(x =>     
   {                                          
   this.label1.Text = "Result: " + someTask.Result.ToString();   
   this.button1.Enabled = true;   
   }, uiScheduler  
  );        
 }

This one works. I click the button and the UI does not lock up at all; I can minimize the form, move it around the screen, and so on.

However, I have had to do some extra work. The ContinueWith method tells the Task to run some other code after the background thread has completed. By default this code will not run on the UI thread, which means it will raise an exception when it updates the UI, but you can pass in a TaskScheduler object so that it continues on the UI thread.

Now here is a look at the same problem using C# 5.0. The slowFunc is the same, so I will not retype it. Here is the code for the button click:

 private async void button1_Click(object sender, EventArgs e)
 {
 this.button1.Enabled = false; 
 var someTask = Task<int>.Factory.StartNew(() => slowFunc(1, 2)); 
 await someTask;  
 this.label1.Text = "Result: " + someTask.Result.ToString(); 
 this.button1.Enabled = true;
 }

Less code, same result, which is usually a good thing.

What is going on here though? First, the async modifier is added to the click event handler. This does not mean that the method runs asynchronously. It means that it contains code that will run asynchronously using await. As Eric Lippert explains, it tells the compiler to rewrite the method for you.

Second, there is the await keyword. I cannot improve on Lippert’s explanation so here it is:

The “await” operator … does not mean “this method now blocks the current thread until the asynchronous operation returns”. That would be making the asynchronous operation back into a synchronous operation, which is precisely what we are attempting to avoid. Rather, it means the opposite of that; it means “if the task we are awaiting has not yet completed then sign up the rest of this method as the continuation of that task, and then return to your caller immediately; the task will invoke the continuation when it completes.”

If you refer back to the Visual Studio 2010 examples, you will see that the code is very close to my first, non-working example. In other words,using await makes the code work in the way that intuitively I hoped that it might, without specifically called the ContinueWith method and messing around with the thread context as in the second example.

This is still concurrent programming though. One thing that C# 5.0 cannot prevent is an impatient user clicking several times on the button when the result does not appear immediately, so in all the examples I have disabled the button while the background thread runs.

.net, microsoft, mobile, visual studio, windows, windows 7

Building Windows – when Microsoft shows its hand

I’m in Anaheim, California on the eve of Microsoft’s BUILD conference. I have heard the phrase “wait until BUILD” so many times from Microsoft over the last few months that it has given this conference a special flavour. After Wednesday, the company will have to think of another way to avoid awkward questions like what is happening to Silverlight.

This is the latest chapter in the progression of Windows, server client and mobile. In particular, I will be trying to understand Microsoft’s software development platform. Whatever it looks like, it will be diverse, and include native code, HTML and JavaScript, .NET code including Silverlight, and perhaps some new hybrid. What will be the pros and cons of each approach, how do developers create apps that span desktop, tablet and mobile, and how will the delivery model change in the app store era?

Interesting questions; but the other theme is about how effectively Microsoft will compete versus its competition as the importance of desktop Windows shrinks. Cloud, mobile and tablet are the themes here, and after many mis-steps time is running out.

Not much to add except “watch this space” over the next few days; though I would be interested in any specific comments or questions on Microsoft’s strategy.

microsoft, silverlight, software development, visual studio

Windows Phone 7 apps, stats and future

2 Comments

Justin Angel, a former Microsoft employee who worked on Silverlight, has posted his analysis of the 24,505 apps he found in the Windows Phone 7 marketplace, exploiting a loophole that lets you get the download links. A few highlights:

  • 97% of the apps are not obfuscated, meaning that it is trivial (with easily available tools) to decompile the source.
  • 90% are Silverlight vs 10% XNA. This is not so much an indicator of the popularity of the two frameworks, but more an indicator of how many apps are graphic-rich games rather than some other kind of utility. Of course if you are making a very simple app, Silverlight is easier than XNA, so that may be a factor too.
  • 99% are C# vs 1% Visual Basic and a smattering of F#. A fascinating stat that makes me wonder what is the future of Visual Basic.

There are more interesting stats about libraries and components used, for which I refer you to the original post.

Does it matter? Well, Windows Phone 7 has not been a big success so far, though the reasons for that are not so much the quality of the OS or the ease of developing apps, but rather its low profile at retail and the fact that most operators and manufacturers don’t really need it: Apple and Android between them pretty much have the market.

That said, there are a few reasons why Windows Phone or some evolution of it may yet be significant. Nokia is betting on it, and while Nokia is undoubtedly in difficulties, this must work in Microsoft’s favour. Further, fear uncertainty and doubt surrounding Android patent and copyright issues may persuade some industry players to give Windows Phone another look.

Perhaps more significantly, when Microsoft unveils its developer strategy at the BUILD conference next week, it is likely that the application model in Windows Phone, or some evolution of it, will integrate with what is planned for Windows 8. NVIDIA is already talking about how Windows 8 will run Windows Phone apps.

For these reasons I believe there is at least a glimmer of hope for Microsoft in the mobile world; certainly the developer story to be officially told next week will be an interesting one.

.net, development, professional, software development, visual studio

Continuous Integration vs Continuous Delivery vs Continuous Deployment: what is the difference?

I am reading the excellent book Continuous Delivery by Jez Humble and David Farley. But what is Continuous Delivery and how does it differ from the other “continuous” development methodologies?

It helps to understand that all these methodologies spring from the Agile software development movement, and the expression Continuous Delivery is a quote from the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Now, the starting assumption is that most software projects integrate a number of smaller projects, whether from third-parties or from team members. Since these pieces are developed to some extent independently there is a risk that changes made to one piece will require modifications to another piece; hence according to Humble and Farley:

Most software developed by large teams spends a significant proportion of its development time in an unusable state.

The business of getting all the parts to work together is called integration, and if this involves serious work you need to have an integration phase where this is the sole objective. This is a bad idea for all sorts of reasons, slowing development and preventing proper testing other than at the end of these integration phases.

The solution is called Continuous Integration (CI). You have a frequent automated build that assembles all the pieces from all the teams into a working application. If the build fails, or if automated tests run against the build fail, then this is a bug that should be fixed immediately, not later in some separate phase of development.

Tools for CI include Cruise Control, Hudson, TeamCity and others; .NET developers can also configure Visual Studio Team Foundation Server for CI.

The problem with CI alone is that the development environment is not the same as the production environment. What if the CI build works and tests pass, but once deployed the application breaks or performs badly? Perhaps the development environment runs a multi-tier application with all the tiers on a single box, but when deployed onto actual multiple machines or VMs, something goes wrong. Permission problems are another common source of errors.

Continuous Delivery means that you not only build the software, but also deploy it frequently. This usually means provisioning servers, which you can automate using a tool like Puppet for Unix-like servers, or with Virtual Lab Management in a Visual Studio environment. Automation is pretty much essential for this to work. The more closely the test environment matches the production environment, the better.

Generally though, Continuous Delivery means deployment to a test environment. What about taking the next step, and deploying continuously to production? That is the methodology called Continuous Deployment. It sounds risky; but if you have a very extensive and thorough set of automated tests, then the risks are mitigated, especially as the extent of the changes in any one deployment is reduced.

Other suggestions for reducing risk include deploying to a small subset of users first, called “canary testing”; and making rollback easy.

That said, to judge by the Humble/Farley book the distinction between Continuous Delivery and Continuous Deployment is just a little blurred. The authors acknowledge that continuous deployment into production is not always a good idea. They also imply that Continuous Deployment might mean only that your application is always ready and easy to deploy into production, not that you necessarily deploy it constantly:

Your implementation should make it possible to deploy any version of your application that has made it past the automated tests into any of your environments at the push of a button, given the correct credentials.

Compliance and security are also factors that may rightly make it impossible to automate deployment to production completely.

Client-installed applications present some special difficulties which Humble and Farley discuss.

In summary then:

Continuous integration: your application always builds and passes its tests, including all the pieces from different sub-teams.

Continuous delivery: your application always builds and deploys to a test environment and passes its tests.

Continuous deployment: your application is always ready to deploy to production through a largely automated process.

Update: I received an email from Martin Fowler about this post. He refers to Jez Humble’s post on Continuous Delivery vs Continous Deployment and adds:

– I would use your definition of Continuous Deployment for Continuous Delivery

– I would change the definition of Continuous Deployment to say something like "every good build is released to production"

However, I clarified with him that if you building for a test environment but are confident that any build that passes would be OK to deploy to production, then you are still doing Continuous Delivery. In the end, while I am sure you should use Fowler and Humble’s definitions rather than mine, it seems to me a fine distinction and that if you are doing Continuous Delivery properly then the transition to Continuous Deployment is largely a matter of policy.

.net, microsoft, software development, visual studio

Real-world Microsoft Team Foundation Server: Not very good, says ThoughtWorks

12 Comments

I spoke to Sam Newman, who is European Continuous Delivery Practice Lead at ThoughtWorks, a software development company. Needless to say, we talked extensively about Continuous Delivery and I will be reporting on this separately; but I was also interested in his comments on Microsoft’s Team Foundation Server (TFS).  He told me that ThoughtWorks teams often end up working with it at their .NET clients, but it is problematic. In one case, he said, 6% of productive time was absorbed dealing with TFS.

What was the problem, performance, bugs, features lacking?

When we’ve looked at the problems we’ve had, a lot of it unfortunately comes down to the version control system. It’s not very good. It’s slow, you can’t do rollbacks, sometimes things go missing, you get locks. When we talked about 6% of time, they were things like waiting for a solution to expand in Visual Studio. A lot of those issues are in the version control system.

A frustration is that you cannot use TFS with any version control system other than its own.

Every other build server in the world, from Anthill to Go to Cruise Control to Hudson, you can put in at least 10 version control systems. In TFS they are all coupled. So you can’t take the version control and point it at Subversion. That might resolve a lot of the issues.

Why is TFS so widely used? It is because it comes in the box, says Newman.

I can’t think of a single client that wanted a tool, went out into the marketplace, and selected TFS because it is the right tool for them. Most clients use TFS because it comes with their Enterprise MSDN licence.

I have tried TFS myself and found it pretty good; but then I am just testing it on small projects as a solo developer, so it is hard for me to replicate the experience of a real-world team. You would have thought that performance issues, such as waiting ages for a solution to expand in Visual Studio, could be solved by tracing the reason for the delay; but apparently this is not easy.

This is anecdotal evidence, and of course there may be plenty of TFS installations out there that work very well; I would be interested in hearing of counter examples. I am also not sure to what extent the problems apply to all versions of TFS, or whether there is improvement in TFS 2010.

Newman recognizes that anecdotal evidence is not much use: he says ThoughtWorks is trying to collect some solid data that can be used both to discuss with clients making version control and build system choices, and with Microsoft.

Performance is a feature, and makes a large contribution to user satisfaction. The first release of Outlook 2007 was extraordinarily slow in some setups, and I remember the pain of clicking on a folder and then waiting tapping my fingers while it thought about expanding. It sounds like some TFS users are having a similar experience but in Visual Studio.

.net, development, microsoft, mobile, mono, open source, professional, software development, visual studio, web authoring

The strategy behind Mono has shifted: ten years of open source .NET

Yesterday, SUSE and Xamarin announced, in effect, the transfer of all things Mono to Xamarin.

The agreement grants Xamarin a broad, perpetual license to all intellectual property covering Mono, MonoTouch, Mono for Android and Mono Tools for Visual Studio. Xamarin will also provide technical support to SUSE customers using Mono-based products, and assume stewardship of the Mono open source community project.

Xamarin is a startup formed by Mono founder Miguel de Icaza following the acquisition of Novell and SUSE by Attachmate, which ceased Mono development.

Attachmate acquired Novell in November 2010. Mono has been plucked from the abyss with impressive speed.

That said, the strategy behind Mono has shifted. Mono exists because de Icaza liked what Microsoft announced back in 2000 when it introduced C# and the .NET Framework. Microsoft made a show of standardizing the .NET CLI (Common Language Infrastructure), which made PR sense at the time since there was controversy over Sun’s ownership of Java, though nobody really believed that Microsoft knew how to steward an open source development platform or indeed believed that it was really serious about it. History largely justifies that scepticism; but de Icaza called Microsoft’s bluff and forged ahead with Mono, implementing not only the CLI and C# but most of the .NET Framework as well.

The goal of Mono, as I recall, was to bring the benefits of C# and .NET to Linux developers, and to enable developers to move applications freely between Windows and Linux. Apple OS X was also on the radar, though it took longer to become much use. Recalling Mono’s early days, de Icaza said:

Mono to me is a means to an end: a technology to help Linux succeed on the desktop.

Mono worked remarkably well from quite early on, but never quite well enough to persuade mainstream developers it was a sensible choice for applications that would otherwise have run on Windows. It did emerge as a viable and productive toolset and platform for Linux and a number of Mono applications became popular, including Beagle search, Tomboy notes, and F-Spot photo management. Some ASP.NET applications run on Mono; I have one on this site. Another Mono success was its use as the scripting engine in Unity, a game development platform.

A big problem for Mono though was the lack of a business model. There was support and servicing of course, which must have generated some revenue for Novell, but most Mono use is free. Novell possibly had in mind that Mono could be significant as an application server, but it has never become a really trusted platform in the Enterprise. For example, as Alan Radding (Dancing Dinosaur) notes:

DancingDinosaur has not found any SUSE on z user that has successfully implemented .NET apps on the mainframe. A few have tried but reported that Mono on z wasn’t ready for prime time.

Even among the free software and open source community, Mono was hampered by suspicion of Microsoft. If Mono became successful enough to threaten Microsoft, would lawyers appear? Given the way Microsoft is currently behaving with Android, filing legal actions and signing up licensees, those fears might not be unwarranted.

So what is Mono today? The answer is that Mono is now primarily a mobile platform. The Xamarin home page makes this clear, as well as making it apparent that the Mono team has discovered the value of a business model:

image

Xamarin is tapping into two real business needs. One is the need for a cross-platform mobile development platform that works. The second is a way for Windows developers to use their existing C# skills for mobile development, given that they might not be happy with the tiny market share currently achieved by Windows Phone 7.

When I had a quick try with Monotouch I was impressed, and I would like to spend some more time with it and with Mono for Android.

Mono has touch competition though. In particular, PhoneGap, Appcelerator’s Titanium, and Adobe AIR. I was interested to see that Adobe is coming up with a packager for AIR on Android, which may significantly improve it as a cross-platform mobile toolkit.

Still, Xamarin is small and nimble and I expect it to succeed. It has also has Visual Studio integration, which is an advantage. One of the pieces Xamarin has now licensed from SUSE is Mono for Visual Studio.

The downside of these latest developments is that if you depend on Mono for the desktop or for ASP.NET, you may find these parts of the Mono project getting little attention from the new company. But Mobile is all that matters now, right?

I write this on July 19 2011. According to Wikipedia:

Recognizing that their small team could not expect to build and support a full product, they launched the Mono open source project, on July 19, 2001 at the O’Reilly conference.

Well, if there was a launch there it was low-key. It is not mentioned in this report. But de Icaza does recall:

We planned the announcement to come by July 19th 2001, so we could announce this at the O’Reilly conference, as Tim O’Reilly had been very supportive of this effort, and had offered his help since the early stages, when it was still a very young idea. When we announced the project launch we had our team in place, and we were shipping our metadata framework and our C# compiler as well as a few initial classes So officially the Mono project was launched on that date, but it had been brewing for a very long time.

Happy Anniversary!