Release Candidates and Preview Updates
We have been busy preparing some upgrades to our developer tools and today we published our release candidates into Xamarin’s Beta Channels. We also released some major updates for our products on the Alpha channel, as those are not quite ready to use.
We have two themes at work: improving the performance and quality of our products and this is what dominates the Release Candidates in this set of updates and we are adding new features to our products based on how you guys are using them and that is what we are publishing on the Alpha channels.
Here is what we have in store:
Release Candidate: MonoDevelop 2.8.8
MonoDevelop has been optimised to improve the speed of several common operations such as opening solutions and files (both at startup and at runtime).
The updater has been improved to handle failures more gracefully and several minor issues with multi-monitor configurations have been resolved.
The debugging engine contains many improvements to stability and usability. Generics are handled better and viewing the value of large strings (several megabytes in size) will no longer slow down the debugging session.
Switching between the Blame view, Changes view and Log view has been made significantly more reliable and faster. MonoDevelop now integrates with the MacOS keychain so it can store and retrieve credentials for both https and ssh based authentication methods.
Enhanced Git Support
We have upgraded NGit (the .NET port of JGit) to the latest JGit version and improved upon it. Support for the git version control system has been vastly improved with many performance enhancements and many bugs fixed. Common operations such as getting the status of a file, calculating the ‘blame’ view and viewing the commit history for a file have all been significantly improved.
The syncing process has been improved to be more robust against errors and provide better developer feedback for some common issues, such as a missing[Register] attribute for types being synced to Xcode.Support for syncing localized resources to and from Xcode (lproj directoryes) has been added for easy custom localizations.
Improved progress notifications when deploying an application to device or simulator.
Release Candidate: MonoTouch 5.2.6
- MonoTouch.Dialog now ships with JsonElement to create user interfaces from Json data
- Better error reporting from the [LinkWith] attribute, it now issues warnings/errors if no matching architecture is available on the embedded package. (3597)
- Added .NET-style APIs to create NSHttpCookies instead of requiring NSDictionary APIs (3603)
- Some ViewControlles now implement the UIAppearance protocol, this was previously missing: ABPeoplePickerNavigationController, EKEventEditViewController, GKLeaderboardViewController, GKAchievementViewController, GKFriendRequestComposeViewController, GKTurnBasedMatchmakerViewController, MFMailComposeViewController and MFMessageComposeViewController (3226)
- 3189, 3489: Fix (again) references to modal views
- 3357: Stack traces contain numbers, even when not running in debug mode
- 3579: Can’t set CAShapeLayer Color and Path properties to null
- Fix API signature for ArchiveRootObjectToFile
- Improved our Xcode 4.3 support without the “Command-Line Tools”
- Link all default type converters when System.Component.TypeDescriptor is used.
Release Candidate: Mono 2.10.9
This new build of Mono 2.10.9 contains the same Mono runtime that we shipped before, but we continue to upgrade the Gtk+ stack with the various fixes that are being developed by Lanedo for MonoDevelop users on Mac.
The history of Mono 2.10.9 release candidates includes the following major fixes to the Gtk+ stack:
- build #1 Feb 7: first build with Lanedo fixes
- build #2 Feb 8: fixes Pango speed regression
- build #3 Feb 9: fixes previous Pango fix
- build #4 Feb 14: fixed #3424, -O2 compilation caused problems
- build #5 Feb 24: new Gtk, Pango
- build #6 Feb 29: fixed #2777, Child Task incorrect behavior
Technology Preview: MonoDevelop 2.9.2
This release of MonoDevelop contains all of the features from our Release Candidate but contains a completely new code-completion engine written.
This is a joint collaboration between the SharpDevelop and MonoDevelop teams. We are now both using NRefactory 5, powered by Mono’s C# Compiler as a Service, to achieve this.
We are looking for users to exercise the new code completion engine and tell us what areas can be further improved.
Technology Preview: MonoTouch 5.3.0
Cross-thread UI Checks
Many developers creating multi-threaded applications and using Grand Central Dispatch have historically called methods on the UI thread from a background thread accidentally corrupting the state of UIKit. This leads to strange behavior in the best case and to hard to track down crashes in the worst case.
MonoTouch will now check calls made to UIKit APIs that are not thread safe are only performed from the main thread. This will help developer identify parts of their code that should be using BeginInvokeOnMainThread.
The check is only performed on debug builds and is stripped out from release binaries. This behavior can be changed by using the –force-thread-check and –disable-thread-check to mtouch.
You can alter the behavior at runtime for debug builds by setting the UIApplication.CheckForIllegalCrossThreadCalls which defaults to true.
Parameters to Applications
You can now pass parameters to applications by adding the parameters in the Run/General section in the project preferences as well as setting environment variables.
You can use this to set environment variables in your application as well, in particular you can use this to control the behavior of the Mono runtime by using the options documented in the mono manual page.
This release comes with a complete binding to the CoreMIDI APIs on iOS and MacOS X.
The API now allows a delegate that will be invoked upon a match to be passed directly in the constructor instead of using the AddTarget method later or using selectors/objects.
The linker is now able to rewrite the IL of the bindings libraries, including its own, to remove extraneous checks for Runtime.Arch and calls to UIApplication.EnsureUIThread (see Cross-thread UI checks) [ as well as the IsNewRefcountEnabled and MarkDirty methods.
There is now a new OpenTK-1.0 assembly which provides the OpenTK 1.0 API. The reason for this change is that the OpenTK 1.0 API is not backwards compatible with our existing OpenTK.dll. In the future we will keep OpenTK.dll for backwards compatibility, while OpenTK-1.0.dll should be used in new projects.
See the API differences document for details on the actual changes.
Update: Sebastien Pouliot has blogged about the internal updates that we did to our linker to bring you new features, but keep your executables slim. See his Linker vs Bindings and Linker vs UI Thread Checks posts.