Многие вероятно задавались этим вопросом, особенно когда нет VPN, а есть только проброшенный порт.
Алгоритм:
1. Копируем Remote debugger от своей Visual Studio (только так! какой попало не подойдет) на target машину. Важна еще разрядность: для отладки x64 программ копируйте x64 версию, а если программа запущена на Win64, но имеет разрядность x86 - то нужен x86 remote debugger! Он предупредит о том, что версия x64 умеет и x86 процессы дебажить, но в реальности это оказалось неправдой... по крайней мере у меня не получилось
2. Запускаем там msvsmon, желательно с правами админа. Выбираем аутентификацию (лучше Windows, можно без аутентификации). Важно выбрать порт тот, который проброшен в интернет. На роутере настроить forwarding для TCP порта. По умолчанию 4016, но подойдет любой.
Не забываем разрешить соединение по этому порту в фаерволе, либо отключаем его вообще.
3. Соединяемся удаленной Visual Studio с Remote Debugger по внешнему IP и проброшенному порту. К примеру 123.123.123.123:4016, выбираем транспорт (Native в случае отсутствия аутентификации, либо Default - в случае Windows аутентификации), соединяемся... и видим что-то такое:
Unable to connect to 'TARGET'. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging
В случае с Windows Authentication еще успеем ввести логин и пароль, но итог будет тот же.
При этом удаленный дебаггер даже не шелохнулся - нет информации о соединении, либо о каких-то ошибках.
Форумы MSDN расскажут что задуманное невозможно http://social.msdn.microsoft.com/Forums/vstudio/en-US/897782e5-dada-4df1-8ef2-f119cdce7e5e/remote-debugging-over-internet?forum=vsdebug
Ну или порекомендуют VPN...
Но мы не такие! Если поглубже посмотреть в источник причины, то выясняется, что Remote debugger использует pipes для соединения. А пайпы через интернет не того... особенно через порты проброшенные. В реальности ведь удаленному отладчику не очень нужны преимущества пайпов, если вы дебажите native код. DCOM и всякие RPC пригодятся только для отладки managed кода. Единственное что привязывает удаленный отладчик и пайпы - это имя target машины.
РЕШЕНИЕ
Короче говоря, самый простой способ, который я нашел - прописываем в файлике \Windows\System32\etc\hosts имя target машины и привязываем ее к внешнему IP, по которому она доступна, и соединяемся по имени. Важно задать реальное имя машины.
Т.е. в hosts пишем что то вроде
123.123.123.123 TARGETPC
и соединяемся из Visual Studio к TARGETPC:4016
И все работает! правда только для отладки native кода.
Относительно managed кода сказать могу мало что - не пробовал, но будут проблемы. Для версий .NET 4.0 и 4.5 реально используется DCOM, поэтому, по всей видимости, здесь только одно нормальное решение - VPN. Можно попробовать пробросить еще и DCOM порты (вот какие надо http://www.verdiem.com/kb/configure-firewall-dcom-ports), но будет ли оно работать - не знаю...
Алгоритм:
1. Копируем Remote debugger от своей Visual Studio (только так! какой попало не подойдет) на target машину. Важна еще разрядность: для отладки x64 программ копируйте x64 версию, а если программа запущена на Win64, но имеет разрядность x86 - то нужен x86 remote debugger! Он предупредит о том, что версия x64 умеет и x86 процессы дебажить, но в реальности это оказалось неправдой... по крайней мере у меня не получилось
2. Запускаем там msvsmon, желательно с правами админа. Выбираем аутентификацию (лучше Windows, можно без аутентификации). Важно выбрать порт тот, который проброшен в интернет. На роутере настроить forwarding для TCP порта. По умолчанию 4016, но подойдет любой.
Не забываем разрешить соединение по этому порту в фаерволе, либо отключаем его вообще.
3. Соединяемся удаленной Visual Studio с Remote Debugger по внешнему IP и проброшенному порту. К примеру 123.123.123.123:4016, выбираем транспорт (Native в случае отсутствия аутентификации, либо Default - в случае Windows аутентификации), соединяемся... и видим что-то такое:
Unable to connect to 'TARGET'. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging
В случае с Windows Authentication еще успеем ввести логин и пароль, но итог будет тот же.
При этом удаленный дебаггер даже не шелохнулся - нет информации о соединении, либо о каких-то ошибках.
Форумы MSDN расскажут что задуманное невозможно http://social.msdn.microsoft.com/Forums/vstudio/en-US/897782e5-dada-4df1-8ef2-f119cdce7e5e/remote-debugging-over-internet?forum=vsdebug
Ну или порекомендуют VPN...
Но мы не такие! Если поглубже посмотреть в источник причины, то выясняется, что Remote debugger использует pipes для соединения. А пайпы через интернет не того... особенно через порты проброшенные. В реальности ведь удаленному отладчику не очень нужны преимущества пайпов, если вы дебажите native код. DCOM и всякие RPC пригодятся только для отладки managed кода. Единственное что привязывает удаленный отладчик и пайпы - это имя target машины.
РЕШЕНИЕ
Короче говоря, самый простой способ, который я нашел - прописываем в файлике \Windows\System32\etc\hosts имя target машины и привязываем ее к внешнему IP, по которому она доступна, и соединяемся по имени. Важно задать реальное имя машины.
Т.е. в hosts пишем что то вроде
123.123.123.123 TARGETPC
и соединяемся из Visual Studio к TARGETPC:4016
И все работает! правда только для отладки native кода.
Относительно managed кода сказать могу мало что - не пробовал, но будут проблемы. Для версий .NET 4.0 и 4.5 реально используется DCOM, поэтому, по всей видимости, здесь только одно нормальное решение - VPN. Можно попробовать пробросить еще и DCOM порты (вот какие надо http://www.verdiem.com/kb/configure-firewall-dcom-ports), но будет ли оно работать - не знаю...
Комментариев нет:
Отправить комментарий