Что читать начинающему .Net программисту

Подборка, составленная коллективным разумом RapidSoft

Много под катом

NuPack - менеджер пакетов для Visual Studio 2010

Наконец-то дождались?

http://nupack.codeplex.com/

добавляет возможности по добавлению Package Reference - непосредственно из репозитория пакетов

Если приживется, наконец-то будет стандартный способ работы с пакетами в .Net

Ссылки
- http://habrahabr.ru/tag/nupack/ - обзор на Хабре
- подробная статья

UPD: В качестве пробы, выложил версию 0.0.3 утилиты autopatch.Net в виде пакета nupack
1. добавляем в список репозиториев http://dialogue.beta.rapidsoft.ru/nupack
2. создаем новый проект
3. открываем Package Manager console, выбираем в Package Source этот репозиторий
4. говорим add-package autopatch.Net

Вуаля! проект добавлен. Можно пользоваться :-)

.Net 3 - Сила методов расширения

Методы расширения (Extension Methods) это простой такой трюк компилятора, который позволяет программисту добавлять свои собственные методы к уже существующим классам.
Естесственно, чтобы не нарушить защиту класса, методам расширения недоступны “кишки” класса, к которому они пристраиваются. Метод расширение обязан пользоваться существующим публичным контрактом.
Фактически, это такой способ подстроить синтаксис уже существующей библиотеки/фреймворка “под себя”, уменьшив количество кода, которое нужно написать для реализации требуемой функциональности (любители Nemerle меня поймут :-)
Передо мной недавно встала следующая задача: во множестве пользовательских контролов ASP.NET приложения нужно было анализировать дерево контролов страницы и выцепить из него самый первый контрол, который реализовал определенный интерфейс.
Метод FindControl для этого не подходил – я не имел возможности задавать имя контрола. В результате были написаны пара методов-раширений, которые добавляли требуемую функциональность

ReSharper 5 Overview

Парни из JetBrains в своем блоге рассказывают о том, что будет в 5-м ReSharper-е.

Выглядит о-очень вкусно, один только Call Tracking это какая офигенная штука. Она, я так понимаю в design time анализирует откуда указанный метод может быть вызван и разворачивает это дерево вызовов. То есть – больше никаких веерных Find Usages :)

Еще из понравившегося – Move String to Resource, то есть интернационализация по одному клику, почти так же удобно как и в XCode.

С новыми технологиями тоже неплохо, обещают поддержку .Net 4.0, VS 2010, ASPNET MVC

Идеальный менеджер пакетов для .Net

Буду собирать ссылки и мысли по поводу идеального менеджера пакетов для .Net

Преамбула

.Net разработка исторически была не очень “опен сорсовой”, то есть базировалась на проприетарных библиотеках.
Microsoft делает некоторые подвижки в этом направлении – открыл исходники .Net Framework, хостит opensource проекты на CodePlex, но до совершенства еще далеко – например, в VS нет удобного способа при отладке, к примеру, NHibernate, просматривать исходный код этой бибилиотеки.
При этом OpenSource проектов для .Net просто завались – например NHibernate, Spring.Net, майкрософтовские Pattern&Practices Building Blocks etc.
Есть еще и The Mono Project, который мало того, что  сам opensource, так еще и порождает множество проектов с открытым исходным кодом.

Зачем?

Если я подключаю внешнюю библиотеку (тот же NHibernate) то мне нужно руками следить за всеми зависимостями, котоые она тянет за собой, следить за их версиями, следить за конфликтом версий и тп.

Вместе с тем в Java мире это уже все давно пройденный этап – есть Maven, который поддерживается всеми основными IDE, есть Bulildr, есть opensource репозитории, которые подцепляются без проблем. Есть Ivy the package manager в конце концов.

В Java если ты хочешь разработать проект с использованием например Hibernate или Spring Framework, ты пишешь .pom файл из пяти строчек) – и тот же Maven скачивает тебе нужные версии всех нужных библиотек, со всеми их зависимостями, со всеми документациями и пр.

Что же делать?

Ну, есть NMaven (который суть плагин для Maven), есть Byldan, есть предложенный в Хабровской статье менеджер, но как-то оно все не складывается в единую картину.
Я вижу, что идеальный менеджер пакетов должен быть:

