Да, я знаю, что этот вопрос похож на C# - DLL «Ресурсы» не загружается, поскольку она не существует, но мой вопрос касается DLL, которой я не владею. Этот другой вопрос касается собственной DLL автора, которую они написали.
Обновлено: после решения проблемы оказывается, что это был точно такой же сценарий. Я сам пометил свой вопрос как дубликат.
Я пишу библиотеку C#, которая использует Cosmos DB .NET SDK 3.32.2. Иногда эта библиотека выдает исключение, потому что не может найти Microsoft.Azure.Cosmos.Direct.resources.dll
. Этот файл никогда не существовал; Cosmos.Direct
DLL поставляется с en-US
инвариантными ресурсами культуры, встроенными в DLL. Да, я декомпилировал его для проверки — похоже, что Cosmos.Direct
является частью SDK, который команда Cosmos не выпускала с открытым исходным кодом.
Чтобы было ясно, я не контролирую Microsoft.Azure.Cosmos.Direct.dll
. Это моя зависимость. К вашему сведению, пакет NuGet для Microsoft.Azure.Cosmos
поставляется с четырьмя библиотеками DLL, одна из которых — Microsoft.Azure.Cosmos.Direct.dll
.
FooBar.OurCustomExceptionType: One or more errors occurred. ---> System.AggregateException: One or more errors occurred. ---> System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\Foo\Bar\Microsoft.Azure.Cosmos.Direct.resources.dll' or one of its dependencies. The system cannot find the file specified.
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
at Microsoft.Azure.Documents.StoreResult.CreateStoreResult(StoreResponse storeResponse, Exception responseException, Boolean requiresValidLsn, Boolean useLocalLSNBasedHeaders, Uri storePhysicalAddress)
at Microsoft.Azure.Documents.StoreReader.<ReadMultipleReplicasInternalAsync>d__14.MoveNext()
... long stack trace ...
at FooBar.OurCustomCosmosWrapper`1.<GetItemAsync>d__4.MoveNext()
Глядя на трассировку стека, библиотека ищет «вспомогательную сборку» ресурсов, которых никогда не было, хотя ресурсы встроены в DLL.
Я настроил свое собственное приложение на использование [assembly: NeutralResourcesLanguage("en-US", UltimateResourceFallbackLocation.MainAssembly)]
в AssemblyInfo.cs, но очевидно, что это не влияет на эту библиотеку зависимостей Cosmos. Это влияет только на мою собственную сборку FooBar, которая зависит от Cosmos SDK.
Как заставить одну из зависимых библиотек DLL (в данном случае Microsoft.Azure.Cosmos.Direct.dll) использовать свои собственные встроенные ресурсы вместо того, чтобы пытаться найти отдельный файл resources.dll
, которого не существует?
Бьюсь об заклад, это может быть одной из нескольких проблем:
Мы решаем это внутренне, тогда я опубликую обновление, которое безопасно и имеет смысл для общедоступного сообщества SO. Я опубликовал это, надеясь, что сделал очевидную ошибку C#, возможно, даже не относящуюся к Cosmos.
Это была не вина Космоса; на самом деле у нас был обработчик AppDomain.AssemblyResolve, зарегистрированный где-то еще, который перехватывал загрузки сборок, даже если они были встроенными сборками, и пытался загрузить их из определенного места в виде файла .dll. Этот файл никогда не существовал, поэтому он потерпит неудачу.
Тот ТАК пост, который я изначально упомянул в своем вопросе? C# - DLL «Ресурсы» не загружается, поскольку она не существует
На самом деле это решило проблему. Просто найдите в своем репозитории AssemblyResolve
, проверьте, зарегистрирована ли для него функция обработчика, а затем убедитесь, что обработчик возвращает null
(или nullptr
, если в C++), когда встречает одну из ваших встроенных сборок ресурсов.
Можете ли вы описать, как вы развертываете свое приложение? Вы полагаетесь на Nuget для разрешения зависимостей или у вас есть собственная система, которая копирует/загружает библиотеки DLL? Можете предоставить репродукцию? Как выглядит ваш CSPROJ? Вы зависите от другого проекта, который также зависит от SDK? Как разрешается конфликт зависимостей, если он есть? Это не обычная ошибка и не то, о чем сообщалось на github.com/Azure/azure-cosmos-dotnet-v3/…