Разыскивание неустойчивой 'Ссылки на объект не набор к экземпляру объекта'. ошибка на сборке
Я думаю, что это будет лучше в качестве комментария. Но у меня нет необходимой репутации. Таким образом, я отвечу на ваш вопрос более подробно.
Вы не предоставили образец. Так что я могу только сделать предположение. Скорее всего, ваша проекция имеет намного больше граней по сравнению с двухсторонней сетью. В зависимости от вашей конкретной сети это может значительно увеличить время создания сюжета.
Двусторонняя проекция из ненаправленной сети с 500 ребрами приведет к 124750 (или n * (n-1) / 2) ребрам.
library(igraph)
library(tictoc)
g <- data.frame(c(1:500), "A")
g <- graph_from_data_frame(g)
V(g)$type <- bipartite_mapping(g)$type
bp <- bipartite_projection(g)
gsize(g)
500
gsize(bp$proj1)
124750
А время печати увеличилось бы на 8,5 с (MacBook Pro с 2015 г. с Intel i7 и 16 ГБ ОЗУ):
tic("Plotting bibpartite net")
plot(g)
toc()
Plotting bibpartite net: 1.194 sec elapsed
tic("Plotting projected net")
plot(bp$proj1)
toc()
Plotting projected net: 9.621 sec elapsed
Проблема в том, что количество связей в проектируемой сети растет в геометрической прогрессии и время создания сюжета.
10 ответов
Проверьте Журнал приложения своего Event Viewer - Он должен сказать Вам, где исключение выдается.
-
Видят, существуют ли какие-либо события постсборки, которые могли бы перестать работать. Они могут быть найдены на странице свойств каждого проекта.
-
использование Попытки Восстанавливают Решение вместо Решения для Сборки. Вы, возможно, должны добавить, Восстанавливают Решение от Инструментов>, Настраивают. Если Ваше веб-приложение устанавливает или регистрирует какие-либо сервисы окон, и те сервисы запускаются, Восстанавливая плуги через те типы проблем.
То, что действительно нечетно, - то, что это - ошибка времени выполнения. Вы не должны видеть это во время компиляции. У Вас есть кто-либо пред - или пост - шаги сборки присоединенный к решению? Какие-либо модульные тесты Вы включаете со своим процессом 'сборки'?
, Где эта ошибка обнаруживается?
Просто для уточнения действительно ли это - сам компилятор, который дросселирует? Вы делаете что-либо странное с #define и #if директивами в Вашем коде? Возможно, что-то делается не в порядке в какой-то момент... Просто мысль...
Выполните эту команду в командной строке и посмотрите, получаете ли Вы некоторую более подробную информацию
%WINDIR %\Microsoft.NET\Framework\v3.5\msbuild.exe YourSolution.sln/v:n
Я видел это, когда Вы имеете контроль управления на странице, где существует недопустимый HTML. Если Ваш codebehind попытается сделать что-то с управлением, то он не сможет найти его и даст Вам Ссылку на объект... ошибка во время компиляции. По моему опыту, это не создает ошибку периода выполнения, и проект создаст, если рассматриваемый файл будет закрыт во время сборки. HTH, Удачи!
"Ссылка на объект не набор к экземпляру объекта" является ясно ошибкой времени выполнения, не ошибкой времени компиляции. Таким образом, то, что это говорит мне, - то, что Visual Studio дросселирует на чем-то, которое не может обязательно быть в Вашем коде, или которое что-то в Вашем коде только косвенно вызывает.
Следующий вопрос я спросил бы: это происходит только в Visual Studio или приводит в порядок шоу того же самого при создании использования MSBuild или CSC?
Первая вещь, которую я попробовал бы, будет состоять в том, чтобы увеличить многословие компилятора. Это может быть установлено в опциях Visual Studio - например, "Инструменты-> Опции-> Проекты и Сборка Решений и Выполнение-> выходное многословие сборки проекта MSBuild" для VS2005. При установке его на диагностику затем, это должно сказать Вам, что это делает в то время, когда исключение повышено по крайней мере.
У меня было это во время изготовления, когда мой проект содержал пользовательские источники данных (мои собственные объекты, возвращая наборы) с ошибками компиляции (то есть, мои объекты имели ошибки).
Вы также получите эту ошибку, при попытке добавить источник данных, и Ваш проект не имеет никаких источников данных в корне проекта (например, если Вы поместили все свои классы источника данных в подпапку). Единственное решение, которое я нашел, состояло в том, чтобы создать источник данных в корне проекта.
Жаль не быть более точными, но, кажется, существует несколько вещей, которые могут пойти не так, как надо с источниками данных/объектами во время компиляции.
Чтобы решить эту проблему, мы никогда не отслеживали причину ошибки, но она исчезла, когда мы обновились до Visual Studio 2008 и преобразовали проект в веб-приложение.