• Клоном хорошо зарекомендовавшей себя Java-вской библиотеки (например, того же Maven);
• Совместимым с Visual Studio (т.е иметь плагин, аналогичный Maven integration например в IntelliJ IDEA);
• Использоваться как в .Net так и в Mono – технологии практически идентичные, надо дружить;
• Иметь репозиторий проектов, куда любой уважаемый разработчик сможет залить свой проект для публичного доступа. CodeHaus и Sonatype Nexus – идеалы для подражания.

Но самое главное, как обычно, не технологии. Самое главное – показать .Net сообществу, что подход, принятый в Java мире, отлично подходит и для мира дотнетовского.
Вообщем, тема для размышлений богатейшая.

PS - Вот обсуждение на Хабре (комментарии тоже интересные)
http://habrahabr.ru/blogs/net/68453/
PS2 - Сравнение подходов Java/.Net на RSDN - http://rsdn.ru/forum/flame.comp/3275597.aspx
PS3 - посмотреть NPanday
PS4 - обсужение на stack overflow

Debugging Tools – как открывать дампы из Explorer-а (.Net Framework 2.0+)

Всем хорошего дня!

Недавно пришлось опять плотно поработать в дампами ASP.NET-овского сайта, снятыми при помощи UserDump.

Дампов было несколько, мы многократно открывали их на разных машинах, каждый раз, открывая дамп приходилось набирать мантру:

• Open WinDbg
• Copy длиннючий путь к sos.dll, сказать .load …\sos.dll
• Open в WinDbg файл с дампом через control-d

Как результат, я начал гуглить на тему скриптов для дебаггера, и нашел чудную статью Carlo Cardella под названием “Never Doubt My Debugger”.

В статье было написано, как настроить WinDbg так, чтобы открывать файлы дампов .dmp в Эксплорере одним кликом (при этом, самостоятельно загрузив еще и sos.dll (sic!):

К сожалению, один-в-один его скрипты не запустились, поэтому я их чуть-чуть подправил, и выкладываю здесь для всеобщей пользы:

• WinDbgExp.zip - Open Dump Files .dmp in Explorer (<1Kb)

Установка

Все что нужно, это скопировать скрипты в каталог C:\Program Files\Debugging Tools for Windows (x86)\scripts (каталог надо создать) и запустить файл register.reg, который добавить в реестр правильнуб команду на открытие .dmp файлов.

Внимание!

Скрипт расчитывает на следующее:

• Debugging Tools установлены в каталонг C:\Program Files\Debugging Tools for Windows (x86)
• используется sos.dll из .Net Framework 2.0 или выше по пути c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\

Соответственно, если вы установили отладчик в другой каталог или у вас другой номер сборки .Net Framework, нужно подправить файлы dbgnet20.txt и/или register.dbg

Coming Soon...

Как лучше, так -



Или вот так -


?

Как прочитать файл .properties из .Net

Сейчас занимаюсь доведением до ума библиотеки AutoPatch под .Net - авторы начали ее портировать, но похоже так и не довели дело до конца. Потребовалось прочитать .property файл, который записан в java формате.

Нашел для этого класс JavaProperties. Автор утверждает, что он портировал функциональность java-парсера, так что проблем с совместимостью быть не должно. С удовольствием даю ссылку:

http://www.kajabity.com/index.php/2009/06/loading-java-properties-files-in-csharp/

как узнать PublicKeyToken для сборки .Net

How to obtain public key token for a .Net assembly:

C:\Program Files\NUnit 2.4.8\bin>sn -Tp nunit.framework.dll
Microsoft
(R) .NET Framework Strong Name Utility Version 2.0.50727.42Copyright (c)
Microsoft Corporation. All rights reserved.
Public key
is0024000004800000940000000602000000240000525341310004000001000100cf4a0bbf354b6d8d0c39e7bc40dd0be16a32ba9d763e8d04fd9591b92d7269dd09c2c65ec7563ce393aca71913bea13dd6a20d676ed7ddc726f846fce66800bb034903619a1baa520f5f758946cf2b4af6ba7c310d02d092a5cf51be6d52e88633f502474b4f461d850b63219c09a3373a23d73156ee03d6c7b38c36d1211fac
Public
key token is 96d09a1eb7f44a77

Сравнительный анализ современных .net ORM

Задача

Необходимо было аргументированно выбрать ORM для большого .Net проекта. Рассматриваемые (пока) ORM: Entity Framework, BLTooklit, SubSonic.

Результат

* Аналитический отчет
* Сводная таблица с баллами, набранными каждой из ORM

Ваша критика/пожелания приветствуется. Надеюсь продолжить этот опыт и рассмотреть еще и другие (не менее интересные ORM)

Microsoft открывает исходные коды .Net Framework

Наконец-то свершилось - исходники .Net Framework опубликованы, отладка со вклбченными иходниками возможна в VS2008. Не нужно больше ковырять фреймворк .Net Refelector-ом :-)

