NullPointerException
s - исключения, возникающие при попытке использовать ссылку, которая указывает на отсутствие местоположения в памяти (null), как если бы она ссылалась на объект. Вызов метода по нулевой ссылке или попытка получить доступ к полю нулевой ссылки вызовет функцию NullPointerException
. Они наиболее распространены, но другие способы перечислены на странице NullPointerException
javadoc.
Вероятно, самый быстрый пример кода, который я мог бы придумать для иллюстрации NullPointerException
, be:
public class Example {
public static void main(String[] args) {
Object obj = null;
obj.hashCode();
}
}
В первой строке внутри main
я явно устанавливаю ссылку Object
obj
равной null
. Это означает, что у меня есть ссылка, но она не указывает на какой-либо объект. После этого я пытаюсь обработать ссылку так, как если бы она указывала на объект, вызывая метод на нем. Это приводит к NullPointerException
, потому что нет кода для выполнения в местоположении, на которое указывает ссылка.
(Это техничность, но я думаю, что она упоминает: ссылка, которая указывает на null, равна 't то же, что и указатель C, указывающий на недопустимую ячейку памяти. Нулевой указатель буквально не указывает на в любом месте , который отличается от указаний на местоположение, которое оказывается недопустимым.)
Что-то, что удобно для трудно для отладки разделов кода,
System.Diagnostics.Debugger.Break()
, бросит точку останова, пойманную любым установленным отладчиком (VStudio, WinDbg, Удаленный отладчик и т.д....).
Использование это для отладки действительно хитрых областей, где регулярный F5+Go или "Присоединяют к Процессу", является трудным или невозможным работать, некоторые примеры включают:
создайте VM, установите Visual Studio, сделайте копию из нее (или создайте differencing Виртуальный жесткий диск), и запустите установщик под отладчиком под VM.
, Именно это я сделал бы (но я не эксперт).
присоедините процесс установщика к Visual Studio в Отладке-> Процессы-> Присоединение или CTRL +, ALT + P установил точку останова, и необходимо быть в состоянии пойти
Я использую EventLog.WriteEntry («источник», «сообщение») и проверяю EventLog при установке. Может быть, не оптимально, но у меня работает :)
Лучший способ, который я нашел, - это написать модульный тест, обновить и инициализировать свой класс установщика из вашего модульного теста:
[TestClass] public class InstallerTest {
[TestMethod]
public void InstallTest() {
// substitute with your installer component here
DataWarehouseInstall installer = new DataWarehouseInstall();
string assemblyDirectory = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
string installLogFilePath = Path.Combine(assemblyDirectory, "install.log");
installer.Context = new System.Configuration.Install.InstallContext(installLogFilePath, null);
// Refactor to set any parameters for your installer here
installer.Context.Parameters.Add("Server", ".");
//installer.Context.Parameters.Add("User", "");
//installer.Context.Parameters.Add("Password", "");
installer.Context.Parameters.Add("DatabaseName", "MyDatabaseInstallMsiTest");
//installer.Context.Parameters.Add("DatabasePath", "");
// Our test isn't injecting any save state so we give a default instance for the stateSaver
installer.Install(new Hashtable());
} }
По крайней мере тогда он лучше использует преимущества инструментария IDE. Это особенно полезно для очень крупных установщиков с МНОЖЕСТВОМ компонентов. Затем вы также можете создавать упорядоченные модульные тесты и запускать их последовательно, чтобы имитировать ваш установщик во время отладки или ваших автоматических сборок.
Еще одним советом были бы общие принципы программного обеспечения SOLID / GRASS ... разрабатывайте аккуратные / тонкие слои, сохраняя фактическую логику установщика "настраиваемых действий" очень простой и вместо этого вызывайте любые повторно используемые материалы API, которые у вас есть, которые специфичны для вашего установщика. (s), как мы привыкли к разработке пользовательского интерфейса. (В любом случае, установщик - это просто еще один пользовательский интерфейс.) Это особенно важно, если ваша цель - сделать определенный пользовательский интерфейс доступным для всех установщиков ваших продуктов.
Вы также можете использовать утилиту installUtil.exe для тестирования вашего компонента программы установки.
В случае, если вы создали сборку класса c# с классом Installer, измените настройки отладки для запуска внешней программы 'C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe' и введите аргументы командной строки соответствующим образом (например, /Args=myargument "путь к сборке")
В завершение установите точки останова, нажмите f5 и вы готовы к отладке кода. --paralax
Я использую следующий класс для записи простого журнала в целевой каталог. На мой взгляд, это проще, чем пытаться использовать отладчик Visual Studio.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace MyCompany.Deployment
{
/// <summary>
/// Enables a quick and easy method of debugging custom actions.
/// </summary>
class LogFile
{
const string FileName = "MyCompany.Deployment.log";
readonly string _filePath;
public LogFile(string primaryOutputPath)
{
var dir = Path.GetDirectoryName(primaryOutputPath);
_filePath = Path.Combine(dir, FileName);
}
public void Print(Exception ex)
{
File.AppendAllText(_filePath, "Error: " + ex.Message + Environment.NewLine +
"Stack Trace: " + Environment.NewLine + ex.StackTrace + Environment.NewLine);
}
public void Print(string format, params object[] args)
{
var text = String.Format(format, args) + Environment.NewLine;
File.AppendAllText(_filePath, text);
}
public void PrintLine() { Print(""); }
}
}