New – AWS Mobile SDK for Xamarin | AWS News Blog
您似乎是从中国境内访问我们的网站的。请导航至我们的优化版网站：。
28 JUL 2015 | in
We want to make sure that developers can use the programming language of their choice to build AWS-powered applications that run on many different types of devices and in a wide variety of environments. As you can see from the AWS Tools page, we already support multiple mobile (, , and ) and counter-top ( / ) devices with SDKs for , , , , , , , and , along with IDE toolkits for
Today we are adding a developer preview of support for
to the existing . Xamarin allows you to build cross-platform
applications that run on iOS, Android, and Windows devices. The new
gives your Xamarin app access to multiple AWS services including:
– Identity management.
– Object storage.
– NoSQL database
– Mobile Push for notifications.
– Track app usage and other metrics.
You can use the
IDE to write, debug, and test your code:
You can also use
with the .
to learn how to install the SDK and to start using AWS services from a Xamarin application.
on the Xamarin blog.Xamarin.Android开发及常见问题的解决 - CSDN博客
Xamarin.Android开发及常见问题的解决
一、Xamarin.Android开发环境的搭建
（一）所需组件
1.VS2013（VS2010以上即可）
2.JDK（/technetwork/java/javase/downloads/index.html）
3.Android SDK及NDK（/sdk ）
4.gtk-sharp（http://www./download/#download-win）
5.Xamarin VisualStudio
（二）搭建环境两种可选方案
&&&&&& 搭建开发环境可以使用Xamarin官网上的在线安装文件来安装，下载地址：/download，也可以选择自己手动安装。在线安装为傻瓜式安装，就不解释了（唯一缺点是下载速度奇慢）。来说下手动安装过程。
（三）安装顺序
1.安装Java SDK（jdk），这是虚拟机运行的基本条件
2.安装Android SDK后运行并下载各个版本的Android SDK
3.使用avd Manager工具（在Android SDK同级目录下可以找到）来新建一个模拟器（如果使用真机测试，可以不用新建模拟器）
4.安装gtk-sharp
5.安装Xamarin VisualStudio，该文件为VS的插件，用来添加Xamarin的项目模板
6.设置VS2013开发环境里的Android SDK及NDK路径
至此，环境搭建完成！
二、常见问题的解决方案
（一）开发环境无法发现模拟器或真机
&&&&&& 这种情况90%是adb被占用的问题，adb的tcp默认是5037，导致android设备与5037端口绑定失败的原因有很多，比如不要安装360、91助手等任何能连接手机的应用，他们会占用该tcp5037。
我们来输入命令来进一步确定，在cmd命令台输入“adb start-server”后如果输出了：
adb server is out of date. killing...
ADB server didn't ACK
* failed to start daemon *
那么可以确定adb的端口是被别的进程占用了，这时候，我们再来输入命令:
netstat -ano | findstr &5037&
回车后会有类似这样的反馈：
TCP 127.0.0.1:.0.0:0 LISTENING 4236
TCP 127.0.0.1:.0.1:49422 ESTABLISHED 4236
TCP 127.0.0.1:.0.1:5037 ESTABLISHED 3840
这时候我们打开任务管理器，把pid为4236的进程干掉。
（二）开发环境提示“vs正忙...”
&&&&&&& 开发环境一旦出现了这样的提示，请不要继续傻傻的等它忙完，它也不会告诉你它到底在忙些什么，唯一能确定的是，它永远忙不完。你还是直接启动任务管理器来结束它，再重新开始，所以我们做开发一定要记得时刻不停的按“control+s”，至少开发Xamarin.Android要把它当回事儿。
（三）双击axml文件后，开发环境死掉
这是Xamarin.Android插件的问题，要么你可以换一种打开方式来编写布局文件
要么你可以选择升级你的Xamarin插件
（四）出现代码不正确的执行
做Xamarin.Android开发，经常会遇到很多难以解释的现象，如果出现了类似于：
if (b == true){
&&&& //do something...
这样的代码，如果还是会执行do something，请自觉的把你的解决方案清理后，重启，这大多是编译器的错误，他会记录你的断点位置，以及监视变量的值，他出了问题，你最好重启吧。
三、调试及部署解决方案
（一）一个断点拦不住
&&&&&& 经常会出现打了断点，但是调试期间却没有停下来，也无法监视变量。遇到这样的问题我们需要在连续的地方打上两个断点，两个以上（包括两个）的断点才能拦住它！如下图，要监视变量c，我们打断点需要这样打两个！切记！
&&&&&&&&&&&&&
（二）部署（发布app）
&&&&&&& 电子签名是指数据电文中以电子形式所含、所附用于识别签名人身份并表明签名人认可其中内容的数据。通俗点说，电子签名就是通过密码技术对电子文档的电子形式的签名，并非是书面签名的数字图像化，它类似于手写签名或印章，也可以说它就是电子印章。很多杀毒软件会把其当做一个鉴别软件安全与否的首要标准。一个完善的可运行应用都要有电子签名，在android签名时需要使用keytool来签名，需要提供版本号、密钥、公司名称、所属地区等资料。在vs中省去了dos界面的命令行，只需要在发布android
app的时候填写资料，点击“Next”即可!
&&&&&&& 首先我们需要把解决方案配置由Debug版本改为Release版本，再来点击菜单栏中的“工具”==&“pulish Android Application”选项
&&&&&&&&&&&&
四、Android基础知识汇总
编码注意事项：
android原生开发语言为java，他们的成员以及变量命名采用Camel命名规则，而C#语言采用Pascal命名规则，因此，在看到java代码，想要转换C#代码时，请修改下大小写；另外java中没有属性这一说法，请将obj.setValue()等这类方法在转换时改为obj.Value=”xxx”;而且在java中，没有事件Event这一说，请灵活修改java中的接口。
（一）Android四大组件
Activity、Service、Broadcast Receiver以及Content Provider并称为Android四大组件。
(1)、Activity：活动
1.生命周期一定要清楚
生命周期：
onCreate ==& onStart ==& onResume ==& onPause ==& onStop ==& onDestroy
&&&&&&&&&&&&
(2)、Service：服务
&&&&& 1.服务中的code默认是运行在主线程中，请新开线程来运行你的code
&&&&& 2.请尽量使用filter使用startService方法来启动Service
生命周期：
&&&&& startService：onCreate ==& onStartCommand ==& onDestroy
&&&&& bindService：onCreate ==& onBind ==& onUnbind ==& onDestroy
&&&&&&&&&&&&&&&&&&&&&
(3)、Broadcast Receive：广播
&&&&&& Broadcast Receive为广播接收器，它和事件处理机制类似，只不过事件的处理机制是程序组件级别的，广播处理机制是系统级别的。
&&&&&& 注册广播：（这是一个拦截系统启动完毕的注册方式）
在Xamarin中我们使用一下代码来实现：
[BroadcastReceiver]
[IntentFilter(new string[] { &com.msg.ywq& })]
public class YlPadMsgReceiver : BroadcastReceiver
当系统启动后便会执行onReceive()方法，你要做什么，请写在这里。
(4)、Content Provider：内容提供者
&&&&&& Android中的Contentprovider机制可支持在多个应用中存储和读取数据。这也是跨应用共享数据的唯一方式。在android系统中，没有一个公共的内存区域，供多个应用共享存储数据。
&&&&&& 参考地址：http://blog.csdn.net/iceo/article/details/
（二）Android Layout常见布局文件的使用
&&&&&& 小窍门：很多人觉得写布局很烦，写起来太困难，属性太多，其实布局文件理解起来很简单，就把它当做在做css+div布局就行，这样理解起来会对我们写布局有很大的帮助。
常见布局：
LinearLayout：线性布局。分为水平、垂直，设置属性orientation为horizontal或vertical即可。
RelativeLayout：相对布局。几个相对布局会重叠在一起，调整它的位置可使用
layout_above：在xxx之上
layout_below：在xxx之下
layout_alignParentLeft=”true”：设置在父容器的左侧
layout_alignParentRight=”true”：设置在父容器的右侧
layout_toLeftOf：在xxx的左边
layout_toRightOf：在xxx的右边
FrameLayout：层次布局。常用来配合Fragment使用
常见布局属性：
layout_width：设置宽度
layout_height：设置高度
layout_gravity：设置该容器在父容器中的方位，属性值包括有：center、right...
gravity：容器内部文字或元素在该容器中的方位
layout_marginLeft、layout_marginRight、layout_marginTop ...... 不解释
background：背景。可设置十六进制颜色值，也可设置图片
id：设置控件元素的id，是渲染到界面后，取得该控件的方式。
（三）Android 分辨率的调整
1.使用相对屏幕像素密度单位。
2.使用android layout 布局文件做布局，灵活使用fill_parent、wrap_content等属性值，以及灵活使用layout_weight比重属性调整比例。
3.使用draw9path工具调整不规则图片的局域拉伸。
4.使用Context.Resources.DisplayMetrics.Density得到屏幕像素比例，动态调整布局。
（四）adb常用命令
adb pull -从手机中下载文件到电脑上 & & & & & & & 如:adb pull sdcard/stock.apk C:\\stock.apk
adb push -从电脑中上传文件到手机上 & & & & & & 如:adb push C:\\stock.apk sdcard/
adb install -安装软件到手机上 & & & & & & & & & & && 如:adb install C:\\stock.apk
adb uninstall -卸载手机上的软件 & & & & & & & & & & 如:adb uninstall stock.apk
adb device & & & & & & & & & & & & & & & & & & & & & & & & & 列出adb已绑定的android设备
五、Android设备兼容性
&&&&&&& Android设备在国内有相当部分厂商修改了内核底层，因此做安卓有个很头疼的问题，就像web应用中常见的问题---兼容性，兼容性是个硬伤！我们开发应用，尽量使用较低版本的sdk来编译，除此之外，谨记：代码一定要规范，切不可投机取巧！为实现一个效果而牺牲了兼容性，倒不如将效果降低，保持功能的正常使用！
&&&&&& 在android设备中，特别是国内的中兴，三星，华为等以及山寨机，经常把android内置的Google服务框架从系统内核中抽掉，这种情况下不能使用Google自带的推送。加之推送服务器为Google的服务器，国内把Google给和谐了，所以在做推送时，建议使用国内第三方推送工具。
&&&&&& 还有一些设备厂商将手机做成了双卡双待，Android SDK中没有获取第二个卡槽信息的api，加之国内通讯运营商对sim卡所做的修改，经常在获取sim信息的时候不成功，甚至报错，这时候一定要加try！
&&&&&& 为了将系统安装包缩小，自带的语音组件，也经常被国内厂商卸载掉，在使用语音的时候也一定要加上try！
&&&&&& 在某些功能块调用时必须使用try，同时切记不可在catch里不做任何处理！还有一个不得不用try的原因，在java 语言的api中，常常会有以下的api，而我们在调用的时候，必须使用try，将其包起，否则编译器都无法通过！
&&&&&& 以下代码是模拟了android api的一个方法，遇到这类api，必须使用try包起来。
public void do1() throws Exception {
&&&& //do something...
&&&& throw new Exception(&not implement&);
六、具有敢于怀疑一切的精神
&&&&&& 没有什么特殊的，记得出了问题后，不要认为something一定是对的，没有什么是绝对的，必须怀疑一切！比如上面提到的代码不正确的执行，如果不敢怀疑，一整天都找不到问题所在！
七、具有网管的精神-重启
&&&&&& 我们必须承认事物没有完美的，况且Xamarin还在进化阶段，有bug是很正常的，不稳定也可以理解。我之前经常遇到VS挂掉、连接模拟器失败，怎么都解决不了、代码不按照正常思维执行、VS自己闪退、视图编辑器打开失败、编译总是失败等等一些问题，经过重启环境更甚至于重启电脑后，一切正常！
本文已收录于以下专栏：
相关文章推荐
本文用于介绍Visual Studio 2012中Xamarin
Mono For Android 如何打包编译APK文件，从如何创建Android项目，到如何启动调试，都会逐个配图讲...
Xamarin.Android发布程序详解
Xamarin.iOS 委托事件的封装
C# 使用Xamarin 开发应用 -- 切换Activity
官方学习文档：/guides/android/getting_started/
官方学习例子：http://developer.xamarin...
他的最新文章
讲师：何宇健
讲师：董岩
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字).NET Core跨平台的奥秘[上篇]：历史的枷锁
时间： 11:26:07
&&&& 阅读：16
&&&& 评论：
&&&& 收藏：0
标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&微软推出的第一个版本的.NET Framework是一个面向Windows桌面和服务器的基础框架，在此之后，为此微软根据设备自身的需求对.NET Framework进行裁剪，不断推出了针对具体设备类型的.NET Framework版本以实现针对移动、平板和嵌入式设备提供支持。除此之外，在Windows平台之外一致游荡着一只特立独行的猴子（Mono）。.NET平台看起来欣欣向荣，而实际上却日薄西山，就在这个时候微软走了一条唯一正确的道路，那就是基于跨平台理念重新设计的.NET Core，以及由此驱动地对整个.NET平台进行全新布局。
对于计算机从业人员来说，“平台（Platform）”是一个我们司空见惯的词语，在不同的语境中它具有不同的语义，比如它可以指代操作系统环境和CPU架构类型，也可以表示硬件设备类型。经过多年的苦心经营，微软已经为在Windows平台下构建了一个完整的支持多种设备的.NET生态系统。与此同时，通过借助于Mono和Xamarin，.NET已经可以被成功移植到包括Mac OS X、Linux、iOS、Android和FreeBSD等非Windows平台。
一、Windows下的.NET 微软在2002年推出了第一个版本的 .NET Framework，这是一个主要面向Windows 桌面（Windows Forms）和服务器（ASP.NET Web Forms）的基础框架。在此之后，PC的霸主地位不断受到其他设备的挑战甚至取代，为此微软根据设备自身的需求对.NET Framework作了相应的简化和改变，不断推出了针对具体设备类型的.NET Framework，主流的包括Windows Phone、Windows Store、Silverlight和.NET Micro Framework等，它们分别对移动、平板和嵌入式设备提供支持。由于这些不同的.NET Framework分支是完全独立的，这使我们很难开发一个支持多种设备的“可移植（Portable）”应用。
.NET Framework的层次结构 针对不同设备.NET Framework的独立性导致了在很多情况下我们不得不针对具体的设备平台进行编程，跨设备平台代码的重用显得异常困难。为了让读者朋友们对这个问题具有深刻地理解，我们从.NET Framework的结构开始讲起。从结构组成的角度来讲，.NET Framework由如下图所示的两个层析构成，它们分别是提供运行环境的CLR（Common Language Runtime）和提供API的FCL（Framework Class Library）。
CLR之于.NET等同于JVM之于Java，它是.NET虚拟机。作为一个运行时（Runtime），CLR为程序的执行提供一个托管（Managed）的执行环境，它是.NET Framework的执行引擎，为托管程序的执行提供内存分配、垃圾回收、安全控制、异常处理和多线程管理等方面的服务。CLR是.NET Framework的子集，但是两者却具有不同的版本策略。到目前为止，微软仅仅发布了4个版本的CLR，它们分别是1.0、1.1、2.0和4.0，.NET Framework 1.0和1.1分别采用CLR 1.0和1.1，CLR 2.0被.NET Framework 2.0和3.x共享，.NET Framework 4.x下的运行时均为CLR 4.0。
FCL是一个旨在为开发人员提供API的类库，由它提供的API又可以划分为如上图所示的两个层次。处于最底层的部分被称为BCL（Basic Class Library），它提供了一系列基础类型，它们用于描述一些基本的数据类型和数据结构（比如字符串、数字、日期/时间和集合等）和提供一些基础性的操作（比如IO、诊断、反射、文本编码、安全控制、多线程管理等）。在BCL之上的则是面向具体应用类型的API，我们大体上可以将它们划分为入下三种类型：
面向应用（比如ASP.NET、WPF和Windows Forms等）
面向服务（比如WCF、WF和Data Services等）
面向数据（比如ADO.NET、Entity Framework和LinQ to SQL等） 我们也可以采用另一种方式对FCL进行重新划分：将面向某种应用或者服务类型（比如Windows Forms、WPF、ASP.NET和WCF等）的部分成为AppModel，那么整个.NET Framework则具有了如下图所示的三层结构。
大而全的BCL 我们知道微软的.NET战略是在千禧年提出来的，两年之后第一个.NET Framework版本和IDE（VS.NET 2002）随之问世。在之后的10多年中，一系列版本的.NET Framework被先后推出。微软目前发布的最新.NET Framework版本为4.7，下图为你展示了整个.NET Framework不断升级的演进过程，以及各个版本提供的主要特性。
上图2-3勾勒出.NET Framework这些年的发展历程旨在说明一个问题：作为整个.NET平台的基础框架，.NET Framework在不断升级过程中是自己变得更加强大和完备，但是在另一方面也是自己变得越来越臃肿。随着版本的不断升级，构成.NET Framework的应用模型、BCL和运行时（CLR）都在不断地膨胀（.NET Framework 2.0/3.x和.NET Framework 4.x分别采用CLR 2.0和CLR 4.0），下图很直观地说明了这个问题。
我们知道程序集是.NET最基本的部署单元，不论定义其中的多少类型被使用，CLR总是将整个程序集加载到内存中。对于上面介绍的构成.NET Framework的三个层次来说，应用模型是针对具体应用/服务类型的，相应的API通过独立的程序集来承载（比如ASP.NET的核心框架定义在程序集System.Web.dll中，承载整个Windows Forms框架的程序集则是System.Windows.Forms.dll），所以.NET Framework的各个应用模型是相互独立的。在开发某种类型的应用时，我们只需要引用应用模型对应的程序集就可以了，也就是说我们开发一个Windows Forms应用，是不需要去引用System.Web.dll程序集的。
但是BCL的绝大部分核心代码都定义在mscorelib.dll这个核心程序集中，所以BCL基本上来说是作为一个不可分割的整体存在于.NET Framework之中。.NET Framework需要对运行在本机各种类型的托管程序提供支持，针对所有应用类型的基础类型均需要定义在BCL中。在很多情况下，我们的应用可能仅仅需要使用到BCL一个很小的子集，但是我们不得不将定义整个程序集都加载到内存之中。
一方面BCL总是作为一个不可分割的整体被加载，另一方面其自身的尺寸也在随着.NET Framework的升级而不断地膨胀。对于客户端应用（比如Windows Forms/WPF应用）来说，这应该不算是一个大不了的问题，但是对于移动和服务端应用（包括部署于云端应用）来说，由此带来的对性能和吞吐量的响应就成了一个不得不考虑的问题。
理想的BCL消费方式是“按需消费”，我们需要那个部分就加载那个部分。由于作为独立部署单元的程序集总是作为一个整体被CLR加载到内存中，要完全实现这种理想的BCL消费方式，唯一的办法就是将其划分为若干小的单元，并分别定义到独立的程序集中。除此之外，按照模块化的原则对整个BCL进行拆分也是版本升级变得更加容易，如果现有版本具有需要修复的Bug，或者性能需要改进，那么只需要改动并升级相应的模块就可以了。下图展示了具有模块化BCL的.NET Framework层级结构。
多个设备平台独自为政 经过多年的经营，微软已经为我们构建了一个完整的支持多种设备的.NET生态系统，从最初单纯的桌面平台，逐渐扩展到移动、平板和嵌入式等平台。设备运行环境的差异性导致了针对它们的应用不能构建在一个统一的.NET Framework平台上，所以微软采用独立的.NET Framework平台来对它们提供针对性的支持。就目前来说，除了支持Windows 桌面和服务器设备的“完整版 .NET Framework”之外，微软还先后推出了一系列“压缩版.NET Framework”，这其中就包括Windows Phone、Windows Store、Silverlight和.NET Micro Framework等，它们分别对移动、平板和嵌入式设备提供支持。
这些.NET Framework并不是仅仅在AppModel层次提供针对相应设备平台的开发框架，它们提供的BCL和Runtime也是不同。换句话说，这些.NET Framework平台是完全独立的，不同.NET Framework平台之间的独立性很直观地体现在下图之中。目标平台的独立性导致我们很难编写能够在各个平台复用的代码，关于这一点我们会在下面一节“复用之伤”中做重点讨论。
二、非Windows下的.NET 尽管微软自身多年以来基本上都只在Windows平台下的一亩三分地上进行耕耘，但是.NET 则通过Mono和Xamarin将触角延伸到其他平台（Mac OS X、Linux、iOS和Android等）。虽然目前做得并不算完美，但是我们可以说.NET具备跨平台的能力。
从CLI谈起 .NET跨平台的能力建立在一种开放的标准或者规范之上，这个所谓的标准/规范就是CLI。CLI的制定旨在解决这样一个问题：由不同（高级）编程语言开发的.NET应用能够在无需任何更改的情况下运行于不同的系统环境下。要实现这个目标，必需有效地解决这里涉及到两种类型的差异，即编程语言的差异和运行时环境的差异。编程语言之间能够实现相互兼容、运行时环境能够得到统一，跨平台的伟业方能实现。
CLI全称为Common Language Infrastructure，其中Common Language说的是语言，具体来说是一种通用语言，它旨在解决各种高级开发语言的兼容性问题。Infrastructure指的则是运行时环境，旨在弥合不同平台之间执行方式的差异。Common Language是对承载应用的二进制内容的静态描述，Infrastructure则表示动态执行应用的引擎，所以CLI为可执行代码和执行引擎确立一个统一的标准。
编程语言有编译型和解释型之别，前者需要通过编译器进行编译以生成可执行代码，CLI涉及的Common Language指的是编译型语言。要实现真正的跨平台，最终需要解决的是可执行代码在不同平台之间的兼容和可移植的问题，而编程语言的选择仅仅决定了应用源文件的原始状态，应用的兼容性和可移植性由编译后的结果来决定。如果通过不同编程语言开发的应用通过相应的编译器编译后能够生成标准的目标代码，那么编程语言之间的差异就不再是一个问题了。
按照CLI的规定，用来描述可执行代码的是一种叫做CIL（Common Intermediate Language）的语言，这是一种介于高级语言和机器语言之间的中间语言。如下图所示，虽然程序源文件由不同的编程语言编写，但是我们可以借助相应的编译器将其编译成CIL代码。原则上讲，我们可以设计出新的编程语言并将其加入到.NET大家庭中，只需配以相应的编译器生成统一的CIL代码即可。我们也可以为现有的某个编程语言设计一种以CIL为目标语言的编译器使之成为.NET语言。CIL是一门中间语言，同时也是一门面向对象的语言，所以对于一个CIL程序来说，类型是基本的组成单元和核心要素。微软制定了一个名为CTS（Common Type System）的规范为CLI确立了一个统一的类型系统。
编程语言的差异通过编译器这个适配器得以“同一化”，运行环境的差异则可以通过虚拟机（VM：Virtual Machine）技术来解决。虚拟机是CIL的执行容器，它能够在执行CIL代码的过程中采用及时编译的方式将它动态地翻译成与当前执行环境完全匹配的机器指令。虚拟机屏蔽了不同操作系统之间的差异，让目标程序可以不做任何修改的情况下就能运行于不同的底层执行环境中，而CIL实际上是一种虚拟机语言。
从实现原理来看，让.NET能够跨平台其实不难，但是让各种相关的人员参与进行以构建一个健康而完善的跨平台.NET生态圈则注定不是一件一蹴而就的事情，这里涉及的利益相关方包括编程语言的设计者，以及设计和开发编译器、虚拟机、IDE以及其他相关工具的人，当然还包括广大的应用开发者。跨平台.NET生态环境必须建立在一个标准的规范之上，所以微软为此制定了CLI，然后提交给欧洲计算机制造商协会（ECMA：European Computer Manufacturers Association）并被后者接受，成为了一个编号为335的规范，所以CLI又被称为ECMA-335（顺便说一下，ECMA还接受了微软为C#这们编程语言制定的规范，即ECMA-334）。
Mono与Xamarin CLI（ECMA-335）这一开放的规范在.NET诞生的那一刻起就赋予了它跨平台的基因，但是被烙上Windows这一印记的微软似乎根本就不曾想过将.NET推广到其他的平台，真正完成这一使命了是一个叫做Mono的项目。虽然Mono已经是一个不算年轻的项目了，但是依然有很多人对它不是很了解，所以我们不妨来简单介绍一下它的历史。
1999年，Miguel de Icaza创建了一家叫做Ximian的公司，这是一家旨在为GNOME项目（这是一个为类Unix系统提供桌面环境的GNU项目，GNOME是目前Linux最常用的桌面环境之一）开发软件和提供支持的公司。2000年6月，微软正式发布.NET Framework，Miguel de Icaza被个“基于互联网的全新开发平台”（.NET在发布的时候被标榜为“a new platform based on Internet standards”）深深吸引。同年11月，微软发布了CLI规范（ECMA-335）并为公众开发了独立实现的许可，Miguel de Icaza从中看到了商机，因为这实际上为.NET走向非Windows平台提供了可能。Miguel de Icaza在2001年7月开启了Mono这个项目，并采用C#作为主要的开发语言（目前支持VB .NET），所以针对CLI和C#的两个ECMA规范是构建Mono项目的理论基础，如果访问Mono的官方网站，我们会发现它是这样定义Mono的：“Mono is an open source implementation of Microsoft‘s .NET Framework based on the ECMA standards for C# and the Common Language Runtime.”
Mono的使命不仅仅局限于能够将.NET应用正常运行在其他非Windows平台，它还希望帮助开发人员能够直接在其他平台进行. NET应用的开发，所以Mono不仅仅根据CLI为相应的平台开发了作为虚拟机的CLR和编译器，还提供给了IDE和相应的开发工具（被称为MonoDevelop）。Mono的第一个正式版本（Mono 1.0）在项目开启差不多三年之后（2004年6月）发布。
2003年8月，Ximian被另一家叫做Novell的公司收购，后者继续支持Miguel de Icaza开发Mono项目，在这期间Mono陆续推出了若干Mono 2.x版本。2011年4月，Novell又被另一件叫做Attachmate的公司收购，后者决定放弃Mono，于是Miguel de Icaza带着整个Mono团队成立了一个家新的公司，起名为Xamarin。同年7月，Xamarin向原来的母公司Novell拿到了Mono的开发许可。在此之后的几年内，Xamarin先后发布了Mono 3.x、Mono 4.0和Mono 5.x，目前的最新版本为5.4。Mono现今的目标是实现.NET 4.5除WPF、WF和部分WCF外的所有特性，目前缺失的部分的开发正在通过一个叫做Olive（Mono的一个子项目）的项目进行着。
在Mono项目的基础之上，Xamarin开始开发以新公司命名的产品，其中最重要版本当属2013年2月发布的Xamarin 2.0。Xamarin 2.0由Xamarin.Android、Xamarin.iOS和Xamarin.Windows组成，它们使我们可以采用C#开发针对Android、iOS和Windows的Native应用。除此之外，Xamarin 2.0还携带着一个叫做Xamarin Studio（MonoDevelop的升级版）的IDE以及与一些与Visual Studio集成的工具。2014年5月Xamarin 3.0发布，作为其核心的Xamarin.Forms为不同平台的Native应用提供统一的控件，也就是说我们利用Xamarin.Forms API开发Native应用可以在无需做任何改变的情况下运行在Android、iOS和Windows上。
2016年2月，微软和Xamarin宣布双方签署协议达成了前者针对后者的收购。在2016年Build大会上，微软宣布将整个Xamarin SDK开源，并将它作为一个免费的工具集成到Visual Studio中，Visual Studio企业版的用户还可以免费使用Xamarin企业版的所有特性。
综上所述，由于.NET是建立在CLI这一标准的规范之上，所以它天生就具有了“跨平台”的基因。在微软发布了第一个针对桌面和服务器平台的.NET Framework之后，它开始 “乐此不疲” 地对这个完整版的.NET Framework进行不同范围和层次的 “阉割” ，进而造就了像Windows Phone、Windows Store、Silverlight和.NET Micro Framework的压缩版的.NET Framework。从这个意义上将，Mono和它们并没有本质的区别，唯一不同的是Mono真正突破了Windows平台的藩篱。包括Mono在内的这些分支促成了.NET的繁荣，但我们都知道这仅仅是一种虚假的繁荣而已。虽然都是.NET Framework的子集，但是由于它们采用完全独立的运行时和基础类库，这使我们很难开发一个支持多种设备的“可移植（Portable）”应用，这些分支反而成为制约.NET发展的一道道枷锁。至于为什么“可移植（Portable）”.NET应用的开发如此繁琐，敬请关注中篇《》。 标签：&&&&&&&&&&&&&&&&&&&&&&&&&&&
&&国之画&&&& &&&&chrome插件&&
版权所有 京ICP备号-2
迷上了代码！