От уже декілька тижнів я працюю в новій компанії, що означає не тільки зміну обстановки і оточуючих тебе людей, а й зміну робочого (читай "віртуального") середовища. Про одну з таких змін я зараз розкажу і можливо воно збереже комусь 2-3 години робочого часу.

В попередній організації у нас в SVN був такий собі репозиторій "tools" в якому знаходились різноманітні допоміжні програмки (зокрема NAnt). Кожен девелопер мав локальну копію цього репозиторію, обновляв його час від часу і використовува що було необхідно.

А на мому теперішньому місці праці, нажаль, такого ніхто не додумався зробити. От я і взявся "пофіксити цю багу". Хоча, а що там такого робити? Створити директорію, скопіювати все що треба, закомітити в SVN і готово :) Єдине чого я не врахував, це OS на якій ми працюємо. Раніше у мене була Windows Server 2003, а тут Windows 7. Одна з основних їх відмінностей - це система безпеки. У Windows 7 всі скачані файли (Інтренет чи SVN не грає ролі) будуть помічені як небезпечні і будуть виконуватись з пониженими правами. Так от, якщо я раніше на WinServer 2003 запускав скачаний з SVN NAnt без проблем, то тепер у мене він "вилітав" з помилкою:

Мені, як і більшості девелоперів, приходиться повторювати "ритуал" створення локального веб-сайту на власній девелопмент-машині час від часу, і буває що я забуваю про один з кроків. Тому цей пост буде швидше простим нагадуванням для мене ніж чимось новим для community. Хоча, сподіваюсь, що для когось це також стане непоганою покроковою інструкцією на початку його кар'єри.

І так, допустимо, що на компютері вже встановлено:

• Windows 7
• IIS
• MS SQL Server

Всі дії я проводив через GUI, проте вони можуть бути виконані і через командну строку і/або Powershell.

Новий користувач

Першим кроком необхідно створити нового користувача для нашого майбутнього веб-сайту. Звичайно, не заборонено працювати і під локальними правами, але я вважаю це поганою практикою + такого ніколи не трапляється у Production-середовищі.

Відкрийте "Computer Management" консоль і знайдіть там "Local Users and Groups". Після чого правим кліком по "Users" ви зможете викликати контексне меню і через пункт "New User..." створити нового користувача:

Не забудьте помітити чекбокси "User cannot change password" та "Password never expires".

Після збереження всіх змін, відкрийте вікно "Properties" новоствореного користувача. Там вам потрібно буде видалити всі групи до яких він належить і додати його у групу "IIS_IUSRS":

Новий веб-сайт

Для того щоб створити новий веб-сайт потрібно в уже відомій вам "Computer Management" консолі знайти "Internet Information Services", перейти до списку "Sites" і там створити новий веб-сайт:

Закінчивши клікніть по кнопці "Connect as..." і введіть логін та пароль користувача створеного попередньо:

Клікаємо на "ОК", знову "ОК" і перевіряємо чи все працює (кнопка "Test Settings..."):

Буває, що з "Authorization" виникають проблеми. У такому випадку необхідно у властивостях директорії, де розміщений веб-сайт, змінити настройки безпеки і дозволити користувачу з попереднього пункту читати/зберігати данні у цій директорії.

Сподіваюсь до цього моменту все пройшло без проблем і ми можемо спокійно додати URL нашого творіння у локальний "hosts"-файл, щоб броузер не шукав його, як виразився один коЛЛЄга, "по всіх інтернетах"

Прошу звернути увагу на те, що для модифікації цього файлу у Win7 вам знадобляться права адміністратора.

В загальному, на цьому можна закінчити цей короткий пост для тих, хто не планує використовувати Windows-аутентифікацію для роботи з Sql Server. Якщо ж ви все-таки хочете скористатись всіма багами благами, то ласкаво прошу витратити ще 5 хвилин вашого дорогоцінного часу і дочитати все до кінця.

Новий користувач у Sql Server

Підключіться до вашого MS SQL Server з допомогою "Microsoft SQL Server Management Studio", перейдіть до списку логінів (Security > Logins) та відкрийте діалог створення нового логіну:

