Miguel becomes an American..! 

Miguel becomes an American

Posted by Andrew Tierney Thursday, January 15, 2015 10:01:00 PM


The entire team at Xamarin has been working hard on this release for over a year to bring you the Unified API with 64-bit support. Please note that Apple announced two important deadlines for when your app must include 64-bit support:

  • February 1st: New iOS app submissions
  • June 1st: All new and existing iOS app submissions or updates

Updated Components and Libraries

We are rolling out updates for official Xamarin Components and NuGet packages with support for the Unified API. If you are a library creator and have not updated your component or NuGet package yet, please do so as soon as possible so that app publishers have time to migrate and test apps before Apple’s February 1st deadline.  Check out Matt Ward’s blog post on how to update your library for the new Unified API.

Get Started Today

You can begin migrating your apps today by using our built in migration assistant for both Xamarin Studio and Visual Studio. If you need more guidance on migrating your app to the Unified API, make sure to read through our full guide on our documentation site, or check out this Xamarin University Lightning Lecture.

Live Webinar

If you’d like to see migration in action and get your Unified API questions answered, join Xamarin Developer Evangelist Mike James for a live webinar thisThursday, January 15th at 11am EST.

Register Now

Posted by Andrew Tierney Tuesday, January 13, 2015 11:30:00 PM

David I Facebook posts.. 

If your interested in Tech news, you should take a look at David I's facebook page. (click here)

A sample of his content includes:

Mobile Push Notifications without a BaaS

Delphi, C++Builder and RAD Studio XE7 include support for mobile push (remote) notifications via a Parse and Kinvey BaaS providers. This makes it really easy to send push notifications to your user...



Top 20 Automated Home Posts of the Year 2014 | Automated Home

2014 really was the year you went bonkers for heating controls. There are no less than 7 posts in our top 20 based on these technologies and our Heating Forums...
Posted by Andrew Tierney Saturday, January 10, 2015 5:03:00 PM

Xamarin's New Year Post.. 

Posted by Andrew Tierney Saturday, January 10, 2015 9:45:00 AM

Welcome to 2015 

Lots of exciting things planned for 2015.. Stay tuned..

Posted by Andrew Tierney Thursday, January 1, 2015 7:40:00 PM

Merry Christmas....!!! 

Merry Christmas

Merry Christmas..!!!!

Have a safe and merry Christmas and a Happy New Year..!!!


Posted by Andrew Tierney Thursday, December 25, 2014 11:27:00 AM

Microsoft Open Sources .NET and Mono 


by Miguel de Icaza

Today, Scott Guthrie announced that Microsoft is open sourcing .NET. This is a momentous occasion, and one that I have advocated for many years.

.NET is being open sourced under the MIT license. Not only is the code being released under this very permissive license, but Microsoft is providing a patent promise to ensure that .NET will get the adoption it deserves.

The code is being hosted at the .NET Foundation's github repository.

This patent promise addresses the historical concerns that the open source, Unix and free software communities have raised over the years.

.NET Components

There are three components being open sourced: the .NET Framework Libraries, .NET Core Framework Libraries and the RyuJit VM. More details below.

.NET Framework Class Libraries

These are the class libraries that power the .NET framework as it ships on windows. The ones that Mono has historically implemented in an open source fashion.

The code is available today from http://github.com/Microsoft/referencesource. Mono will be able to use as much a it wants from this project.

We have a project underway that already does this. We are replacing chunks of Mono code that was either incomplete, buggy, or not as fully featured as it should be with Microsoft's code.

We will be checking the code into github.com/mono by the end of the week (I am currently in NY celebrating :-)

Microsoft has stated that they do not currently plan on taking patches back or engaging into a full open source community style development of this code base, as the requirements for backwards compatibility on Windows are very high.

.NET Core

The .NET Core is a redesigned version of .NET that is based on the simplified version of the class libraries as well as a design that allows for .NET to be incorporated into applications.

Those of you familiar with the PCL 2.0 contract assemblies have a good idea of what these assemblies will look like.

This effort is being hosted at https://github.com/dotnet/corefx and is an effort where Microsoft will fully engage with the community to evolve, develop and improve the class libraries.

Today, they released the first few components to github; the plan is for the rest of the redesigned frameworks to be checked in here in the next few months.

Xamarin and the Mono project will be contributing to the efforts to bring .NET to Mac, Unix, Linux and other platforms. We will do this as Microsoft open sources more pieces of .NET Core, including RyuJIT.

