Архив рубрики: Visual Studio

Скрыть окно IntelliSense в Visual Studio

Нет, я знаю что кнопка Esc закрывает это окно. Но бывает пишешь код, выскакивает окошко IntelliSense и в нем надо что-то выбрать, но вот перед тем как это что-то выбрать, надо посмотреть что там по этим окошком с подсказками. Есть "старый" вариант нажать Esc, посмотреть что там нужно и нажать Ctrl+Space чтобы опять открыть окно с подсказками. Но сейчас в Visual Studio пришла горячая клавиша зажатый Ctrl. Да, не нажать отпустить, а именно зажать:
Окошко скрывается, а все что находиться под ним замечательно видно.

Об использовании событий pre-build и post-build в Visual Studio

В некоторых проектах, создаваемых при помощи Visual Studo, возникает необходимость выполнения различного рода дополнительных операций в pre-build [и | или] post-build.

Если исходный код проекта находится в сети, а не на локальном диске, то открывать его следует в Visual Studio через предварительно подключенный сетевой диск. Т.е. например, если исходный код проекта находится в каталоге "\\hyprostr\dfs\groups\developers\src\DwgSaveAs\", то следует предварительно создать сетевой диск при помощи команды NET ADD:

net add Y: "\\hyprostr\dfs\groups\developers"

После этого, открывать в IDE проект, находящийся в сети, всегда следует путём указания каталога "Y:\src\DwgSaveAs\", вместо его сетевого имени "\\hyprostr\dfs\groups\developers\src\DwgSaveAs". В этом случае значения переменных ProjectDir, TargetDir и т.п. будут так же содержать значения, начинающиеся с "Y:\", а не с "\\hyprostr\". Это позволит в pre-build и post-build использовать команды такие как COPY, т.е. такие, которые обычно не могут работать с UNC-путями.

Предположим, что в событии post-build нашего проекта размещена такая команда:

COPY /Y "$(ProjectDir)teigha_vc11_amd64dll\*" "$(TargetDir)*"

Если проект будет открыт в IDE с использованием сетевого пути ("\\hyprostr\..."), а не сетевого диска "Y:\...", то попытка выполнить операцию, обозначенную в post-build будет неудачной. Если же проект будет открыть с использованием сетевого диска, то обозначенная в команде операция будет выполнена успешно.

Циклы в pre-build и post-build

Обозначенная выше команда, размещённая в post-build, может оказаться нецелесообразной в использовании, если выполняется копирование большого количества файлов. В подобных случаях процесс сборки проекта может занимать времени больше, чем нам бы того хотелось. Да и вообще, каждый раз выполнять копирование файлов, не подвергавшихся изменению, не целесообразно...

Порой нам нужно копировать только такие файлы, которых ещё нет целевом каталоге. Например, это могут быть файлы библиотек сторонних разработчиков. Чтобы копировать только отсутствующие в целевом каталоге файлы, в нашем post-build предыдущий вариант команды можно заменить таким:

For %%F In ("$(ProjectDir)teigha_vc11_amd64dll\*.*") Do If Not Exist "$(TargetDir)%%~nxF" Copy "%%F" "$(TargetDir)%%~nxF"

Внимание!
Обратите внимание на то, что все символы % в данном случае должны быть продублированы. В этом нет необходимости в BAT-файлах, но при использовании подобных выражений в составе pre-build или post-build проектов Visual Studio такая потребность имеется.

Примечание
Несмотря на то, что решения открываемые через сетевой диск отображаются в группе Recent вкладки Start Page, тем не менее Visual Studio 2015 Update 2 не умеет их открывать через соответствующую ссылку, если пытаться сделать это сразу после запуска IDE. При попытке сделать это, появляется такое окошко:


Чтобы открыть решение через сетевой диск, сразу после запуска Visual Studio, придётся выбирать пункт Open Project на вкладке Start Page, или же сделать это через меню File -> Open Project/Solution. Кроме того, работает и способ открытия sln-файла решения (из сетевого диска) в Проводнике Windows.

Если затем закрыть решение, не завершая при этом работу IDE (т.е. при помощи пункта меню  File -> Close Solution), то соответствующая ссылка на решение в группе Recent будет работать. Причём работать будет и в том случае, если выбрав пункт меню File -> Open Project/Solution затем перейти в каталог решения и нажать кнопку Cancel - после этого, соответствующая ссылка в Recent сможет открывать решение. Правда всё это работает только до перезапуска IDE...


Созданеи MSI для приложений .Net

В старых версиях Visual Studio был специальный тип проекта для создания инсталяторов. О том что на месте этого проекта сейчас и что делать, под катом.

Собственно, сейчас там вот так:
При попытке создать этот проект, открывается html страничка, которая предлагает перейти на сайт Flexera (кто это такие?) и отдав им ключи от квартиры получить возможность создавать инсталяторы:
Немножко поискав, я нашел два способа создания инсталяторов без предоставления ключей от квартиры. Вот о них и поговорим.
1. Расширение для студии Microsoft Visual Studio Installer Projects. После его установки, в окне новых проектов становится доступна новая ветка в дереве и четыре проекта в ней:
Проекты создаются с минимумом настроек:
Мы указываем что будет копироваться в папку приложения, что будет создаваться на рабочем столе, ну и в меню программ. Инсталятор при запуске запросит куда устанавливать приложение, пропишет себя корректно в списке программ доступных для удаления, ну и удалится все при необходимости.
2. Второе решение это WiX Toolset. Он ставится со своего инсталятора:
После установки, в дереве новых проектов добавляется ветка с семью типами проектов:

Проект выглядит не сложнее чем из пункта 1, содержит одну XML и папку для Reference:
Добавляем ссылку на проект или проекты которые должны инсталироваться, а вот дальше... Файлик с расширением wxs позволяет в очень широких пределах настраивать наш инсталятор. Самое простое, это прописать приложение для развертывания:

Прописав только эту строку и сбилдив проект мы получаем инсталятор который единственно чем отличается от описанного в предыдущем шаге, так это тем, что не спрашивает путь для установки приложения. Но вот если мы захотим наш инсталятор настроить, то вот здесь можно впасть в кому от возможностей (если не тыкнули по ссылке, то обратите внимание на скрол):
Но о примерах этих настроек как-нибудь в другой раз.

Выводы. Если нужно написать простенький инсталятор, то ставим Microsoft Visual Studio Installer Projects и не заморачиваемся с настройками. Если нужно или с высокой вероятностью нужно будет в будующем серьезные возможности по работе с реестром, настройке мастера и так далее, то WiX Toolset вам в помощь.