Після цього введіть всю необідну інформацію у вкладці "General", але НЕ зберігайте зміни:

Тепер переходимо на вкладку "User Mapping":

Тут необхідно вказати БД до якої наш користувач зможе звертатись і його права. На завершення перевіримо вкладку "Status", щоб упевнитись, що ми успішно зможемо залогінитись та працювати:

Зберігаємо!

Якщо все було зроблено правильно, то у списку користувачів нашої БД має зявитись новий користувацький запис:

The end!

• без "прогріву" час очікування відповіді від сервера (у Firefox) ~8-10 секунд (час рендеру стрінки не враховується)
  
• час виконання HTTP GET функції перший раз ~7 секунд, всі наступні - практично миттєво
• час очікування відповіді від сервера (у Firefox) після "прогріву" ~5-7 секунд, всі наступні - практично миттєво

Для тих хто не хоче перечитувати всі коментарі в темі на StackOverflow, постараюсь стисло передати всю їх суть:

1. як "золоту середину" було запропоновано рішення з 2 методами один з яких приймає string, а інший FileInfo
2. особливо оптимістично налаштовані вирішили, що використання Stream має вирішити  всі проблеми
3. тільки один з учасників читає MSDN :) саме він і запостив, на мою думку, найбільш інформативний коментар ("The difference is primarily that there is a little bit of checking going on; the FileInfo constructor does some checking for a null or clearly invalid parameter...")

Тепер декілька слів по кожному з пунктів:

1. Створювати два методи (які будуть практично ідентичні!) тільки для того щоб всі залишились задоволеними - це якось тупо... і "попахує" добре відомою американською політкоректністю :)
2. у випадку передачі Stream як аргумента без гострої на те необхідності - на кодревю зразу ж потрібно перевіряти справку від психіатра
3. а от почитати MSDN + подивитись Reflector-ом всередину конструктора FileInfo і аргументувати його (не)використання - це досить-таки непогана ідея!

І так, ось що можна побачити всередині конструктора:

[code language="C#"]
        public FileInfo(string fileName)
        {
            if (fileName == null)
            {
                throw new ArgumentNullException("fileName");
            }
            base.OriginalPath = fileName;
            string fullPathInternal = Path.GetFullPathInternal(fileName);
            new FileIOPermission(FileIOPermissionAccess.Read, new string[] {fullPathInternal}, false, false).Demand();
            this._name = Path.GetFileName(fileName);
            base.FullPath = fullPathInternal;
        }
[/code]

Коротке пояснення коду:

• спочатку йде перевірка на null (до речі, в когось є ідеї чому "fileInfo" не перевіряється на пусту строку?) - це ясно
• всередині "Path.GetFullPathInternal(fileName)" проходить валідація шляху до файлу + отримання повного шляху в разі, якщо "fileName" - це відносний шлях  (ага! а от перевірка на пусту строку :) )
• перевірка прав на читання - на мою думку, одна з осносних причин чому варто використовувати FileInfo
• виклик "Path.GetFileName(fileName)" просто перевіряє шлях до файлу на invalid-символи

Як бачимо, нічого надзвичайного :)
Переваги в порівнянні з методом який використовує string-аргумент очевидні:
- "халявна" перевірка шляху на валідність
- перевірка прав перед читанням (про це постійно забувають), а значить можна спростити код обробки помилок в процесі самого читання

Недоліки:
- виклик методу з kernel32 для отрмання повного шляху і перевірка прав доступу займає якийсь час, хоча не думаю що це критично

FYI:
Атрибути і вся інша інформація підгрузиться тільки в момент коли це справді необхідно, тому про додаткові витрати ресурсів хвилюватись не варто.

Як на мене, я бачу більше "плюсів" при використанні FileInfo - додаткові халявні перевірки (в межах розумного) ніколи не бувають лишніми :)

The end

P.S.: Якщо хтось бажає додати "за/проти" кожного з методів, розказати байку про їх використання або просто висказати своє "+1" - прошу в коменти