Побробности можно прочитать в блоге ScottGu.

Исходники открыты под Read-Only Reference License. То есть смотреть можно, изучать можно, копировать и использовать нельзя. Это не очень настоящий OpenSource, но все-таки.

Microsoft Volta

В ряду JavaScript-компиляторов пополнение: технология Microsoft Volta (возможно, это новое имя Script#-а)

Поглядим-поглядим...

QuickStart: http://labs.live.com/volta/docs/quickstart.aspx

Open Source persistence framework list

http://csharp-source.net/open-source/persistence

Радостная новость - Microsoft будет отдавать исходники некоторых своих сборок .Net Framework 3.5. И можно будет отлаживаться прямо внутри них!

"Today I'm excited to announce that we'll be providing
this with the .NET 3.5 and VS 2008 release later this year.
We'll begin by
offering the source code (with source file comments included) for the .NET
Base Class Libraries (System, System.IO, System.Collections,
System.Configuration, System.Threading, System.Net, System.Security,
System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms
(System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF
(System.Windows). We'll then be adding more libraries in the months ahead
(including WCF, Workflow, and LINQ). The source code will be released
under the Microsoft Reference License (MS-RL)."

http://weblogs.asp.net/scottgu/archive/2007/10/03/releasing-the-source-code-for-the-net-framework-libraries.aspx

Отладка, UserDump и Debugging Tools for Windows

См также

• Как открывать .dmp файлы прямо в эксплорере через контекстное меню
• Все посты про отладку

Доктор, у меня все болит

Как объяснить? Как описать?
Даже всезнание отказывает…
Вернор Виндж, «Пламя над бездной»
Если вы не разу не встречались с ситуацией, когда приложение отлично работает на машине разработчика, но необъяснимо глючит у заказчика – вы очень везучий программист. Или вы не программист, а кто-то другой.
Обычно ситуации такие возникают нечасто, но каждая из них до боли запоминается, и вспоминаешь о ней с содроганием еще спустя месяцы. Ну еще бы – заказчики звонят, менеджеры матерятся, команда сидит сутками на работе и пытается спасти положение. Если проблему удается решить, чувствуешь себя чуть ли не Кутузовым, выигравшим очередное сражение. Если же нет…
Я сейчас расскажу о том, как можно облегчить себе жизнь в ситуации, когда ASP.NET приложение ведет себя невесть как на production машине, а вы не можете понять, почему так происходит.
Обычно симптомы простые – очень злые заказчики выходят на связь и говорят, что «сайт не работает». Когда начинаешь разбираться – выясняется, что приложение действительно время от времени недоступно и веб-сервер радостно кидает ошибки вида “502 Service Unavailable”. Для клиента это может выглядеть как надпись «Page cannot be found» в браузере.

После такого дела, естественно, захочется посмотреть, что же там происходит на сервере. В этом поможет приложение Process Explorer (в принципе, и стандартный Task Manager сгодится, но он похуже).
Process Explorer и другие чудо-утилиты – File Monitor, Registry Monitor, Process Monitor etc – написал великий мастер Марк Руссинович. Все это хозяйство можно скачать с сайта Microsoft вот по такому адресу: http://www.microsoft.com/technet/sysinternals.
Когда запустите Process Explorer, посмотрите информацию по процессу w3wp.exe

W3WP – это такой процесс, в котором Internet Information Server 6 по умолчанию запускает приложения ASP и ASP.NET. Точнее – те приложения, которые вы сгруппируете в одном AppPool. Прочитать про w3wp можно тут: http://msdn2.microsoft.com/en-us/library/ms524990.aspx

Вот например, как может вести себя w3wp:

В какой-то момент процессор на сервере начал потреблять 100% CPU. На картинке мы видим длительную 50%-ю загрузку, потому что на сервере установлен 2хядерный процессор и только половина ресурсов процессора была потрачена. Справа на картинке видно, как какой-то другой запрос скушал остатки процессорной мощности секунд на 10.

Еще бывает очень полезно настроить логгинг Performance Counters – можно много узнать о личной жизни сервера. Вот здесь (http://msdn2.microsoft.com/en-us/library/fxk122b4(vs.71).aspx) рассказывается про каунтеры, полезные для анализа ASP.NET приложений.

Дальше нам нужно понять – что же так грузит процессор? Раз дело в w3wp, значит, это наше приложение (или не наше, но здесь для простоты давайте считать, что только ваше приложение сидит в данном AppPool-е)
Дело может осложниться тем, что проблема возникает только на рабочем сервере, где любая отладка невозможна, и нигде больше проблему повторить не удается. Значит, надо как-то анализировать «нутро» процесса, его помыслы и деяния. Причем, не мешая настоящим, живым пользователям пользоваться сайтом.

Знаю, знаю, что на production отлаживаться нельзя. И доступа туда разработчики иметь не должны. Но если вы работаете не в банке, а скорость реагирования на проблему важнее бюрократии и безопасности – доступ вам скорее всего дадут. Впрочем, снять дамп процесса можно научить и сисадминов, причем без проблем. Сисадмины обычно в курсе, что такое core dumped, и с радостью помогают в создании таких «кор» другим.

В принципе, Process Explorer показывает, какие у процесса есть потоки и чем они заняты (даже Stack Trace делает и отладочные символы понимает). Проблема только в том, что Process Explorer не показывает .Net-овский управляемый стек.
Вот, например, попробуйте догадаться, чем сейчас занимается .Net приложение:

Раз Process Explorer нам не помощник, значит, нужен инструмент, который сделает трассировку .net-стека по всем потокам процесса. И такой инструмент есть – называется он Debugging Tools for Windows и совершенно бесплатно доступен на сайте Microsoft.

WinDbg в составе Debugging Tools – это, наверное, вообще самый мощный отладчик для Windows. Он умеет отлаживать все – от драйверов до .Net приложений. И что немаловажно, он умеет анализировать дампы процессов, в том числе и дампы, которые создали на другой машине. И .Net он тоже понимает. Скачать Debugging Tools можно по этому адресу: http://www.microsoft.com/whdc/devtools/debugging/default.mspx

Пользуемся User Dump

Но мы не можем отлаживаться на production! Поэтому мы сделаем дамп процесса, скопируем его к себе и будем исследовать при помощи WinDbg из поставки Debugging Tools.
А дамп процесса мы сделаем при помощи утилиты UserDump, которую качаем опять же с сайте Microsoft: http://www.microsoft.com/downloads/details.aspx?FamilyID=E089CA41-6A87-40C8-BF69-28AC08570B7E&amp;displaylang=en&displaylang=en
Инсталлировать ничего не нужно, нужно только подкараулить наш процесс, когда он начнет вести себя плохо, и сделать дамп, указав userdump-у ID процесса:

На время работы утилиты процесс блокируется и никакие запросы к сайту не работают. К счастью, дамп создается быстро – меньше минуты. Может и за 10 секунд управиться.
Созданный .dmp файл архивируем и копируем затем на девелоперскую машину. Файл будет размером с рабочий набор процесса – то есть не меньше 30 мегабайт а скорее всего раз в 10 больше. Впрочем, сжимается дамп-файл неплохо.

Ставим Debugging Tools for Windows

Тут даже рассказывать-то особенно нечего – скачиваем Debugging Tools и устанавливаем к себе на компьютер.
Затем запускаем WinDbg и открываем наш дамп:

Не пугайтесь только внешнего вида WinDbg – он кажется каким-то выходцем из прошлого. Примерно так наверное выглядит робот-марсоход изнутри. Какие-то приборы, циферки, буковки … Короче, не программа, а мечта.

Анализируем дамп процесса

Когда дамп процесса загрузится, вы увидите примерно следующее:

Красным выделена команда, которую нужно будет набрать в консоли дебаггера. Дело в том, что функции отладки .net приложений в WinDbg выполнены в виде плагина, который и загружается командой “.load”.
Существует два вида библиотеки sos.dll (sos – это сокращение от почему-то ”Son of Strike”). Одна версия подходит для managed программ, работающих под .Net 1.0 и 1.1, а вторая – для .Net 2.0
Для .Net 1.x sos.dll лежит в каталоге %DEBUGGING_TOOLS_HOME%\clr10.
Версия для .Net 2.0 поставляется вместе с самим .Net Framework. По необъяснимым причинам, она беднее по функционалу, чем sos.dll для 1.x, но тоже ничего.
Загругить ее можно так:
“.load C:\<WINDOWS_HOME>\Microsoft.NET\ Framework\v2.0.50727\sos.dll”
После того, как мы загрузили sos.dll, в отладчик добавилось множество полезных команд. Все эти команды начинаются со знака ”!”.
Полный список команд можно посмотреть, набрав «!help» в консоли отладчика. Команд там страницы на две, и с помощью них можно узнать много всего о .net – приложении.

Вот список команд для sos.dll от .net 1.x. Впечатляет?
Смысл части команд понятен из названия, а чтобы узнать подробности , наберите в консоли «!help <ИМЯ КОМАНДЫ>». Советую посмотреть справку по всем командам – многое потом может пригодиться.
Вспоминаем про нашу проблему – 100% загруженность CPU.
Смотрим список managed потоков – команда «!Threads»

Помимо кучи разных цифр здесь видно, что в процессе, который мы задампили, выполнялось 12 потоков. Пользы от этого нам сейчас немного, но для цельного понимания картины пригодится.
Теперь нам не остается ничего, кроме как просмотреть трассировку всех стеков для всех потоков с помощью команды «!EEStack»

EEStack выводит уйму информации: ссылки на стековые фреймы, адреса возврата и самое главное – символические имена для каждого стекового фрейма.

По-хорошему, при отладке не помешают бы еще и PDB файлы Windows – отладочные символы от основных DLL. Их можно получить, подключившись в Microsoft Symbol Server. Как - смотрим на сайте Microsoft: http://msdn2.microsoft.com/en-us/library/b8ttk8zy.aspx

Но поскольку мы не собираемся отлаживаться на уровне ассемблера откомпилированный JIT-компилятором код, в дампах стека нас будут интересовать только символы, начинающиеся с “MethodDesc“. Это, собственно и есть названя .net-овских классов и методов.
На следующей картинке можно получить кучу полезной информации, например вот тут видно, какую страницу рендерил ASPNET в этом потоке в момент, когда вызвали userdump.exe

Явно это был SlideViewer.aspx, что бы это название не значило.
А дальше нужно всего лишь внимательно просмотреть стеки от всех потоков и понять, где же тот самый поток, который загрузил процессор. Ну а еще дальше – сущие пустяки: успокоить заказчика, починить баг, написать тесты, выкатить обновление программы. После всего, через что мы только что прошли, это уже мелочи…
Понятное дело, что WinDbg вместе с sos.dll умеют в сотни раз больше, чем я тут описал. Например, можно посмотреть, какие объекты лежат в куче, как они распределены по поколениям. Можно посмотреть на внутренние структуры ASP.NET, на синхротаблицы объектов и многое другое…
К чему я клоню – встроенный отладчик Visual Studio по сравнению с WinDbg – просто неумелое дитя. Хотя – тсс, никому не говорите – в Visual Studio при помощи окна Immediate тоже можно загружать и использовать sos.dll.. Но, хотя дамп процесса проанализировать в ней можно, интеграции с sos.dll у Visual Studio нет, да и среда не столь заточена под ручную работу.
На заметку: Чтобы открыть дамп процесса в Visual Studio, нужно сказать File->Open Project и указать тип проекта как "Dump File". После этого дамп-файл откроется в IDE и можно будеть зайти в режим отладки (Debug this Instance), в котором доступна часть функциональности WinDbg на уровне пользовательского интерфейса (Окна Stack Trace, Threads, Memory и др.)
Удачи в отладке!
Версия 1.1
Ю.Скалецкий, 21 сентября 2007
http://yuryskaletskiy.blogspot.com/
История:
23 sep - версия 1.1: Оказывается, в Visual Studio тоже есть возможность анализировать дампы.

Не забыть! проект subsonic

http://www.subsonicproject.com/ - очередной DAL framework, в этот раз базированный на Ruby on Rails. Надо посмотреть, что там ребята наворотили...

"What is it?
A Super High-fidelity Batman Utility Belt. SubSonic works up your DAL for you, throws in some much-needed utility functions, and generally speeds along your dev cycle."

Вложенные web.config-и

Искал-искал, как сделать аналог include в app/web .config - и наконец нашел. Начиная с .Net 2.0 у конфигурационных тегов есть малоизвестный атрибут configSource.

Вот что о нем написано на MSDN: http://msdn2.microsoft.com/en-us/library/ms228167(VS.80).aspx

Script#

НЕ МОГУ ПОВЕРИТЬ

существует компилятор C# -> JavaScript

http://www.nikhilk.net/ScriptSharpIntro.aspx

Это может быть убийцей Google Web Toolkit :-)

Скачал, засел разбираться...

UPD: http://code.google.com/p/extsharp/ - C# programming for ExtJS

Command Line Arguments Parser

UPDATE Feb.09
Выложил парсер командной строки, которым мы пользуемся, в Google Code:
http://code.google.com/p/commandlineargs/

Собственно, сам пост

Разбираясь с исходниками NUnit, наткнулся на любопытный способ разбора параметров командной строки.

Вообще-то, не могу понять, почему в .Net Framework не предусмотрели классов для парсинга командной строки. Банальный же массив string[] args, который передается в Main(), для серъезного дела вообще никак не подходит. Вот и пишет каждый разработчик себе такой класс самостоятельно, потому что дело вроде плевое и импортить что-то чужое не хочется. Я вот тоже писал, и не раз.
Что нужно хорошему парсеру аргументов командной строки? Несколько вещей, на мой взгляд:
- поддержка опции /help. То есть утилита должна напомнить пользователю, как ее правильно вызывать
- поддержка именованных параметров, вне зависимости от очередности их расположения в строке вызова. То есть util.exe /console /admin должен интерпретироваться так же, как и util.exe /admin /console
- грамотная валидация. То есть утилита должна объяснить пользователю, что он ввел не так

Так вот, в NUnit используется класс Codeblast.CommandLineOptions. В нем используется интересный подход, суть которого в следующем:

Разработчик command line утилиты создает наследник класса CommandLineOptions, в котором описывает требуемые параметры командной строки просто как properties. Такие properties он помечает специальным атрибутом Option("..."), указывая описание свойства, которое потом автоматически сгенерируется и покажется пользователю.

Авторы (Gert Lombard и James Newkirk) в коментариях к коду дают вот такое описание возможных параметров:

// I define 3 types of "options":
// 1. Boolean options (yes/no values), e.g: /r to recurse
// 2. Value options, e.g: /loglevel=3
// 2. Parameters: standalone strings like file names
//
// An example to explain:
// csc /nologo /t:exe myfile.cs
//
// + parameter
//
// + value option
//
// + boolean option

Вот так этот класс применяется в NUnit console runner. Посмотрите на диаграмму классов:



Пользоваться таким парсером очень просто:

ConsoleOptions options = new ConsoleOptions(args);

if(!options.nologo)
WriteCopyright();

if(options.help)
{
options.Help();
return 0;
}

Решение, на мой взгляд, простое и зрелое - проверяется безопасность типов (при парсинге args[] проверяется PropertyInfo требуемых свойств) и использующему параметры коду уже не нужно беспокоиться об парсинге строковых значений, как это бывает в не столь красивых парсерах. Плюс к тому - описывать набор принимаемых параметров через атрибуты очень удобно.

Во всем этом великолепии, на мой взгляд, не хватает всего пары вещей

• Декларативного описания правил валидации. Ну например, через атрибут RequiredOption().
• Множественных layout-ов, когда в зависимости от значения какого-нибудь параметра изменяются требования к наличию-отсутствию других параметров. Можно сделать, например, через дерево классов-наследников CommandLineOptions.
• Неименованных параметров, чтобы можно было бы сделать так: util.exe /update Module1/src

Как пользоваться LINQ или MS DAL

Ссылка на историю в 3-х частях о том, какой будет ORM DAL в .Net vNext

1. http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
2. http://weblogs.asp.net/scottgu/archive/2007/05/29/linq-to-sql-part-2-defining-our-data-model-classes.aspx
3. http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx