Устранение неполадок в развернутой программе c #

Question

Последние пару недель я пишу программу ac #, и сборка текста только что завершила свою работу.Я опубликовал его через visual studio, отправил пакет установки моему клиенту, и он просто не работает на их компьютерах.Я установил на них точно такой же двоичный файл, какой у меня был для тестирования.Это программа, которая начинается с ряда всплывающих окон, и после последнего всплывающего окна программа просто закрывается, а не вызывает основное окно.Я понимаю, что без доступа к моему источнику и компьютерам моих клиентов устранение неполадок невозможно, но, честно говоря, я даже не знаю, с чего начать.Могу ли я получить некоторые предложения о том, на что посмотреть?Мы оба работаем под управлением Windows 7, и хотя у меня есть 64-разрядная версия, я не думаю, что это должно что-то изменить, тем более что программа запускается.

Любой совет, с чего начать искать?

edit Мое решение зависит от пользовательской библиотеки элементов управления, которая не отображается до тех пор, пока не будет выполнена команда this.Show (), в которой (я предполагаю) произойдет сбой программы.Есть ли способ проверить, не включено ли это как-то, но, поскольку он был построен на моем компьютере, ссылка там работает?Я спрашиваю, потому что кнопка «Публикация» просто называет мой проект, а не решение в целом, хотя при сборке он отлично работает на моем компьютере, и у проекта в качестве зависимостей установлена ​​библиотека.

Answer 1

Из комментария о Excel Interop используется, я получил это от MSDN . Это может быть очевидно, но в любом случае.

1. Для правильной работы этого кода в вашей системе должен быть установлен Excel.

2. Для использования COM-взаимодействия у вас должны быть разрешения администратора или опытного пользователя. Для получения дополнительной информации о безопасности см. Безопасность .NET Framework.

В своем примере они используют следующий код. Может быть полезно добавить аналогичную проверку в код запуска.

Microsoft.Office.Interop.Excel.Application xlApp;
xlApp = new Microsoft.Office.Interop.Excel.Application();
if (xlApp == null)
{
   Console.WriteLine("EXCEL could not be started. Check that your office installation and project references are correct.");
}

(примечание: я сам никогда этим не пользовался, поэтому мало что знаю о нем, это просто след из комментариев и некоторых поисков в MSDN).

Answer 2

Если вы можете внести изменения в приложение, вы можете попытаться зарегистрировать любое исключение, выданное с помощью Trace вывода или в течение длительного времени, с помощью специального регистратора, такого как log4net.Кроме того, использование зависимостей может быть полезно при использовании DependencyWalker - 64-разрядная версия может быть проблемой, если у вас есть сборки, загруженные во время выполнения, вы можете получить известное исключение «BadImageFormat».

Если вы можете, я бы такженастроить 32-разрядную виртуальную машину Win 7 для имитации клиентской среды на «чистой» машине, это может помочь воспроизвести проблему.

Изменить, чтобы уточнить конфигурацию трассировки:

Вы можете добавить прослушиватель трассировки в ваш app.config:

<system.diagnostics>
    <trace autoflush="true" indentsize="4">
        <listeners>
            <add name="LogFileWriter" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:\logs\FooApp.log"/>
        </listeners>
    </trace>
</system.diagnostics>

Это приведет к тому, что все операторы Trace.Write() в вашей программе будут записываться в ваш журнал (при условии, что у вас есть право на запись в настроенную папку).

Answer 3

Я бы посоветовал вам взглянуть на Windows Event Viewer. Скорее всего, он содержит некоторую полезную информацию о сбое. Кроме того, существует возможность удаленной отладки вашего приложения, как описано в Как: настроить удаленную отладку . Это то, что я бы сделал. Кроме того, попробуйте перехватить все исключения, возникающие в вашем приложении, подписавшись на события Application.UnhandledException и AppDomain UnhandledException . Это позволит вам получить стек вызовов.

Answer 4

Что помогло мне однажды в ситуации, почти похожей на вашу, так это установить DebugView из внутренних систем на клиентском компьютере и развернуть отладочную версию приложения (, вот как отследить и отладка из C # ).

DebugView покажет все сообщения отладки, которые выдает ваша программа, и это может помочь вам понять, что происходит не так.

После установки как DebugView, так и вашего приложения, клиент запустит DebugView, удостоверится, что захват активен, а затем запустите ваше приложение. Все ваши отладочные сообщения (отправленные на System.Diagnostics.Debug) будут отображаться в DebugView, который затем может быть сохранен вашим клиентом в файл и отправлен вам для анализа.

Answer 5

1. Добавьте логарифмическую возможность и (если ее еще нет) и «архитектор», по крайней мере, для «простых» и «подробных» журналов, где:

   Простой: просто общая информация, которую вам, возможно, понадобится прочитать

   Подробно: только каждое, что вы можете, или есть смысл для ведения журнала (зависит от вашего приложения)

2. Убедитесь, что вы регистрируете обработанные исключения и можете обрабатывать даже необработанные через стандартную подписку вашей AppDomain.
3. Добавить журнал в каждое окно Show () и метод OnClosing () (по крайней мере, для тех, которые зависают)
4. Проверьте, является ли ОС одинаковой на вашей машине сборки и на клиенте .
5. Если ваше программное обеспечение где-то пишет что-то, убедитесь, что у вас достаточно привилегий для этого (простой тест - просто попросите клиента запустить вашу программу Как администратор
6. Если все еще не работает, включите режим Verbose, запустите приложение на клиенте и проверьте журналы.

Рано или поздно вы найдете что-то, что, возможно, не будет напрямую объяснять вашу проблему, но определенно поможет вам найти правильный способ ее решения.

С уважением.

Answer 6

Какой у вас целевой процессор? Возможно, вы установили x64, и ваш клиент работает на 32-битной версии Windows 7