Мне нужно знать контекст (ASP.NET, Windows Service, Windows Application и т. Д.), В котором размещена моя сборка.Как определить, где находится моя dll
Мое собрание должно вызывать различные функции, основанные на контексте. Например, если необходимо создать папку относительно ее местоположения, я хотел бы знать, какой метод использовать: Path.GetFullPath(dirName) или Server.MapPath(dirName).
Похоже, вы разрабатываете DLL для использования другими разработчиками. Это также звучит так, как будто вы пытаетесь создать временные файлы, где вы не знаете и/или не имеете контроля над средой.
Если это верно, возможно, лучше создать конфигурационный файл (расположенный в том же каталоге, что и ваша DLL), который содержит среди всего прочего путь для использования с временными файлами. (Или, еще лучше, использовать в AppSettings в вашем App.Config или Web.Config похож на Log4Net)
При отсутствии этого файла конфигурации, вы можете попытаться использовать GetTempPath(), но это, скорее всего, fail for ASP.NET (и may fail под другой обстоятельства).
Если вам не удалось создать временные файлы, вы можете попытаться сохранить необходимую информацию в памяти (например, с помощью MemoryStream).
Если это не удается, вы всегда можете указать пользователю использовать конфигурационный файл.
В ответ на ваш актуальный вопрос, я не в курсе способ надежно сказать, какой проект вы работаете. Красота .NET - настолько гибкая. Теоретически вы могли бы написать приложение консоли, которое может работать как веб-сервер или настольное приложение или как служба Windows. Это могут быть все три в одном.
Вы всегда можете попытаться угадать, основываясь на referenced assembliescalling executable (System.Windows, вероятно, означает рабочий стол, System.Web, вероятно, означает ASP.NET и т. Д.), Но это будет чревато ошибкой. Я написал несколько настольных приложений, которые ссылаются на веб-сборки, и я написал веб-сайты, которые ссылаются на настольные сборки.
Но если вы поместите путь в свой конфигурационный файл, вам может не понадобиться знать контекст ... у вас уже есть полный путь, который вам нужен, без использования GetFullPath() или MapPath ().
Если вам действительно нужно различать, вы можете включить настройку в свой конфигурационный файл. Пользователь вашей DLL сможет настроить сборку в среде, в которой он используется. Если они ошибочно настроятся на конфигурацию ... хорошо ... большинство программных продуктов будет работать неправильно, если вы неправильно настроите конфигурацию. Так оно и есть.
Или ... еще лучше ... если поведение определенных задач (например, поиск пути к файлу) необходимо изменить на основе некоторого состояния, неизвестного во время разработки, тогда вы можете закодировать свою DLL для поддержки dependency injection чтобы ваш пользователь мог обеспечить нужную функциональность.
Спасибо, что я создал конфигурацию, которая имеет путь к папке –
«Принятие» ответа помогает будущим посетителям находить ответы на свои вопросы. (Пожалуйста, не чувствуйте давления, хотя, если этот ответ не был полезен, вам не нужно его принимать) – JDB
Извините, но до тех пор, пока не узнаю, что я не нашел прямого ответа на мой вопрос. Когда я помещаю путь в ConfigFile, не имею в виду, что я выполняю свою мысль, так или иначе, ваше предложение хорошее. –
@CodeCaster - Я думаю, что OP может спрашивать, является ли путь одинаковым для всех контекстов (ASP.NET, Windows Service, Windows Application и т. Д.). Например, если ASP.NET возвращает URL-адрес, его, возможно, нужно будет сопоставить. – JDB
@ Ramhound: системная переменная, такая как? –