"Chernyavskiy" <80634@users.rsdn.ru> wrote in message news:3341777@news.rsdn.ru...

>>>>> Необходимо сохранить установку Environment из закладки Configuration Properties/Debugging.
>>>>>
>>>>> При сохранение проекта, данная настройка попадает не в основной .vsproj, а в .vcproj.USERNAME.user, что недопустимо, т.к.
>>>>> я готовлю примеры, которые будут распространяться вместе с продуктом.
>>>>>
>>>>> Пробовал использовать Property Sheets (.vsprops), однако в них нет Environment.
>>>>>
>>>>> Суть борьбы за сохранность Environment кроется в необходимости загрузки DLL не из текущего каталога. Притом, каталог не обязан быть прописан в PATH.
>>>
>>> S>Dll, путь к которой надо указывать, откуда берется?
>>> DLL собираются при сборке основного проекта. Разрабатываемые мною сэмплю призваны показать конечному пользователю пример сипользования
>>> возможностей данных DLL.
>
> S>Ну так и переделать сэмплы так, чтобы Dll собиралась при сборке основного проекта в нужную директорию. Насколько помню, последние версии студии так по дефолту и делают.
> Так не получится. Во-первых, DLL много. Так что логично, что они лежат в отдельном каталоге.
> Во-вторых, сэмплов тоже много. Копировать все необходимые DLL в каждый сэмпл — много места лишнего потребуется, да и клиентов оттолкнет.

Дело хозяйское. Вариантов вижу ровно 2:
1) попробовать найти в студии недокументированные особенности, например скопировав отвечающий за Environment кусок XML из vcproj.USERNAME.user в нужный vsprops. На мой взгляд, есть неплохие шансы на то, что оно его смерджит и не выкинет. Правда, такие же шансы я вижу и у варианта, когда найденный сейчас хак перестанет работать в следующей версии студии. Что оттолкнет клиентов значительно сильнее.
2) использовать delayload (там изначально хуки предусмотрены), ищущий dll по нужным путями. Пути (относительные) придется хардкодить.
Ну а лично я бы не заморачивался и все сложил в кучу — и экзешники, и dll.