Next Steps

Like we did in the past with .NET code that Microsoft open sourced, and like we did with Roslyn, we are going to be integrating this code into Mono and Xamarin's products.

Later this week, expect updated versions of the Mono project roadmap and a list of tasks that need to be completed to integrate the Microsoft .NET Framework code into Mono.

Longer term, we will make the Mono virtual machine support the new .NET Core deployment model as well as the new VM/class library interface

We are going to be moving the .NET Core discussions over to the .NET Foundation Forums.

With the Mono project, we have spent 14 years working on open source .NET. Having Microsoft release .NET and issue a patent covenant will ensure that we can all cooperate and build a more vibrant, richer, and larger .NET community.


Posted by Andrew Tierney Thursday, November 13, 2014 8:41:00 AM



Earlier this year, both Epic Games and CryTech made their Unreal Engine and CryEngine available under an affordable subscription model. These are both very sophisticated game engines that power some high end and popular games.

We had previously helped Unity bring Mono as the scripting language used in their engine and we now had a chance to do this over again.

Today I am happy to introduce Mono for Unreal Engine.

This is a project that allows Unreal Engine users to build their game code in C# or F#.

This is a taste of what you get out of the box:

  • Create game projects purely in C#
  • Add C# to an existing project that uses C++ or Blueprints.
  • Access any API surfaced by Blueprint to C++, and easily surface C# classes to Blueprint.
  • Quick iteration: we fully support UnrealEngine's hot reloading, with the added twist that we support it from C#. This means that you hit "Build" in your IDE and the code is automatically reloaded into the editor (with live updates!)
  • Complete support for the .NET 4.5/Mobile Profile API. This means, all the APIs you love are available for you to use.
  • Async-based programming: we have added special game schedulers that allow you to use C# async naturally in any of your game logic. Beautiful and transparent.
  • Comprehensive API coverage of the Unreal Engine Blueprint API.

This is not a supported product by Xamarin. It is currently delivered as a source code package with patches that must be applied to a precise version of Unreal Engine before you can use it. If you want to use higher versions, or lower versions, you will likely need to adjust the patches on your own.

We have set up a mailing list that you can use to join the conversation about this project.

Visit the site for Mono for Unreal Engine to learn more.

Miguel de Icaza (miguel) 

Posted by Andrew Tierney Friday, October 24, 2014 8:55:00 AM

Mono 3.10.0 Released 

Mono 3.10.0 is a bugfix release with a few features.


  • Implemented System.IO.Compression.FileSystem.
  • Uri now implements the .NET 4.5 behavior, it can be reverted to the old behavior in the same way by setting the System.Uri::s_IriParsing static field to false.


  • Remove unnecessary locking from core metadata parsing functions.
  • Avoid cache thrashing of locals array when looping over enumerator.

Known Issues

The OSX package packages an invalid libgdiplus library that affects users of System.Drawing that requires it to work.

This specially affects Xamarin.Mac users that fit the following criteria:

  • Uses Xamarin.Mac Classic (Unified is unaffected).
  • Uses the subsets of System.Drawing that use libgdiplus.dylib internally
  • - System.Drawing.RectangleF, PointF, Colors are unaffected
  • - System.Drawing.Bitmap, and font for example are affected

The symptom of the problemw is your application failing with: “System.TypeInitializationException: An exception was thrown by the type initializer for System.Drawing.GDIPlus —> System.Exception: GdiplusStartup”

Bug fixes


  • Fix support for unaligned offsets in the store_membase_imm opcodes. Fixes #23267.
  • Fix the lookup of nested types which have a namespace. Fixes #21653.
  • Increase some opcode sizes. Fixes #23026.
  • Always pass the imt arg to interface calls in gsharedvt methods. Fixes #22624.
  • Store the epilog length in MonoArchEHJitInfo instead of encoding it in jinfo->unwind_desc, since the latter can overflow for methods with large epilogs. Fixes #22685.
  • Add a mono_thread_detach_if_exiting () public api function which can be called by embedding code to detach the runtime if the code is running from a pthread dtor. Fixes #21164.
  • Fix yet another native types problem. Fixes #22053.
  • Fix the leaking of mach ports introduced by 98bbf8512aec0fa01b4426583280f6d231d22187. Fixes #22068.
  • Add support for constrained calls with vtype return types in gsharedvt code. Fixes #22109.
  • Fix the PLATFORM_GNU check so it works with gnueabi etc. as well. Fixes #21520.
  • Don’t make runtime invoke signatures generic. Fixes #21973.
  • Allow v8..v15 in unwind info on arm64. Fixes part of #21615.
  • Fix Process.PrivateMemorySize64 etc. on ios. Fixes #21882.
  • Fix enum->int casts in gsharedvt code. Fixes #21893.
  • Don’t assert when loading a generic methodspec with 0 arity. Fixes #19097.
  • Avoid asserting when a cattr cannot be loaded. Fixes #21653.
  • Avoid making generic calls from gsharedvt methods normally, go through the rgctx infrastructure instead. Fixes #21677.

