InvalidOperationException: Не удалось найти "UserSecretsIdAttribute" на сборке

Ответ 1

Недавно появилось обновление модуля секретов пользователей. В версии 1.0.1 и выше теперь требуется указать атрибут уровня сборки для идентификатора секретов пользователя или в качестве резервной копии, как это было ранее в project.json.

Вот объявление на GitHub: https://github.com/aspnet/Announcements/issues/209

Вы можете определить id секретов в .csproj следующим образом:

<PropertyGroup>
  <UserSecretsId>aspnet-TestApp-ce345b64-19cf-4972-b34f-d16f2e7976ed</UserSecretsId>
</PropertyGroup>

Это генерирует следующий атрибут уровня сборки. В качестве альтернативы вместо добавления его в файл .csproj вы можете, конечно, добавить его самостоятельно, например. к Startup.cs:

[assembly: UserSecretsId("aspnet-TestApp-ce345b64-19cf-4972-b34f-d16f2e7976ed")]

Кроме того, вы должны использовать:

builder.AddUserSecrets<Startup>();

Он будет искать этот атрибут в сборке данного типа, в этом случае я использовал класс Startup.

Примечание: это будет устаревшим в 2.0: (1.0.2 и 1.1.1 отметили его устаревшим)

builder.AddUserSecrets();

Я проверил исходный код для конфигурации секретов пользователя и вызвал AddUserSecrets() без этого типа:

var attribute = entryAssembly.GetCustomAttribute<UserSecretsIdAttribute>();
if (attribute != null)
{
     return AddUserSecrets(configuration, attribute.UserSecretsId);
}

// try fallback to project.json for legacy support
try
{
     var fileProvider = configuration.GetFileProvider();
     return AddSecretsFile(configuration, PathHelper.GetSecretsPath(fileProvider));
}
catch
{ }

// Show the error about missing UserSecretIdAttribute instead an error about missing
// project.json as PJ is going away.
throw MissingAttributeException(entryAssembly);

Он пытается найти атрибут UserSecretsId на вашей сборке и не сможет этого проверить, может ли он найти его в project.json. Затем (как прокомментировано) возвращает ошибку об отсутствующем атрибуте, поскольку они больше не хотели бы жаловаться на project.json, поскольку он устарел.

Ответ 2

Я хочу добавить к этому ответ для тех, кто в моей ситуации.

Я пишу консольное приложение .NET Core, пытаясь использовать менеджер секретов (не уверен, что это предназначено для консольных приложений). Единственный способ, которым я смог избавиться от ошибки, - это использовать атрибут уровня сборки на сборке, где я использовал менеджер секретов.

Как я уже сказал, я не уверен, предназначен ли менеджер секретов для консольных приложений. Так что, возможно, есть проблема с файлами .xproj и .csproj.