Я хочу получить bin приложения/debug-path
Я хочу получить Bin/Debug-Path приложения во время Время проектирования
С помощью Google я нашел несколько записей (например, StackOverFlow), но ни одна из них не работает ...
Что я уже пробовал:
Приложение.CommonAppDataPath
Приложение.ExecutablePath
Приложение.StartupPath
Приложение.LocalUserAppDataPath
Собрание.GetEntryAssembly.кодовая база
Каталог.GetCurrentDirectory
домен приложений.CurrentDomain.BaseDirectory
Мой.Приложения.Информация.Каталоге directorypath
Ни один из них выше не указывает верный путь ... :(
Richard MacCutchan
Это зависит от того, где вы хотите ссылаться на путь. Возможно, вы могли бы объяснить, что именно вы пытаетесь сделать.
Ralf Meier
Я хочу сохранить некоторые данные, сгенерированные компонентом во время разработки, в этот путь.
Я знаю, что сам конструктор может хранить данные компонента в конструкторе-скрипте формы, на которую он помещен, но я хочу, чтобы он был независимым.
Но ваш вопрос для меня не совсем ясен - какая информация вам нужна ?
Richard MacCutchan
Извините, но я все еще не совсем понимаю. Свойства проекта содержат относительный путь к bin\Debug, но я не уверен, как вы обращаетесь к этому в конструкторе. В C++ это довольно просто, так как все эти значения являются макросами, к которым можно получить доступ с помощью команд оболочки. C# и VB.NET похоже, что у вас нет такой же возможности, если только вы не можете каким-то образом получить доступ к свойствам через COM-интерфейс Visual Studio с помощью скрипта.
Ralf Meier
Я думаю, вы поняли, что я имею в виду (или хотите знать).
Мое приложение хранится под :
C:\Users\myName\Documents\Visual Studio 2013\Projects\myProject\MyProject
Итак, путь, который я хочу получить, таков :
C:\Users\myName\Documents\Visual проекты студии\2013\myproject будет\мой проект\бин\ "отладка"
Но ни одна из статей, которые я нашел, и пространств имен, которые я пробовал, не доставляют этот путь - я также буду рад, если получу путь приложения. Открытый путь "бин\" отладка "" могут быть добавлены на постоянной ...
Richard MacCutchan
Можете ли вы просто использовать путь "bin\Debug", так как он должен быть относительно каталога Вашего проекта?
Ralf Meier
Я хочу иметь его относительно моего проекта-каталога ... но и мой проект-каталог никуда не денется (как переменная или что-то в этом роде) ...
Dave Kreskowiak
Во время разработки не существует такой вещи, как папка "bin\Debug". Если приложение никогда не компилировалось, оно просто не существует.
Кроме того, вы описываете то, что никогда не должно быть сделано во время разработки. Ваш компонент никогда не должен создавать файл данных во время разработки. Этот файл не будет частью файлов проекта и не будет скопирован в целевую папку отладки или выпуска вместе с кодом при его компиляции.
В лучшем случае вы должны поместить эти сгенерированные данные в виде кода в файл кода "designer generated".
Ralf Meier
Именно по этой причине я хочу записать его в папку" bin\Debug "- или"bin\Release".
Но... поскольку Visual Studio знает, где писать скомпилированные части проекта, я предположил, что есть способ использовать это внутри моего приложения.
Dave Kreskowiak
Причина не в этом. Это то, что вы хотите сделать, но это совсем не логично.
Проблема с выбранным вами методом заключается в том, что код может быть выполнен только один раз, во время разработки, но данные могут даже не быть записаны, потому что целевая папка не существует. Целевую папку также можно очистить, уничтожив данные.
Весь смысл в том, что если это данные, которые должны быть сгенерированы, то они должны быть сгенерированы во время выполнения, а не во время разработки.
То, что вы пытаетесь сделать, нелогично для процесса разработки приложения, потому что целевая папка может вообще не существовать, и непрактично, потому что данные могут быть легко уничтожены просто путем создания приложения!
Вам действительно нужно поближе взглянуть на то, что вы делаете с этими данными и почему.
Ralf Meier
То, что я хочу сделать, - это создать компонент, который предоставляет некоторые свойства элементам управления в той форме, в которой находится компонент.
Одним из этих свойств является список (Строка), который позволяет выбирать. Содержимое из этого списка выходит из компонента и должно быть создано и/или изменено только во время разработки. Это содержимое должно быть общим для всех возможных других экземпляров этого компонента в других формах внутри того же проекта.
Что было причиной, почему я решил сделать это, как это.
Пришла идея использовать папку" bin\Debug "- или"bin\Release" -потому что в этом месте наконец-то можно найти готовое скомпилированное приложение (а также необходимые DLL - файлы и так далее)-Так почему бы не поместить этот файл данных в одну точку, потому что теперь все части вместе.
Если я использую приложение (Runtime-mode) Я проверяю заявление.StartupPath для этого файла-мое приложение может это проверить ...
Так... неужели я действительно ошибаюсь в своих мыслях ?
Dave Kreskowiak
То, о чем вы говорите, - это Объекты Поставщика Расширителя[^Это элемент управления, который расширяет другие элементы управления, добавляя к ним новые свойства и логику.
Ваши данные должны быть в сгенерированном дизайнером коде, который Атрибуты дизайнера[^] обеспечивает вас. Только так ваши данные смогут надежно попасть в приложение.
Ralf Meier
Как я уже писал :
Я знаю все части вокруг компонента, предоставляющие свойства другим элементам управления, сериализующие эти предоставленные свойства и так далее. Большая часть этого в настоящее время реализована и все еще работает.
Но - вся информация на самом деле хранится в конструкторе-скрипте формы, к которой принадлежит компонент - это означает, что если я хочу использовать то же самое на другой форме, вся общая информация должна быть создана снова. Вот почему я подумал о (Для этого компонента) Общепроектном хранилище общей информации-чтобы каждый экземпляр этого типа компонента мог получить доступ к одной и той же базе данных ...
Извинитесь, если не все это понятно с самого начала этой "дискуссии"...
Dave Kreskowiak
Я не уловил этого из разговора. Похоже, вам придется создать собственный инструмент сериализации, чтобы поместить ваши данные в статический класс, независимый от атрибута DesignerSerializationVisibility.
У меня нет примера, потому что я никогда не видел, как это делается, и сам этого не делал.
Ralf Meier
..- но вы понимаете мою цель ?
Конечно... вполне возможно, что здесь нет ничего сравнимого. Это идея (все начинается с идеи ;-))
Возможно, если бы я мог закончить его, я написал бы об этом статью в CP.
В данный момент я застрял с этой "простой" частью - я могу сериализовать ее, но не автоматически в том месте, где я хочу ее иметь.
Вот почему я прошу указать путь проекта в качестве переменной (или что-то в этом роде). Я не хочу писать путь как константу ...
Dave Kreskowiak
Я все прекрасно понимаю. Проблема с тем, что вы пытаетесь сделать, заключается в том, что вы пытаетесь получить путь из Visual Studio. Нет никакой переменной "окружения", которая дает вам этот путь. Он действительно существует только во время компиляции.
Этот путь также изменяется в зависимости от того, создаете ли вы отладочную сборку или сборку выпуска. Он также может измениться, если будут сделаны дополнительные настройки. Путь, вероятно, больше не будет иметь формат \bin\Debug или \bin\Release, возможно, \bin\x86\Debug или \bin\x64\Release или что-то еще, в зависимости от имен конфигураций.
Теперь, чтобы получить путь из Visual Studio, ваш код должен быть написан, чтобы получить путь из Visual Studio, навсегда привязав ваш проект к Visual Studio, возможно, к конкретным его версиям из-за изменений в объектной модели DTE (Visual Studio).
Это действительно плохая идея.
Ralf Meier
Поместить данные в статический класс тоже можно было бы, но я понятия не имею, как это реализовать ...
Dave Kreskowiak
И я тоже. Вот тут-то и появляется куча исследований.
Я бы, наверное, начал с:
Custom DesignerSerializationVisibilityAttribute - Поиск В Google[^]
Создание пользовательских редакторов и дизайнеров[^]
и
Обзор Сериализации Конструктора[^]
Ralf Meier
Спасибо за ссылку ... но с большинством из них я знаком ...
Моя единственная проблема заключается в том, где (и, возможно, как) хранить "общие" данные ...