Class Libraries

  • Fix Uri UserInfo parsing. Fixes 23246.
  • Update RequestMessage.RequestUri.AbsoluteUri after redirect. Fixes #22383.
  • Fixes XContainer attempt to create a XNode from a null value. Fixes #20151.
  • Changed XObject OnChanged and OnChanging to use Owner. When XObject.Owner is not a XElement XObject.Parent returns null and the owner would not be notified of changing and changed events. Fixes #18772.
  • Process XslLiteralElements with only child attributes as empty ones. Fixes #14751.
  • ‘finally’ protect ClientRuntimeChannel.Begin/EndProcess(). Fixes #22179.
  • WebClient.OpenWrite() must get the response on close. Fixes #10163.
  • Fix WebClient.UploadValuesTaskAsync(); Fixes #20359.
  • Improve System.Security.Claims. Fixes #22282.
  • Fixed serialization of XmlNode field with attribute XmlAnyElement. Fixes #3211.
  • Handle String::Format with escaped closing }. Fixes #22114
  • Add a missing check to TypeBuilder.CreateType (). Fixes #22059.
  • Xml Serialization of Base class w/o a parameterless constructor. Removed validation code that did not allowed serialization of base classes without a parameterless constructor. Fixes #6913.
  • Fixed XmlSerializer to handle attribute XmlSchemePrivider.IsAny. XmlSerializer no longer outputs a root element with class name when the class has the attribute XmlSchemeProvider and IsAny is true. Fixes #11916
  • Test that DeflateStream.Read does read an empty stream. Covers #19313.
  • Reseting all private key values to null is required because a new import may not overwrite existing values. Fixes #18482.
  • Handle quoted filename value. Fixes #21960.
  • Dispose XmlReader using correct value. Fixes #21771.

C# Compiler

  • Don’t use `1 naming for compiler generated second level and deeper nested types. Fixes #22893.
  • Extend missing type check to type lookups. Fixes #20933.
  • Fix copy and paste error in constraints checker. Fixes #22131.
  • Speed up nullable tokenizer. Fixes #20195.
  • Coalescing operator if the lhs of a null is a integer type that is larger than the integer type on the rhs. Fixes #22054.
  • Check for duplicate destructors. Fixes #21983.
  • Switch statement with constant block at first label. Fixes #21805.
  • Decimal constants modulo folding. Fixes #21743.
  • Update codegen for boolean loads. Fixes #21685.


  • Workaround for issues with CreateItem task where metadata are not generated due to up-to-data inputs. Fixes #23022.
  • Add KeepDuplicates etc. to 4.0 as internal. Fixes #20961.
Posted by Andrew Tierney Tuesday, October 7, 2014 10:56:00 PM

CastleSoft switches to Syncfusion 

CastleSoft is happy to announce that today we have switched from our current .NET Tool provider Telerik to Syncfusion.

Why did we switch ?  Syncfusion has support for Desktop/Web/Mobile/JavaScript and soon the Xamarin platform.

As a Xamarin consulting partner having Syncfusion support gave us reason to question our choice of vendor.

Syncfusion is the enterprise technology partner of choice for Windows development, delivering a broad range of software frameworks and tools. Syncfusion has established itself as the trusted partner worldwide for use in mission-critical applications. Founded in 2001 and headquartered in Research Triangle Park, North Carolina, Syncfusion has more than 10,000 customers, including large financial institutions, Fortune 100 companies, and global IT consultancies.

We look forward to working with Syncfusion and hope to make some further announcements soon..

Posted by Andrew Tierney Friday, October 3, 2014 7:57:00 PM
Page 1 of 4 1 2 3 4 > >>