В след за выходом очередных версий студии и фреймворка вышли обучающие материалы по данным технологиям.
Скачать можно щелкнув по этой ссылке.

В состав обучающих материалов входят презентации, лабораторные работы, демонстрационные примеры на следующую тематику:

• C# 4.0
• Visual Basic 10
• F#
• Parallel Extensions
• Windows Communication Foundation
• Windows Workflow
• Windows Presentation Foundation
• ASP.NET 4
• Windows 7
• Entity Framework
• ADO.NET Data Services
• Managed Extensibility Framework
• Visual Studio Team System
  

К тому же на потрале Channel 9 в разделе обучений http://channel9.msdn.com/learn/  появилось 2 онлайн тренинг-курса
1) Visual Studio 2010 and .NET Framework 4 Training Course
2) Windows 7 Online Training

Всем приятного изучения новых технологий.

Ссылки по материалу:

• Training Kit for VS2010 and .Net Framework 4.0 beta 2.
• Info about training kit
  
• http://channel9.msdn.com/learn/

Да, это так! Ранее уже сообщалось о том, что 28 октября нас ожидает русскоязычная версия этого продукта. И ОНИ сдержали свое слово.

Сейчас для всех желающих доступен обновленный выпуск библиотеки MSDN.  В этот выпуск включены следующие обновленные наборы содержимого:

• Документация Visual Studio 2008
• Документация для разработчиков Windows Vista
• Документация по набору драйверов Windows (WDK)
• Документация по Microsoft Office 2007
• База знаний Майкрософт
• И многое другое.

Прочитать описание продукта и скачать его можно пройдя по этой ссылке.  Также можно воспользоваться прямой ссылкой на закачку.

Русскую версию можно поставить параллельно с английской. Они абсолютно не конфликтуют. Кого заинтересовало - дерзайте!

На сайте семинаров TechDays.ru появился интересный доклад Виталия Зайко на тему локализации Visual Studio 2008 и MSDN. Виталий рассказывает, что очень скоро нас ожидают русские версии этих продуктов. Лично меня очень обрадовала эта новость касательно библиотеки MSDN. Большинство программистов и так непхоло читают на английском, но русская версия позволит быстрее прочитать и понять суть искомой задачи.

Как утверждает докладчик, локализованные версии Visual Studio и MSDN станут доступны 28 октября этого года.

Кому интересно, те могут посмотреть доклад по адресу:
http://www.techdays.ru/Lecture.aspx?LID=fde4ba9d-f02e-470d-b6a2-f69cc4386bb2

В нем рассказывается об особенностях локализации, затраченных ресурсах и как все это можно будет скачать. А также продеменострирована работа в русских версиях данных продуктов.

Как я уже писал в одном из своих предыдущих постов, стал доступен очередной релиз StyleCop.

Обновление включает:

• Различные фиксы, включая задачи интеграции c Visual Studio
• Документация с правилами теперь включена и интегрирована в Visual Studio в меню "Show Error Help"
• Добавлены новые правила
• Бренд Source Analisys сменился на StyleCop

Также меня порадовало то, что теперь StyleCop работает с веб-проектами, созданными как  Web Site. Напомню, что ранее StyleCop проверял только те веб-приложения, которые создавались как Web Application.

Ниже приведен небольшой список новых правил, вошедших в StyleCop 4.3:

• Требование сортировать директивы using
• Требование использовать встроенные алиасы типов для int, string, float и т.д.
• Требование стандартного текстового описания для конструкторов и деструкторов
• Требование использовать String.Empty вместо ""
• Запрет использования регионов внутри тела методов
• Запрет использования регионов вообще (данное правило по-умолчанию выключено)
• Запрет использования пустого статического конструктора
• Запрет ненужных или пустых блоков try\catch\finally

Кроме этого, как и обещалось ранее, стал доступен SDK для StyleCop. В котором объясняется:

• как создавать и устанавливать собственные StyleCop-правила
• как интегрировать кастомные настройки в диалог настроек StyleCop'а
• а также описано как интегрировать StyleCop в произвольную среду для сборки кода

Напомню, что StyleCop не является официальным продуктом Microsoft, так что используйте SDK на свой страх и риск :-)

Скачать все это можно пройдя по этой ссылке.

Также ниже приведены прямые ссылки на закачку:

• Инсталлятор StyleCop
• Документация
• SDK

 

