C # 7 представляет кортежи , поэтому вы можете сделать это:
var list = new List<(int id, string name)>();
list.Add((3, "Bob"));
var (id, name) = list[0];
var entry = list[0];
string s = $"{entry.name} has ID {entry.id}";
foreach (var (id, name) in list)
{
}
До C # 7 вы можете использовать старый тип Tuple
, который немного более грязный: [ 115]
var list = new List>();
list.Add(Tuple.Create(3, "Bob"));
foreach (var item in list)
{
int id = item.Item1;
string name = item.Item2;
}
Я столкнулся с этой проблемой не так давно. Короткий ответ заключается в том, что если вы запускаете 32-битное приложение на 64-битной машине, то его ключи реестра находятся в узле Wow6432Node.
Например, предположим, что у вас есть приложение, которое хранит свою информацию реестра в:
HKEY_LOCAL_MACHINE\SOFTWARE\CompanyX
Если вы компилируете свое приложение как 64-битный двоичный файл и запускаете его на 64-битном компьютере, тогда ключи реестра находятся в указанном выше месте. Однако, если вы скомпилируете свое приложение как 32-битный двоичный файл и запустите его на 64-битной машине, ваша информация реестра теперь находится здесь:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\CompanyX
Это означает, что если вы запустите как 32-битную, так и 64-битную версии вашего приложения на один и тот же компьютер, тогда каждый из них будет искать разные наборы ключей реестра.
Это не отдельные реестры - один является подузлом другого, и ОС выполняет виртуализацию, чтобы 32-битные приложения получали свои ключи, а 64-битные приложения получали свои ключи.
Я запускаю 64-битную машину в качестве рабочего стола; и я никогда не сталкивался с какими-либо проблемами с различными конфигурациями реестра.
Согласно MSDN, очевидно, есть разница: http://msdn.microsoft.com/en-us/library/ms724072 (VS.85) .aspx
НТН
Вот статья в Википедии о реестре WOW64, которая может дать вам некоторую информацию, которую вы ищете:
Ваше понимание правильное. Приложению x64 не нужно будет обращаться к идентификаторам CLSID x86, поскольку оно никогда не сможет загрузить эти компоненты, и наоборот.
Если вы хотите создать компонент для использования как x86, так и x64, вам нужно либо создать пара DLL, одна построенная для x86, а другая для x64, и зарегистрируйте обе в соответствующих частях реестра. Regsrv32.exe в папке System32 неправильно зарегистрирует компонент x64 и regsrv32.
Как зарегистрировать сборку .NET для использования в качестве COM в чисто 64-битном приложении?
Проблема: По умолчанию, если вы включите «Регистрация для COM-взаимодействия» в настройках сборки, библиотека типов НЕ регистрирует для 64-разрядной версии.
Решение: Чтобы зарегистрировать вашу сборку, которой нет в GAC, на 64-битной машине, откройте окно cmd и выполните:
cd c:\windows\microsoft.net\framework64\v2.x.xxxxx
regasm /codebase "path to your compiled assembly dll"
Это устранит «Ошибка не зарегистрированного класса» при использовании собственного C ++ для создания экземпляра сборки .NET как объекта COM.