Open Source .NET Development [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Open Source .NET Development [Electronic resources] - نسخه متنی

Brian Nantz

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید


Summary


There is no perfect implementation of the CLI standard. Some implementations are further along than others. Some stick close to the specifications; others add some nice functionality above and beyond the standards. The Open Source projects could be embedded into a commercial product, but keep in mind the target OS platforms when choosing an implementation. Even though the implementations have minimized the amount of code porting required, porting an implementation is not a small task. If you decide you need to port an implementation, consider the language used in the lower-level workings of the framework (i.e., C versus C++) and try to match that language with one you are comfortable with. Review Chapter 1's discussion of Open Source licensing and research beyond the overview to see exactly what is expected from a specific license. MIT tends to lend itself a little better to proprietary extensions to the Open Source project than does the GNU GPL, but the GPL favors the product implementer. Make no mistake about it: Microsoft is in the business of making money. It will do whatever is in their best interest. Microsoft saw the advantages of standardizing the CLI and C# for acceptance in the community. The standards mutually benefited Microsoft, Open Source, and in the end, you the programmer. Recently, Microsoft has applied for patents for ASP.NET and ADO.NET. Implementers using these and other technologies that are not part of the standard should not be astonished if Microsoft decides to enforce the patents. While implementations that go beyond the specs offer greater compatibility with Microsoft's CLR and may be more attractive, they do run the risk of Microsoft changing the fundamentals of the non-standard technology or claiming it as intellectual property. Compared to many other companies, Microsoft has had a very good track record of keeping backwards compatibility in their APIs and functionality so as to not strand someone or force them to re-code their product. So far, Microsoft seems perfectly fine with the Open Source implementations of the CLI and even seems to encourage it somewhat through Rotor. Microsoft Research added the new functionality of Generics to the SSCLI as an experiment before putting it into .NET 2.0. From here on out, we are venturing into the unexplored territory of Microsoft .NET and Open Source.


    / 275