Здравствуйте shapkin, Вы писали:

S>А почему же у вас имена сборок генерятся? Если создать все по умолчанию, имя сборки будет совпадать с именем приложения.

Я, к сожалению, не могу ответить на этот вопрос.
Приведенный пример действительно сделан с нуля.
Для интереса еще раз повторил те же шаги, что описывал выше... Все по прежнему. И имена сборок почему-то генерируются автоматически...

Здравствуйте Аноним, Вы писали:

А>Тут можно не извращаться. Компилируешь свой resx файл в сборку, сборку ложишь в каталог bin проекта и наслаждаешся.

Я правильно понял, что нужно создать отдельный проект, состящий из некоторого количества ресурсов и скомпилированный его вариант подложить в тот каталог bin, где лежат dll-ки от веб-приложения?

Да, так можно, в принципе, сделать.
Но у меня при подобном решении вот какая возникла загвоздка: реально при выполнении кода веб-овские dll-ки копируются в некий временный каталог в Temporary ASP.NET Files.
С ресурсной же dll этого не происходит. И приходится для ее загрузки указывать полный путь. Нечто вроде:

System.Resources.ResourceManager rm = new System.Resources.ResourceManager( "resources.lang", System.Reflection.Assembly.LoadFrom( "D:/Projects/test/Bin/resources.dll" ) );
string strg = rm.GetString( "String1" );

Строчка-то считывается... Но привязываться к конкретному пути неправильно.

Или это у меня просто руки кривые?

Проблему удалось решить.
Дело было в следующем:
Дляопределения ассамблеи надо вместо кода

this.GetType().Assembly

пользоваться кодом

System.Reflection.Assembly.GetExecutingAssembly()