На кодеплексе есть такой проект как WCF Security Guidance Project, о котором уже сообщалось ранее в блоге Сергея Лутая. Данный проект состоит из набора обучающего видео, вопросов и ответов, практических рекомендаций, и т.п. по защите распределенных приложений, построенных на базе технологии WCF.

Спешу сообщить, что команда Microsoft Patterns & Practices совместно с командой вышеуказанного проекта выпустили первый релиз WCF Security Guide - руководства по обеспечению безопасности приложений, использующих технологию WCF.

Руководство состоит из 4-х разделов:

1. Основы безопасности Web Service'ов;
2. Основы безопасности WCF;
3. Сценарии внедрения WCF в Intranet-приложения;
4. Сценарии внедрения WCF в Internet-приложения;

Также в руководство вошли все наработки WCF Security Guidance Project: How To, Q&A, Guidelines, практики применения. В руководство не вошли видео-ресурсы, видимо по причине того, что руководство является книгой в формате PDF.

Возможно, кого-то огорчит, что книга на английском языке, но текст не сложный и с картинками .

Скачать руководство можно со странички авторов. Также можно щелкнуть по этой ссылке и подтвердить свои намерения.

В последнее время появилось достаточно много путаницы вокруг такого продукта от Microsoft как StyleCop. Он появился относительно недавно и был представлен как инструмент анализа кода. В сообществе VSTS было очень много шума о том, как новый инструмент связан с FXCop и встроенной в студию утилитой Code Analysis. Спрашивается зачем создавать еще один инструмент, делающий то же самое?

По словам команды разработчиков VSTS продукт StyleCop разработан программистом из другого подразделения Microsoft. Имя этого человека Jason Allor. Он и его команда создали инструмент, который в чем-то повторяет FxCop и Code Analysis. Но в то же время делает вещи, которым вышеупомянутые утилиты не уделяют внимания. StyleCop является инструментом, контролирующим стиль кодирования, проверяющим форматирование кода. А также следит за тем, чтобы исходный код соответствовал соглашениям о стиле кодирования. StyleCop в отличие от FxCop не делает глубокого анализа, такого как проверка на безопасность, наличие корректных обработок "узких" мест и т.п. Еще одним важным отличием является то, что FXCop работает со статическим кодом, т.е. с готовой сборкой, в то время как StyleCop работает над кодом, который вы пишете в текущий момент.

Разработчики данной утилиты предупреждают, что это продукт не Microsoft и даже не Team System Power Tool. Этот инструмент разрабатывался страстным программистом из Microsoft по вечерам и выходным. StyleCop не имеет полноценной службы поддержки, обслуживания и сопутствующих услуг по выше указанной причине (т.к. на разработку уходит всего лишь свободное время программиста).

Подводя итог, приведу выдержку из блога команды разработчиков StyleCop:

StyleCop ‒ не часть VS Code Anasysis и даже была разработана не командой разработчиков VS. Утилита основное внимание уделяет проверке и контролю соблюдения правил стиля кодирования. Для того, чтобы убрать некоторые путаницы, мы уходим от имени, "Source Analysis" и будем обращаться к инструменту с этого времени как StyleCop, что является оригинальным названием инструмента! Мы планируем выпустить обновление, которое будет включать изменение имени, и исправление ошибок, обнаруженных сообществом после первого релиза. Этот выпуск будет также включать часть новых правил, которые не вошли в первый выпуск, а также другие предложения от сообщества. Мы выпустим небольшой SDK для инструмента, с описаниями интерфейсов расширяемости для создания собственных наборов правил. Также в SDK будут включены объяснения того, как использовать инструмент в различных утилитах, предназначенных для сборки кода. Мы выпустим документацию, описывающую все правила по умолчанию.

Статья написана по материалам блога Brian Harry - ведущего технического сотрудника команды VS TFS

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

[PathTooLongException]: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Со своей стороны мы могли бы сказать заказчикам, что не получается сохранить файл с таким названием, т.к. это ограничение системы. Но наши заказчики, увидев данное сообщение, скорее всего скажут: "260 символов? Это же смешно! Увеличьте ограничение!"

.NET API очень сильно завязан на Windows API, поетому может показаться, что данную проблему не решить, т.к. сама Windows не дает оперировать с путями к файлам более 260 символов. Однако, Windows API все же предоставляет нам методы для обхода данного ограничения. Если перед путем к файлу поставить префикс "\\?\" и вызвать Unicode-версию функции Windows API, то можно использовать пути к файлам длиной до 32K символов.

