Получить имя папки, где находится запущенный dll-файл

[Александр Ривилис]

Boxa.Shu,
Если есть возможность, то проверь что в этом случае возвращает Assembly.GetExecutingAssembly().GetName().FullName - должен быть полный путь к dll-файлу

[Владимир Шу]

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

[Пашин Евгений]

Что-то я уже запутался... Сейчас все сработало как надо - вернул полный путь к dll-файлу 

Код - vb.net [Выбрать]

1.         Dim myPath As System.Reflection.Assembly = System.Reflection.Assembly.GetExecutingAssembly()
2.  
3.         MsgBox(myPath.Location)

Приношу свои извинения... Пора выпить чаю, нужно отдохнуть от компьютера.

А вот это код вернул следующее:

Код - vb.net [Выбрать]

1.         Dim myNewPath As System.Reflection.Assembly = System.Reflection.Assembly.GetExecutingAssembly()
2.  
3.         MsgBox(myNewPath.FullName)

AutoCAD_First_Button_After_Error, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

[Александр Ривилис]

Еще вариант:

Код - C# [Выбрать]

1. string codeBase = Assembly.GetExecutingAssembly().CodeBase;
2. UriBuilder uri = new UriBuilder(codeBase);
3. string path = Uri.UnescapeDataString(uri.Path);
4. return Path.GetDirectoryName(path);

Вариант с Assembly.GetExecutingAssembly.Location, как пишут действительно работает не всегда:
http://stackoverflow.com/questions/52797/how-do-i-get-the-path-of-the-assembly-the-code-is-in

[Андрей Бушман]

У меня этот метод частенько глючит.

Сильно подозреваю, что это не метод глючит но, скорее всего, ты неверно указываешь путь в своём макросе.

[Пашин Евгений]

Вариант с Assembly.GetExecutingAssembly.Location, как пишут действительно работает не всегда

Ну слава богу, а то я подумал, что у меня с глазами не то творится.

[Владимир Шу]

Сильно подозреваю, что это не метод глючит но, скорее всего, ты неверно указываешь путь в своём макросе.

Библиотека то грузится и команда стартует...

[Александр Ривилис]

Такое чувство, что сборка копируется во временную директорию, а оттуда уже запускается...

[Андрей Бушман]

ариант с Assembly.GetExecutingAssembly.Location, как пишут действительно работает не всегда:
http://stackoverflow.com/questions/52797/how-do-i-get-the-path-of-the-assembly-the-code-is-in

Любопытно... Я как-то с этим ранее не сталкивался, всегда использовал

Код - C# [Выбрать]

1. Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location)

Да и в юнит-тестах (как пишет автор по вашей ссылке) у меня проблем не возникало. Например, если у меня в настройках проекта определена GET_TEST_CASES_FROM_XML, то данные для test cases читаются из XML; в противном случае - из кода. Например, это видно здесь в строках 34 и 35.

[Андрей Бушман]

Такое чувство, что сборка копируется во временную директорию, а оттуда уже запускается...

А вот такое поведение у меня в юнит тестах бывало (вспомнил)! Я в блоге показывал как этим поведением можно управлять в NUnit. Вполне возможно, что аналогичные настройки имеются в TestDriven.NET и MbUnit GUI.

[Владимир Шу]

Виноват. Зря грешил на этот метод.
Гадом оказался метод load у XmlDocument, строчка №12. Несмотря на корректный путь и проверки, почему то берет путь "текущий" (иногда это путь к файлу с которым работаю) и прибавляет к нему имя файла...
В строчках 10 и 11, выводится абсолютно корректный путь, копирую из консоли, вставляю в адресную строку проводника, открывается нужный файл.

Я понимаю что не совсем четко по теме, но все таки, есть идеи?

Код - C# [Выбрать]

1.             String path = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
2.             String inputFile = Path.Combine(path, "blockXML.xml");
3.            
4.             XmlDocument xml = new XmlDocument();
5.            
6.             if (File.Exists(inputFile))
7.             {
8.                 System.IO.FileStream fs = new System.IO.FileStream(inputFile,
9.                     System.IO.FileMode.Open, System.IO.FileAccess.Read);
10.                 acEd.WriteMessage("\n1-" + fs.Name);
11.                 acEd.WriteMessage("\n2-" + inputFile);
12.                 xml.Load(inputFile);
13.             }
14.             else
15.             {
16.                 throw new FileNotFoundException(inputFile);
17.             }

[Дмитрий Загорулькин]

А что это мы поток без using используем? А зачем он там вообще нужен? Если его убрать, проблема остается?

[Андрей Бушман]

Boxa.Shu,

Набросай HelloWorld (команду акада) и выложи (не забудь к нему прикрепить и свой XML).

[Владимир Шу]

Если закоментить строчки 14-17 ничего не меняется.
Вот лог консоли в автокаде:
Command: _NETLOAD Assembly file name: "C://ACAD_DLL//_AddMLeader//AddMLeader_2014.dll"
Command: bx_addmleader
Укажите экземпляр блока:
1-C:\ACAD_DLL\_AddMLeader\blockXML.xml
2-C:\ACAD_DLL\_AddMLeader\blockXML.xml

Вот лог ошибки:
See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.IO.FileNotFoundException: Could not find file 'C:\Users\user\Documents\blockXML.xml'.
File name: 'C:\Users\user\Documents\blockXML.xml'

Извините, вам запрещён просмотр содержимого спойлеров.

И все это безобразие только если загружать эту библиотеку макросом с палитры

Код - Auto/Visual Lisp [Выбрать]

1. ^C^C_NETLOAD "C://ACAD_DLL//_AddMLeader//AddMLeader_2014.dll";bx_addmleader;

Если загрузить руками и запустить команду руками, то все тип топ. Работает как часы.

[Дмитрий Загорулькин]

Если закоментить строчки 14-17 ничего не меняется.

А я говорил про строки 8-10:

Код - C# [Выбрать]

1.                 System.IO.FileStream fs = new System.IO.FileStream(inputFile,
2.                     System.IO.FileMode.Open, System.IO.FileAccess.Read);
3.                 acEd.WriteMessage("\n1-" + fs.Name);

Лучше их комментить. Зачем они? В любом случае, FileStream нужно "заворачивать" в using.