Мы используем диспетчер ресурсов .NET для локализации нашего приложения Silverlight и хотим встроить сателлитные сборки для немецкого языка ("de") в файл XAP. Для этого мы установили нейтральный язык «en» и добавили «de» в список поддерживаемых языков в файле csproj. Это прекрасно работает, когда мы строим проект локально. Если мы создадим решение Silverlight с MSBuild (TFS), Silverlight попытается извлечь спутниковые сборки с HTTP-запросами из /ClientBin/de/*.dll вместо того, чтобы помещать эти файлы в XAP (которые существуют). Поскольку веб-сервер возвращает 404 кода ошибки для несуществующих файлов, происходит сбой Silverlight с ошибкой инициализации.
Оказалось, что если мы удалим пользовательскую операцию сборки TFS, манипулируя файлами кода информации о сборке, приложения Silverlight будут работать как положено. Как ни странно, после повторного включения действия скомпилированное приложение XAP все еще работает (проверено на наличие двух разных определений сборки, работающих на отдельных ветвях). Настраиваемое действие управляет атрибутами сборки AssemblyConfiguration, AssemblyCompany, AssemblyProduct, AssemblyCopyright, AssemblyTrademark, AssemblyVersion и AssemblyFileVersion.
Некоторые дополнительные советы:
- Пользовательское действие изменит файлы информации о сборке до того, как будет выполнена любая компиляция
- Компиляция управляемых источников с помощью Visual Studio создаст работающий XAP
- Содержимое файлов XAP (работающих и не работающих) одинаково (почти одинакового размера, без различий в файле манифеста)
- Администратор ресурсов создается с использованием
ResourceManager("Resource", Assembly.GetExecutingAssembly())
Мои вопросы:
- Почему Silverlight пытается извлечь эти спутниковые сборки из
/ClientBin/de/ вместо того, чтобы просто использовать их в файле XAP?
- Какой тип атрибута в файле сведений о сборке может вызвать такое поведение?
- Почему повторное включение управления версиями не нарушает XAP снова?