Как убрать полный путь до файлов проекта .NET Core в исключениях?

Question

[sorax1]

Имеется проект .NET Core на ПК, где он разрабатывается он лежит в директории, допустим /home/user/project/
При публикации проекта и переносе его на рабочую машину, при возникновении исключений в подробностях можно увидеть полный путь до проекта и строки где исключение было выброшено, к примеру /home/user/project/Program.cs:line 20

Подскажите существует ли возможность скрыть такие подробности, особенно полный путь, убрать вообще или оставить только имя файла.

Comments

[Евгений]

переменные окружения?

[sorax1]

Евгений, расскажите?

[eRKa]

По идее на клиенте вообще не должны быть видны исключения. Их нужно перехватывать и логировать, а клиенту отдавать только подобное "что-то пошло не так".

[sorax1]

eRKa, согласен, проект проходит тестирование и во время него обнаружил подобные логи

[#]

вообще то это отладочная информация, именно для разработчика - сразу понятно в каком файле строка исключения или стека вызовов

если бы вы обращали внимания на крешы программ других производителей, когда отладочная инфа не скрыта полностью, и сели она содержит пути к сорцам - это всегда реальные пути, но НЕ в вашей системе,а в системе разраба

если вы хотите полностью скрыть подобную инфу - разрабатывайте механизм сокрытия сообщений, логгирования и/или отправки сразу отчета разработчику

однако правилами хорошего тона будут запрос разрешения на отправку отчетов + НЕ шифрованная форма логов (db?)

иначе вы будете настроживать встречную паранойю потребителя

[#]

может можно нагуглить что то типа "инструменты сбора телеметрии дл .Net Core?"

[#]

для сравнения, в UWP, такие инструменты изначально предлагаются как часть инфраструктуры

(а так же являются частью, той самой критикуемой слежки и предоставления телеметрии 3м лицам, одна из категорий 3х лиц - разрабы приложений UWP)

[sorax1]

mindtester, вопрос мой был немного из другой области. Никто не опровергает бОльшую часть утверждений, что вы изложили. Во многом вы правы, но есть так же момент, где я с вами не согласен. Это именно тот момент, который я упоминаю в своем вопросе и на который уже дали развернутый ответ, который полностью решает проблему.

Безусловно отладочная информация с описанием полных путей до файла - крайне полезна на стадии разработки и тестирования приложения, но я уверен, что это излишне в релизной версии.

Вы говорите о том, что существуют программные продукты, где отладочная информация содержит реальные пути в системе разработчика, если честно я таких не встречал и очень бы удивился если бы увидел в этих логах нечто подобное "C:\Users\Василий\Проекты\dotnet\...." Не думаю, что такую информацию стоит оставлять в релизной версии и она внушит пользователям больше уверенности, по-моему такой подход как раз менее функционален. Я лишь хотел скрыть частично или полностью путь до файла, оставив возможно сам файл относительно директории проекта и считаю что это более правильно и более эстетично. А о том чтобы убрать логи полностью и речи не шло.

[#]

sorax1,

Вы говорите о том, что существуют программные продукты, где отладочная информация содержит реальные пути в системе разработчика, если честно я таких не встречал и очень бы удивился если бы увидел в этих логах нечто подобное "C:\Users\Василий\Проекты\dotnet\...."

удивляйтесь:

C:\Users\user\VirtualBox VMs\++>"C:\Program Files\Oracle\VirtualBox\VBoxManage" internalcommands createrawvmdk -filename "C:\Users\Public\VirtualBox\raw's\pd4.bulk.vmdk" -rawdisk \\.\PhysicalDrive4
VBoxManage.exe: error: VMDK: could not create new file 'C:\Users\Public\VirtualBox\raw's\pd4.bulk.vmdk'
VBoxManage.exe: error: Error code VERR_PATH_NOT_FOUND at F:\tinderbox\win-5.2\src\VBox\Storage\VMDK.cpp(3392) in function int __cdecl vmdkCreateRawImage(struct VMDKIMAGE *,struct VDISKRAW *const ,unsigned __int64)
VBoxManage.exe: error: Cannot create the raw disk VMDK: VERR_PATH_NOT_FOUND
VBoxManage.exe: error: The raw disk vmdk file was not created

3я строка. кстати, даже не искал специально )) я действительно довльно активно использую виртуальные машины. в частности недавно задвал вопрос

Windows 10, VirtualBox — у кого есть успешный опыт использования реального диска для виртуальной машины?

и прямо сейчас провожу очередную пробу ))

я привык видеть подобные вставки путей... мм... наверное несколько раз в год минимум? а когда работал в корпоративном секторе, скорее раз в неделю в среднем ))) ... и это столько, сколько себя помню в роли админа )))

[sorax1]

mindtester, и все же это нечто другое. Здесь очевидный смысл присутствует в том, что это приложение других масштабов, под различные ОС и их версии и видеть такие подробности крайне необходимо.

Плюс ко всему их путь и структура директорий выглядит лаконично и вполне логично. А вот если бы там был путь к папке на домашнем ПК, с несколькими промежуточными директориями, включающими кириллические символы, то это было бы уже не так профессионально. Именно поэтому мне и нужно было скрыть полные пути, оставив только имя файла без полного описания его полного расположения. Это намного проще, быстрее и разумнее, чем менять расположение проекта, да и проект не того размера чтобы не суметь найти проблему в случае ее возникновения.

[#]

sorax1, ну уже вот выдувать аргументы из воздуха не стоит..

все в ваших руках:
- распологайте проекты по красивым и логичным путям
- избегайте кириллицы
- или скрывайте отладочную информацию тотально

это ваш выбор

вы заявили

если честно я таких не встречал и очень бы удивился если бы увидел в этих логах нечто подобное "C:\Users\Василий\Проекты\dotnet\...." Не думаю, что такую информацию стоит оставлять в релизной версии и она внушит пользователям больше уверенности, по-моему такой подход как раз менее функционален

я привел пример

если вам это фу-фу-фу, а Ораклу можно - это ваше мнение. но избавьте от прехода к кухонным дискуусиям кому это можно а кому фу-фу-фу

Answer 1

[basrach]

Эта информация хранится в файлах с расширением *.pdb. Они нужны для дебагера. Удалить часть пути из них невозможно, но можно удалить файл целиком и тогда в исключениях не будет информации об исходном коде вообще, будет только стек вызовов (имя класса, название метода и т.п.). Также можно в .csproj добавить условие, чтобы при релизном билде эти файлы не создавались:

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
  <DebugType>none</DebugType>
  <DebugSymbols>false</DebugSymbols>
</PropertyGroup>

В основном эти файлы нужны для дебага. Без них дебаггер не будет корректно работать, т.е. он не сможет сопоставить в общем случае инструкцию с исходным кодом. Соотвественно не в релизе отключать генерацию этих файлов не стоит.