Алексей Немиро

Первое:
Лучше изначально строить структуру проекта так, чтобы файловое хранилище было независимым и при высоких нагрузках не валило основной сайт, и чтобы в будущем было проще масштабировать проект.

Проще говоря, как минимум следует использовать разные домены/сайты для хранилищ файлов.

Например, основной сайт:
example.org
А хранилище файлов:
storage1.example.org

Даже размещая основной сайт и хранилище(а) на одном сервере, можно будет распределить нагрузку между проектами.

Тогда и проблема с mime отпадет сама собой.

Второе: Если файлы выдаются серверным кодом, то достаточно добавить заголовок Content-Disposition, чтобы браузер предложил пользователю скачать файл:

Response.AddHeader("Content-Disposition", "attachment; filename=123.gif");

Шаблон может быть такой:
[A-Za-z]{1}[0-9]{1}

Более строго, с начала строки и до конца:
^[A-Za-z]{1}[0-9]{1}$

[A-Za-z] - буквы в заданном диапазоне, можно заменить на необходимый набор символов.
[0-9] - числа от нуля до девяти, равносильно \d
{1} - строго один символ.
^ - в данном случае - начало строки.
$ - конец строки.

Одна буква и много чисел:
^[A-Za-z]{1}\d+$
+ - один или более символов.

Если я правильно понял вопрос, то можно заменить на пустоту символы, которые подходят под шаблон. А те что останется и будут "запрещенными символами".

if (preg_match('/^[a-zA-Z\p{Cyrillic}\d\_\-]+$/u', $str) === 0) {
    echo "Некоторые символы не смогли пройти испытание: ".preg_replace('/^[a-zA-Z\p{Cyrillic}\d\_\-]+$/u', '', $str); 
   // по шаблону, не уверен, возможно потребуется убрать границы: ^ и $
}

Провайдер видит все, логин и пароль.

По протоколу HTTP все данные передаются как есть, в открытом виде.

Другое дело, что ссылки подобного формата могут попасть не только в руки провайдера, но и других лиц. Трафик украсть чуток сложнее. Лучше использовать HTTPS. И рекомендуется избегать использования ссылок, в которых содержится пароль, просто для исключения ошибок со своей стороны (например, от банальной усталости или невнимательности). Простым пользователям это вообще нельзя показывать, для их же безопасности.

В MSDN поиск не удобный, но с этой задачей неплохо справляется Google.

Локальное средство просмотра Microsoft Help, по сути, будет тоже самое, с тем лишь отличием, что информация может храниться локально.

Свежее данных, чем в MSDN, в любом случае не найти.
Формат документации за последнее время стал заметно лучше и понятней. Вот раньше было совсем все плохо :)

А как же Великая и ужасная (технология) ASP .NET? Почему нет в списке? ;-)

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

Я бы рекомендовал сделать акцент на ООП.
PHP может быть объектно-ориентированным, но может и не быть, если лень или недостаточно знаний.

Если говорить об ASP .NET, то тут без ООП не обойтись. Хочешь не хочешь, придется работать с объектами/классами и прочими сопутствующими вещами.

ASP .NET позволяет программировать на Visual Basic .NET и C#. Изучив один из этих языков можно будет создавать приложения для Windows и Windows Phone, всякие библиотеки и компоненты. В общем, много чего можно будет делать.

Сложные и большие проекты делать в ASP .NET проще, чем на PHP (мне доводилось работать и с тем и другим). Раньше у PHP было преимущество в доступности и дешевизне. Сейчас такого преимущества нет. Технология .NET за поседение годы стала доступней. Сервера и хостинг под Windows по стоимости не уступает Linux. Основная среда разработки под .NET - Visual Studio потихоньку становится совсем бесплатной, былые ограничения постепенно уходят в историю, хотя даже с ограничениями многое можно реализовывать гораздо быстрее и проще.

Проще - это не значит, что все будет совсем просто. Придется приложить определенные усилия и потратить уйму времени на изучение. Но оно того стоит.

Придется делать конструктор в FileMember, который будет принимать Grid и строить себя на его основе. В этом случае связь с исходным объектом потеряется (если критично).

Как вариант, можно убрать наследование и сделать в FileMember свойство, принимающее Grid. Будет проще передавать Grid в FileMember :) Но придется изрядно доработать FileMember, чтобы он вел себя как Grid. По сути тупая переадресация будет (но подводные камни исключать нельзя, все может оказаться сложнее).

В итоге нужно выбрать, что будет проще: копировать исходный Grid в FileMember; или определить все свойства, методы Grid и т.п. в FileMember; или отказаться от идеи передавать Grid, использовать только FileMember, изменить исходную задачу на вариант с более простым решением.