Симон Моурир дал этот пример :
object o = null;
DateTime d = (DateTime)o; // NullReferenceException
, где unboxing преобразование (литье) из object
(или из одного из классов System.ValueType
или System.Enum
или из типа интерфейса) - тип значения (кроме Nullable<>
) сам по себе дает NullReferenceException
.
В другом направлении конверсия бокса из a Nullable<>
, которая имеет HasValue
, равную false
, на ссылочный тип, может дать ссылку null
, которая затем может привести к NullReferenceException
. Классический пример:
DateTime? d = null;
var s = d.ToString(); // OK, no exception (no boxing), returns ""
var t = d.GetType(); // Bang! d is boxed, NullReferenceException
Иногда бокс происходит по-другому. Например, с помощью этого не общего метода расширения:
public static void MyExtension(this object x)
{
x.ToString();
}
следующий код будет проблематичным:
DateTime? d = null;
d.MyExtension(); // Leads to boxing, NullReferenceException occurs inside the body of the called method, not here.
Эти случаи возникают из-за специальных правил, используемых во время выполнения при боксе Nullable<>
экземпляров.
Вам понадобится загрузить 32-разрядную dll в отдельный 32-разрядный процесс, и ваш 64-битный процесс свяжется с ним через межпроцессное общение. Я не думаю, что в любом случае 32-разрядная dll может быть загружена в 64-разрядный процесс.
Здесь есть довольно хорошая статья:
Вам необходимо записать исполняемые процессы в виде 32-битных процессов (против любого процессора или x64), чтобы они были загружены с помощью WoW32 для Vista. Это загрузит их в режиме 32-разрядной эмуляции, и у вас не будет проблемы с точкой входа. Вы можете оставить свои библиотеки в режиме AnyCPU, но ваши исполняемые файлы должны быть скомпилированы как x86.
Ответ Джона правильный, если вы не хотите перекомпилировать существующие DLL; однако это может быть и вариантом для вас.
Наша команда в настоящее время переносит наш код x86 FORTRAN на x64, чтобы увеличить потолок памяти.