Сейчас мы рассмотрим как работать с файлами, путь к которым более 260 символов, а потом поговорим о возможных проблемах и ограничениях.

Работа с длинными путями к файлам

Для примера создадим консольное приложение. Нам понадобятся такие пространства имен:

using System; using System.IO; using System.Text;

Далее создадим две функции: для записи и чтения файла:

Функция WriteFile сохраняет файл с заданным именем и записывает в него информацию о количестве символов в его названии:

static void WriteFile(string fileName) {     using (FileStream fs = new FileStream(fileName, FileMode.Create))     {         string text = string.Format("FileName Length: {0} symbols", fileName.Length);         byte[] bytes = Encoding.Default.GetBytes(text);        fs.Write(bytes, 0, bytes.Length);     } }

Функция ReadFile читает и выводит на консоль содержимое файла:

static void ReadFile(string fileName) {     using (FileStream fs = new FileStream(fileName, FileMode.Open))     {         int c;         while (fs.Position < fs.Length)         {             c = fs.ReadByte();             Console.Write((char)c);         }     } }

В методе Main() попробуем вызвать эти функции:

static void Main(string[] args) {     // имя файла 250 символов     string fileName = @"C:\very_long_file_name_" +         "0000003000000000400000000050000000006" +         "0000000007000000000800000000090000000" +         "1000000000001000000000200000000030000" +         "0000040000000005000000000600000000070" +         "0000000080000000009000000020000000000" +         "010000000002000000000300000000040000000005";     Console.WriteLine("Write file...");     WriteFile(fileName);     Console.WriteLine("Read file:");     ReadFile(fileName);     Console.Read(); }

Запустим программу на выполнение и проверим, что все хорошо работает:

Теперь модифицирум метод Main():
создадим на диске C: директорию с названием "very_long_file_name_in_this_directory" и немного изменим переменную, которая хранит имя файла. Сейчас путь к файлу будет состоять из 288 символов:

static void Main(string[] args) {     string directoryName = @"C:\very_long_file_name_in_this_directory";     if (! Directory.Exists(directoryName))     {         Directory.CreateDirectory(directoryName);     }         // имя файла 288 символов     string fileName = directoryName + @"\very_long_file_name_" +         "0000003000000000400000000050000000006" +         "0000000007000000000800000000090000000" +         "1000000000001000000000200000000030000" +         "0000040000000005000000000600000000070" +         "0000000080000000009000000020000000000" +         "010000000002000000000300000000040000000005";     Console.WriteLine("Write file...");     WriteFile(fileName);     Console.WriteLine("Read file:");     ReadFile(fileName);     Console.Read(); }

Запустив приложение на выполнение, мы получим сообщение об ошибке:

[PathTooLongException]: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

Для решения данной проблемы мы воспользуемся Win32 API функкцией CreateFile.
Для начала добавим два пространства имен:

using System.Runtime.InteropServices; using Microsoft.Win32.SafeHandles;

Далее добавим вспомогательные перечислители и битовые флаги (для того, чтобы не передавать в параметры метода непонятные числовые значения):

[Flags] public enum EFileAccess : uint {     GenericRead = 0x80000000,     GenericWrite = 0x40000000,     GenericExecute = 0x20000000,     GenericAll = 0x10000000, } [Flags] public enum EFileShare : uint {     None = 0x00000000,     Read = 0x00000001,     Write = 0x00000002,     Delete = 0x00000004, } public enum ECreationDisposition : uint {     New = 1,     CreateAlways = 2,     OpenExisting = 3,     OpenAlways = 4,     TruncateExisting = 5, } [Flags] public enum EFileAttributes : uint {     Readonly = 0x00000001,     Hidden = 0x00000002,     System = 0x00000004,     Directory = 0x00000010,     Archive = 0x00000020,     Device = 0x00000040,     Normal = 0x00000080,     Temporary = 0x00000100,     SparseFile = 0x00000200,     ReparsePoint = 0x00000400,     Compressed = 0x00000800,     Offline = 0x00001000,     NotContentIndexed = 0x00002000,     Encrypted = 0x00004000,     Write_Through = 0x80000000,     Overlapped = 0x40000000,     NoBuffering = 0x20000000,     RandomAccess = 0x10000000,     SequentialScan = 0x08000000,     DeleteOnClose = 0x04000000,     BackupSemantics = 0x02000000,     PosixSemantics = 0x01000000,     OpenReparsePoint = 0x00200000,     OpenNoRecall = 0x00100000,     FirstPipeInstance = 0x00080000 }

Добавим описание Win32 API функции CreateFile, указав в параметре CharSet, что нам нужна Unicode версия этой функции:

[DllImport("kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)] internal static extern SafeFileHandle CreateFile (     string lpFileName,     EFileAccess dwDesiredAccess,     EFileShare dwShareMode,     IntPtr lpSecurityAttributes,     ECreationDisposition dwCreationDisposition,     EFileAttributes dwFlagsAndAttributes,     IntPtr hTemplateFile );

Функция CreateFile возвращает файловый описатель (file handle), который можно передать конструктору FileStream.

Запись в файл

Сейчас мы перепишем метод WriteFile так, чтобы он мог работать с длинными именами файлов:

static void WriteFile(string fileName) {     string longFileName = @"\\?\" + fileName;         // Создадим файл с правами на запись     SafeFileHandle fileHandle = CreateFile         (   longFileName,             EFileAccess.GenericWrite,             EFileShare.None,             IntPtr.Zero,             ECreationDisposition.CreateAlways,             0,             IntPtr.Zero         );     // Проверка на ошибки     int lastWin32Error = Marshal.GetLastWin32Error();     if (fileHandle.IsInvalid)     {         throw new System.ComponentModel.Win32Exception(lastWin32Error);     }     using(FileStream fs = new FileStream(fileHandle, FileAccess.Write))     {         string text = string.Format("FileName Length: {0} symbols", fileName.Length);         byte[] bytes = Encoding.Default.GetBytes(text);         fs.Write(bytes, 0, bytes.Length);     } }

Чтение из файла

Выполнив метод WriteFile у нас создастся файл с длинным именем. Правда теперь его нельзя будет открыть ни одним редактором, разве что это программа также будет использовать синтаксис "\\?\" для открытия файлов.

Наш метод ReadFile не исключение и в текущем состоянии он будет "кидать" все тот же "PathTooLongException".
Сейчас мы его перепишем аналогично методу WriteFile, изменив права записи на чтение:

static void ReadFile(string fileName) {     string longFileName = @"\\?\" + fileName;     // Создадим файл с правами на чтение     SafeFileHandle fileHandle = CreateFile         (   longFileName,             EFileAccess.GenericRead,             EFileShare.None,             IntPtr.Zero,             ECreationDisposition.OpenAlways,             0,             IntPtr.Zero         );     // Проверка на ошибки     int lastWin32Error = Marshal.GetLastWin32Error();     if (fileHandle.IsInvalid)     {         throw new System.ComponentModel.Win32Exception(lastWin32Error);     }     using (FileStream fs = new FileStream(fileHandle, FileAccess.Read))     {         int c;         while (fs.Position < fs.Length)         {             c = fs.ReadByte();             Console.Write((char)c);         }     } }

Запускаем приложение на выполнение и видим, что файл прочитался, при чем длина его имени равна 288 символов:
 

Удаление файла

Если мы попробуем удалить существующий файл вручную, например, из Проводника, то у нас этого не получится, система скажет, что файл не найден. У нас также не получится удалить файл программно используя клас File, например так: File.Delete(fileName);

Для того, чтобы удалить файл с длинным именем нам необходимо воспользоваться Win32 API функцией DeleteFile.
Добавим ее объявление, указав, что нам нужна Unicode версия:

[DllImport("kernel32.dll", CharSet = CharSet.Unicode)] [return: MarshalAs(UnmanagedType.Bool)] internal static extern bool DeleteFile(string lpFileName);

Теперь создадим метод Delete(), который добавит префикс "\\?\" к имени файла и вызовет только что добавленную функцию DeleteFile:

static void Delete(string fileName) {     string longFileName = @"\\?\" + fileName;     DeleteFile(longFileName); }

Теперь, вызвав функцию Delete, можно удалять файлы с длинным названием.

Ограничения и недостатки данного подхода

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

Во-первых - безопасность. Префикс "\\?\" не только позволяет нам использовать длинные пути к файлам. Его применение включает минимальные права для модификации файловой системы. Этот префикс "выключает" нормализацию файлового имени, которая вызывается функциями Windows API, включая удаление концевых пробелов, использование синтаксиса "." и "..", конвертирование относительного пути в полный путь и т.п.

Во-вторых, не все Windows API функции поддерживают префикс "\\?\" . Например, если функция LoadLibrary получит путь к файлу более 260 символов, то будет сгенерировано исключение.

Еще одним фактором, который можно отнести к недостаткам, является совместимость с другими Windows-приложения и сама оболочка Windows, работающая только с путями к файлам меньше 260 символов. Это означает, что если ваше приложение поддерживает длинные пути, то совсем не обязательно, что другие программы смогут открыть ваши файлы. Тем более непосредственно из самой операционной системы такие файлы нельзя ни переименовать, ни скопировать, ни переместить и т.д.

 

Таким образом, если только ваше приложение будет работать со своими файлами, путь к которым очень длинный, то для решения такой задачи можно использовать описанный в этой статье подход. С другой стороны, если результатами работы вашего приложения должны пользоваться другие программы, то необходимо учесть ограничения данного подхода и по-возможности изменить логику сохранения файлов.

Ссылки по материалу: Статья в MSDN по именованию файлов: http://msdn2.microsoft.com/en-us/library/aa365247.aspx Статья в MSDN по использованию unmanaged функций: http://msdn.microsoft.com/en-us/library/w4byd5y4.aspx Вики-сайт сигнатур PInvoke. Поможет вам понять как использовать Win32 функции в вашем управляемом приложении: http://www.pinvoke.net/ Блог команды BLC: http://blogs.msdn.com/bclteam/default.aspx

Дорога к "Midori" вымощена большим количеством других кодовых названий от Microsoft. Такую информацию сейчас можно услышать о Midori - операционной системе следующего поколения от Microsoft.

Прежде, чем Microsoft представит бренд совершенно новой операционной системы, будь она распределенной, объектно-ориентированной и/или микроядерной - компания планирует выпустить некоторые новые компоненты, которые "проложат путь" к Midori. Сейчас известно о двух элементах: "Redhawk" и "MinSafe".

Redhawk и MinSafe - это две стороны одной и той же монеты. Redhawk - кодовое название нового управляемого кода, работу над которым ведет подразделение разработчиков (Developer Division), в то время как MinSafe - кодовое название дополнительного управляемого кода, который разрабатывает команда Windows.

Оба проекта нацелены на обеспечение новой среды выполнения управляемого кода, которая будет более меньшего размера и (как надеется Microsoft) более привлекательной для разработчиков, которые сталкиваются с накладными расходами, издержками текущей Common Language Runtime (CLR), основой .Net Framework.

Redhawk может включить в себя новый компилятор и новую среду выполнения, которая будет обеспечивать безопасность типов и сбор мусора, но возможно, не остальную часть функциональных возможностей, которые сейчас являются частью .Net CLR.

Команды Redhawk и MinSafe не ограничивают себя поддержкой совместимости с Windows или .Net Framework. (Ходят слухи, что Midori может быть "построена на пустом месте", не на базе операционной системы Windows, и вовсе не обязательно сохранит обратную совместимость с Windows.) Также команды Redhawk и MinSafe проявляют интерес к разработке новой объектной структуры на базе User Mode Driver Framework (UMDF), а также новой библиотеки базововых классов (BCL).

Ходят слухи, что наработки из Redhawk/MinSafe (определенно связанные с моделью драйверов) могут быть включены в Windows 8 - которая, если команда разработки Windows будет придерживаться расписания, выйдет в 2011/2012 гг.

Сейчас возникает очень много вопросов, основанных на вышеуказанной информации, но Microsoft пока не готова говорить о Midori, Redhawk или MinSafe.

Любопытно, как Microsoft работает над тем, чтобы обеспечить native (в противоположность managed) реализацию Веб-служб, которые Microsoft по-видимому подготавливает как часть Windows 7. Парни из AeroXP недавно описали эту платформу - о которой Microsoft планирует более детально рассказать на Профессиональной Конференции Разработчиков (PDC) в конце октября этого года. Платформа будет представлена как "WinFX минус .Net". Эту платформу описывают еще одним кодовым названием: "Sapphire".



Статья подготовлена по материалам блога Mary-Jo Foley.