Выбранный файл не является действительным файлом решения visual studio

Обновлено: 07.07.2024

У меня есть решение с несколькими проектами. Текущий режим сборки - отладка, а все проекты настроены на отладку. Но когда я пытаюсь запустить основной проект - иногда он выдает мне несколько ошибок, все из которых «файл метаданных . \Release\projectX.dll 'не может быть найден» - и, похоже, он говорит о RELEASE папка, хотя текущий режим - отладка. Зачем? Я попытался найти ссылку на «Release\projectX.dll» во всех файлах решения и нашел ее в файле ResolveAssemblyReference.cache.

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

Я пытался удалить ссылки на эти проекты и прочитать их, но через некоторое время я снова начал получать эти ошибки.

Это похоже на ошибку. Почему он выполняет поиск проектов, на которые ссылаются, в папках Release, когда я всегда использую режим Debug?

PS. Для тех, кто столкнулся с этой проблемой: я не мог решить ее простым способом. Исчезло только после переустановки винды :(

Все правильно . попробуй все . (чтобы немного потрачено много времени)

У тебя плохой код? Исправьте это сначала.
Чистое решение и перезапустите Visual Studio
Удалить/добавить ссылки
Проверьте ваш порядок сборки с большими проектами и проверьте
Перестройка подпроектов вручную
Вручную скопируйте библиотеки между проектами в связанные папки bin
Пойди принеси кофе, поиграй в пинбол и возвращайся завтра . ты можешь подумать о чем-то другом.

У меня была точно такая же проблема. Большое визуальное студийное решение с более чем 50 проектами.

Все ссылки были добавлены как проекты. Порядок сборки проекта был правильным (щелкните правой кнопкой мыши по проекту и выберите порядок сборки).

Однако при создании некоторых проектов более высокого уровня «корневой» проект, от которого они зависели, не был построен.

Проблема заключалась в том, что эти проекты не были выбраны для сборки в текущей конфигурации (не знаю, как это произошло).

Чтобы проверить это, выберите «Диспетчер конфигурации» (меню «Сборка») и проверьте, настроены ли проблемные проекты на сборку.

Когда вы говорите, что удалили ссылки на эти проекты и заново их добавили, как вы их точно добавили? Использовали ли вы вкладку «Обзор» в диалоговом окне «Добавить ссылку» в Visual Studio? Или вы использовали вкладку «Проекты» (в которой перечислены соседние проекты в вашем решении)?

Правка : Если вы используете вкладку «Обзор» и вручную добавляете ссылку на вашу .dll, которая находится в папке/Release, тогда Visual Studio всегда будет искать .dll в этом месте, независимо от того, что режим, в котором вы находитесь в данный момент (Debug или Release).

Если вы удалили действительный файл .dll из папки выпуска (вручную или с помощью команды «Очистить решение»), то ваша ссылка будет прервана, поскольку файл .dll не существует.

Я бы предложил удалить ссылку на ProjectX.dll и добавить ее снова - но на этот раз используйте вкладку «Проекты» в диалоговом окне «Добавить ссылку». Когда вы добавляете ссылку таким образом, Visual Studio знает, где взять соответствующий DLL-файл. Если вы находитесь в режиме отладки, он получит его из папки/Debug. В режиме Release, папка/Release. Ваша ошибка сборки должна исчезнуть, и вы больше не будете (неправильно) ссылаться на Release .dll в режиме отладки.

Ну, мой ответ - не просто краткое изложение всех решений, но оно предлагает нечто большее.

Секция 1):

В общем решения:

У меня было 4 ошибки такого типа («файл метаданных не найден»), а также 1 ошибка «Не удалось открыть исходный файл (« ошибка не определена »)».

Я попытался избавиться от ошибки «файл метаданных не найден». Для этого я прочитал много постов, блогов и т.д. И обнаружил, что эти решения могут быть эффективными (обобщая их здесь):

Перезапустите VS и попробуйте собрать снова.

Перейдите к 'Solution Explorer'. Щелкните правой кнопкой мыши на Решение. Перейдите в Свойства. Перейдите к 'Configuration Manager'. Проверьте, установлены ли флажки под 'Build' или нет. Если какие-либо или все из них не отмечены, то проверьте их и попробуйте построить заново.

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

Порядок сборки и зависимости проекта:

Перейдите к 'Solution Explorer'. Щелкните правой кнопкой мыши на Решение. Перейдите к 'Зависимости проекта . '. Вы увидите 2 вкладки: 'Зависимости' и 'Порядок сборки'. Этот порядок сборки является тем, в котором строится решение. Проверьте зависимости проекта и порядок сборки, чтобы убедиться, что какой-либо проект (скажем, «проект1»), который зависит от другого (скажем, «проект2»), пытается построить этот проект (проект2). Это может быть причиной ошибки.

Проверьте путь к отсутствующей .dll:

Проверьте путь к отсутствующему .dll. Если путь содержит пробел или любой другой недопустимый символ пути, удалите его и попробуйте построить заново.

Если это причина, то отрегулируйте порядок сборки.

Раздел (2):

Мой конкретный случай:

Я попробовал все шаги выше с различными перестановками и комбинациями с перезапуском VS несколько раз. Но это не помогло мне.

Итак, я решил избавиться от другой ошибки, с которой мне пришлось столкнуться («Невозможно открыть исходный файл (error Неуказанная ошибка‘) »).

Я попытался выполнить шаги, упомянутые в этом блоге, и избавился от ошибки 'Исходный файл не может быть открыт (' Unspecified error ')', и неожиданно я избавился от других ошибок ('файл метаданных не может быть найдено ').

Раздел (3):

Мораль истории:

Попробуйте все решения, как указано в разделе (1) выше (и любые другие решения), чтобы избавиться от ошибки. Если ничего не получается, как описано в блоге, упомянутом в разделе (2) выше, удалите записи всех исходных файлов, которых больше нет в исходном элементе управления и файловой системе, из файла .csproj.

У меня была эта проблема раньше, и я нашел единственный способ ее решения - запустить Clean Solution, а затем перезапустить Visual Studio.

Для меня обычно целевая платформа отключена (4.5.2 вместо 4.6). Если вы исправите целевую инфраструктуру проекта так, чтобы она соответствовала целевой платформе решения и сборки, будет создан новый .dll.

Снова откройте Visual Studio с правами администратора.

Вы проверили настройки диспетчера конфигурации? В диалоге настроек проекта в правом верхнем углу.

Иногда случается так, что между всеми записями выпуска появляется запись отладки . Если это так, автоматическая зависимость, созданная графом зависимостей решения, запутывается.

У меня была такая же проблема сама.

Visual Studio 2013 только сказал мне, что не может ссылаться на него и не может найти метаданные. Когда я открыл свое решение (в котором есть несколько проектов), он сказал, что я использую проекты ниже, чем базовая версия одного из моих проектов.

Поэтому я перешел на версию 4.5, и она снова заработала.

Это было некоторое время назад, и, возможно, исправление даже вошло в Visual Studio 2008; Я больше не следил за этим. Тем не менее, наш типичный обходной путь был

Конфигурация коммутатора
Перезапустите Visual Studio
Постройте решение

Эта проблема связана с файлами pdb или CodeContracts.

Чтобы решить это:

Очистите выходную папку и перестройте решение.

Переконфигурируйте CodeContracts или отключите его для временной сборки.

У меня была эта проблема, и мне потребовалось много времени, чтобы понять ее. Проблема возникла, когда я удалил проекты из решения и заменил их пакетами nuget.

Решение, похоже, было хорошим, но файл .csproj по-прежнему содержал эти проекты несколько раз в качестве ссылки.

Кажется, что VS не очищает этот файл соответствующим образом. Он все еще ссылался на удаленные проекты под капотом. Когда вручную удалены ссылки из файла csproj, все снова работает! Wohoo

В моем случае у меня были некоторые ошибки в моем коде. Visual Studio показала вашу ошибку вместо реальных ошибок, таких как синтаксические ошибки или неизвестные имена классов. Попробуйте очистить решение и построить проект после проекта. Таким образом, вы обнаружите фактические ошибки.

Опять же, это как раз то, что вызывает ошибку для me .

В моем случае это было вызвано двумя причинами (VS.2012):

1) Один из проектов был настроен для AnyCPU вместо x86

2) Проект, на который ссылались, как-то не отмечен.

Проверьте свою сборку | Configuration Manager, чтобы получить обзор того, что строится и для какой платформы. Также убедитесь, что вы проверили его для Debug & Release, так как они могут иметь разные настройки.

Мы недавно столкнулись с этой проблемой после обновления до Office 2010 с Office 2007 - нам пришлось вручную изменить ссылки в нашем проекте на версию 14 взаимодействий Office, которые мы используем в некоторых проектах.

Надеюсь, это поможет - нам понадобилось несколько дней, чтобы понять это.

Я также видел эту ошибку в решениях, в которых у меня есть несколько проектов (обычно это проекты netTiers, в которых я обновил один или несколько подпроектов для платформы 4.0). Это может быть проблематично удалить. Однако зачастую это можно устранить, сначала исправив все другие ошибки в подпроектах (например, любые отсутствующие ссылки), по отдельности перестроив эти подпроекты, а затем удалив/добавив обратно любые ссылки на эти подпроекты в Visual Studio. Лично мне не повезло, что я решил эту ошибку, очистив решение в одиночку.

Я закончил тем, что удалил свои ссылки (я добавил их должным образом, используя вкладку проектов, и они обычно строили очень хорошо), вручную отредактировал мои файлы .csproj и удалил странные записи, которые не принадлежали - и установил мои выходные данные для отладки и release, x86 и x64 и все остальные процессоры должны быть "\ bin" - я собрал его один раз, затем снова добавил ссылку (снова, используя вкладку проектов), и все снова заработало для меня. Не нужно было перезапускать Visual Studio вообще.

Кажется, я вспомнил, что у меня была похожая проблема несколько месяцев назад. Я решил эту проблему временно, скопировав ссылку DLL в папку Release, что соответствует ожиданиям Visual Studio. Позже я обнаружил ссылку на Release DLL в моем реальном коде. Вы должны попытаться выполнить поиск по всему проекту для\release\project.dll.

Кроме того, я заметил, что проекты модульных тестов Visual Studio иногда помещают атрибут «DeploymentItem» в каждый из методов тестирования, указывающий на вашу целевую DLL, и если вы переключаетесь между Debug и Release, Visual Studio может запутаться, если DLL больше не находится в ожидаемом месте. По моему опыту, эти атрибуты можно безопасно удалить, если вы сами их не поместили в рамках сценария «одиночного развертывания».

Для меня это было вызвано тем, что цель сборки была переписана, чтобы не выводить dll. Устранение этой ошибки для возврата к цели Build по умолчанию устранило проблему.

Чтобы решить эту проблему, я переключаю обратно на любой процессор:
1. Щелкните правой кнопкой мыши по решению и выберите свойства.
2. Нажмите Свойства конфигурации, а затем кнопку Диспетчер конфигурации .
3. В разделе Платформа активного решения выберите Любой процессор.

Я обнаружил, что это обычно происходит со мной, когда у меня все еще есть объявление метода в интерфейсе, который реализует класс, но позже я удалил его и забыл удалить его из интерфейса. Обычно я просто сохраняю все решение каждые 30 минут, а затем просто возвращаюсь к более ранней версии, если не могу найти ошибку.

У меня была эта проблема, и это было из-за недопустимого метода в библиотеке-нарушителе (dll), которая не возвращала значение, например.

Когда я это прокомментировал, все скомпилировалось :)

У меня возникла эта проблема, когда я пытался добавить ссылку на проект, и после долгих поисков и проб со многими из вышеперечисленных параметров конфигурация и результаты моей сборки были правильными.

Наконец, я просто удалил папки\bin и\obj из исходного проекта и ссылок.

Честно говоря, я считаю, что это была папка obj , не содержащая правильных метаданных или поврежденных метаданных.

Все исправлено сейчас.

Обновление:

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

Это, казалось, исправило это до сих пор на последующих сборках.

Пример ссылки в файле .csproj

Была такая же проблема сегодня.

Мое приложение, приложения Windows Forms, случайно имело ссылку на себя. Weird.

После удаления ошибка исчезла.

Ссылка добавлялась каждый раз, когда я перетаскивал пользовательский элемент управления, расположенный в самом проекте Windows Forms, в форму.

Щелкните правой кнопкой мыши на Решение
Выберите Порядок сборки проекта
Посмотрите список проектов в Project Build Order
Создайте каждый из ваших проектов в таком порядке
Проверьте вывод

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

ПРОВЕРЬТЕ ПУТЬ ПРОЕКТА. У него не должно быть неправильных символов, таких как запятая и пробел

например, это неправильный путь: d:\мои приложения\Project1

и это верный путь d:\my_applications\Project1

Также некоторые инструменты установки имеют ту же проблему при запуске установки и не могут быть извлечены.

Проверьте, скрыта ли папка .vs в корне проекта или нет. Мой не был (и должен), так как я сделал копирование/вставку с другого компьютера. Удаление проблемы решило проблему, Visual Studio 2015 просто воссоздала его для меня.

У меня была та же проблема, и причина этой проблемы в том, что файл эталонного проекта dll используется каким-то другим процессом. В моем случае я отлаживал приложение, и приложение было присоединено к отладчику Visual Studio. Когда я перестраивал другое приложение, использующее тот же проект, я получал эту ошибку. После удаления я смог успешно создать второе приложение.

Проблема была решена. Я открыл настройки диспетчера пакетов и нажал «Разрешить NuGet загружать отсутствующие пакеты». Проект сейчас строит.

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

У меня такая же проблема. Я заметил, что мой контекст БД (EF4), который находился в dll проекта, по какой-то причине не был распознан. Я удалил его и создал еще один. и это решило это для меня.

Используете ли вы в своем проекте инструмент для генерации кода базы данных, такой как SQLMETAL?

Если это так, вы можете столкнуться с проблемой перехода от плюрализма к неплюрализованному.

В моем случае я отметил, что некоторые старые имена таблиц с множественным числом (*) (к которым SQLMETAL по умолчанию добавляет букву "s" в конце) ссылаются на классы, сгенерированные SQLMETAL.

С тех пор я недавно отключил плюрализацию имён, после перерегистрации некоторых классов, связанных с базой данных, некоторые из них потеряли префикс "s". Поэтому все ссылки на затронутые классы таблиц стали недействительными. По этой причине у меня есть несколько ошибок компиляции, таких как следующие:

«xxxx» не содержит определения для «TableNames», и не может быть найдено никакого метода расширения «TableNames», принимающего первый аргумент типа «yyyy» (вам не хватает директивы using или ссылки на сборку?)

Как вы знаете, я принимаю только ошибки, чтобы предотвратить сборку сборки. И это значит, что отсутствующая сборка связана с зависимыми сборками, в результате чего оригинальный файл метаданных «XYZ» не может быть найден ».

После того, как я вручную исправил ссылки на таблицы классов в их текущих именах (неплюрализованные), я наконец смог вернуть свой проект к жизни!

В этом посте много полезных советов. Просто добавил еще один.

Откройте файл .csproj в текстовом редакторе и найдите пропавшие файлы, удалите, сохраните и будьте счастливы.

У меня тоже была эта проблема сегодня. Мой был вызван циклическая зависимость . Проект А ссылается на проект Б и наоборот.

Иногда требуется выполнить отладку приложения (EXE-файл), которое не является частью решения Visual Studio. Это может быть проект с открытой папкой, вы или кто-то другой мог создать приложение вне Visual Studio или вы получили приложение в другом месте.

Для проекта с открытой папкой в Visual Studio (без файла проекта или решения) см. статью Выполнение и отладка кода или (для C++) Настройка параметров отладки с помощью launch.vs.json.

Для приложения, которое не существует в Visual Studio, отладка обычно выполняется путем запуска за пределами Visual Studio, а затем присоединения с помощью функции Присоединение к процессу в отладчике Visual Studio. Дополнительные сведения см. в статье Присоединение к выполняемым процессам.

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

Функции отладки для приложения, не созданного в Visual Studio, ограниченны, независимо от того, присоединяетесь ли вы к нему или добавляете в решение Visual Studio.

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

Если у вас нет исходного кода и у приложения нет отладочной информации в совместимом формате, вам доступно немного функций отладки.

Создание EXE-проекта для существующего приложения

В Visual Studio последовательно выберите Файл > Открыть > Проект.

В диалоговом окне Открыть проект выберите Все файлы проекта, если они еще не выбраны, в раскрывающемся списке рядом с полем Имя файла.

Перейдите к EXE-файлу, выберите его и щелкните Открыть.

Файл появится в новом временном решении Visual Studio.

Запустите отладку приложения, выбрав команду выполнения, например Начать отладку в меню Отладка.

Чтобы импортировать приложение в решение Visual Studio

Перейдите к EXE-файлу, выберите его и щелкните Открыть.

Файл появится как новый проект в текущем решении.

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

Я получаю эту ошибку при попытке загрузить проект VS 2008 из системы управления версиями TFS:

Файл проекта был перемещен, переименован или отсутствует на вашем компьютере

После того, как я нажимаю ОК, проект говорит «недоступен». В чем проблема? Как мне решить это? У меня никогда не было этой проблемы раньше. В некоторых блогах говорилось, что нужно удалить файл .suo, но я не могу найти файл .suo. Я удалил весь проект на своем локальном компьютере, чтобы в следующий раз, когда он откроется, он создал новый, но я все еще получаю ту же ошибку.

О, как же я ненавижу TFS за то, что у меня такие головные боли!

Обычно это помогает удалить параметры пользователя решения, также называемые «SUO».

ВС до 2013 года

В старых VS он хранится как «скрытый» SolutionName.suo в той же папке, что и основной .sln файл.

VS2015 или позже

В VS2015 те же данные были перемещены в «скрытую» .vs папку в той же папке, что и основной .sln файл.

Не забудьте перезапустить Visual Studio после удаления файла Это также работает в Visual Studio 2015, хотя путь к файлу .suo был изменен на <SolutionFolder> \. Vs \ <SolutionName> \ v14 \ .suo.

Я только столкнулся с этой проблемой, используя VS 2013 после переименования проекта. Ответ Стэнли привел меня к решению:

Закрыть VS - удалить файл .suo - снова запустить VS.

Я могу ошибаться, но я не думаю, что даже видел файл .SUO, пока не закрыл VisualStudio. Просто хочу добавить - обязательно, чтобы вы закрыли VS перед удалением. Удаление файла, пока VS еще открыт, затем закрытие и повторное открытие не имеет никакого эффекта. Должен закрыться первым!

Удалите файл .suo особым образом.

TFS работает, как и большинство пакетов управления исходным кодом: он запоминает то, что он поместил на ваш компьютер, поэтому, когда вы получаете «Get Latest», ему нужно только получить изменения с момента вашего последнего «Get» вместо того, чтобы получать абсолютно все.

Это имеет одно предостережение: если вы удалите или переименуете локальные файлы на вашем диске, TFS не будет знать, что вы сделали это, и все равно будет думать, что они там, где он их оставил.

Если вы затем «Get Latest», он не потрудится обновить отсутствующие файлы.

Тогда вы, вероятно, получите все виды ошибок «отсутствующих файлов» от TFS и любых других инструментов, которые ищут файлы.

Чтобы обойти это, вам необходимо:

Если вы считаете, что у вас могут быть какие-то изменения, которые вы не хотите потерять, скопируйте исходную папку на свой компьютер в качестве резервной копии на всякий случай!
Щелкните правой кнопкой мыши проект (в Solution Explorer) или папку (в Source Control)
Выберите «Получить конкретную версию» из контекстного меню
Выберите, чтобы получить «Последнюю версию», и отметьте опцию, которая говорит (что-то вроде) «принудительно получать файлы, уже находящиеся в вашем рабочем пространстве», что говорит TFS забыть о том, что он «знает», и в любом случае снова получить все файлы.

Если у вас есть локально измененные (доступные для записи) файлы, будьте осторожны. Есть второй вариант, который перезапишет их, потеряв ваши изменения. Но у вас есть резервная копия, поэтому вы должны быть в безопасности. Как правило, этот параметр также лучше ставить, чтобы убедиться, что весь ваш исходный код полностью обновлен. (Но, очевидно, только если вы не против потерять локальные изменения!)

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

В отличие от простейших программ, таких как "Hello World", большинство приложений состоит из нескольких исходных файлов. Это обстоятельство порождает массу проблем, в частности, как назвать файлы, где их разместить и можно ли их использовать повторно. В интегрированной среде разработки Visual Studio принята концепция решения (solution), состоящего из ряда проектов, которые в свою очередь состоят из ряда элементов, благодаря которой разработчики могут работать с исходными файлами. Интегрированная среда разработки имеет множество встроенных инструментов, позволяющих упростить этот процесс, обеспечив разработчикам доступ к большей части их приложений. Далее рассматриваются структура решений и проектов, доступные типы проектов и способы настройки их конфигурации.

Структура решения

Работая с системой Visual Studio, пользователь открывает решение. При повторном редактировании специальных файлов создается временное решение, которое можно уничтожить по окончании работы. Однако решение позволяет управлять текущими файлами, поэтому в большинстве случаев его сохранение означает, что пользователь может вернуться к тому, что он делал накануне, и вновь открыть файлы, с которыми он работал.

Наиболее распространенным способом структурирования приложений в среде Visual Studio является одно отдельное решение, содержащее много проектов. Каждый проект можно создать из набора исходных файлов и папок. Главное окно, в котором пользователь работает с решениями и проектами, называется Solution Explorer:

Для организации работы с исходным кодом и предотвращения его ассоциации с приложениями (за исключением веб-приложений, в которых существуют специальные папки, имеющие особое предназначение в данном контексте) используются папки (folders). Некоторые разработчики используют имена папок, соответствующие пространствам имен, которым принадлежат классы. Например, если класс Person находится в папке DataClasses в проекте FirstProject, то полностью квалифицированное имя класса может выглядеть как FirstProject.DataClasses.Person.

Папки решения (solution folders) - полезный способ организации проектов в большом решении. Они отображаются только в окне Solution Explorer - физически в файловой системе их не существует. Такие действия, как Build или Unload, можно легко выполнять над всеми проектами, включенными в папку решения. Для того чтобы разгрузить окно Solution Explorer, папки решения могут быть свернуты или скрыты.

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

Папка Miscellaneous Files - это специальная папка решения, которую можно использовать для того, чтобы следить за тем, какие еще файлы, не являющиеся частью какого-либо проекта в решении, были открыты в системе Visual Studio. По умолчанию папка Miscellaneous Files скрыта. Для того чтобы сделать ее видимой, следует выполнить команду Tools --> Options --> Environment --> Documents --> Show Miscellaneous Files.

Несмотря на то что формат файла решения, принятый в предыдущих версиях, не изменился, в системе Visual Studio 2010 открыть файл решения, созданный в версии Visual Studio 2013, невозможно.

Кроме информации о файлах, содержащихся в приложении, файлы решения и проектов могут содержать и другие записи, например, о том, как именно должен быть скомпилирован конкретный файл, об установках проекта, о ресурсах и многом другом. Система Visual Studio 2013 имеет немодальное диалоговое окно для редактирования свойств проекта, в то время как свойства решения по-прежнему открываются в отдельном окне. Как и следовало ожидать, свойствами проекта считаются те свойства, которые относятся только к данному проекту, например информация о сборке и связях, а свойства решения определяют общую конфигурацию для сборки приложений.

Формат файла решения

Система Visual Studio 2013 фактически создает для решения два файла, имеющих расширения .suo и .sln (solution file). Первый - это довольно неинтересный бинарный файл, который сложно редактировать. Он содержит информацию, специфичную для пользователя, например, какие файлы были открыты, когда решение закрывалось в последний раз и где находились контрольные точки. Этот файл скрыт, поэтому он не должен появляться в папке решения при использовании Windows Explorer, если не снять с него соответствующую метку.

Иногда файл .suo оказывается поврежденным, и это вызывает непредсказуемые последствия при сборке и редактировании приложений. Если при работе с конкретным решением система Visual Studio становится нестабильной, необходимо выйти из нее и удалить файл с расширением .suo. Он будет создан заново системой Visual Studio, когда решение будет открыто в следующий раз. Файл решения с расширением .sln содержит информацию о решении, например список проектов, конфигурации сборки и другие настройки, не специфичные для проекта. В отличие от многих файлов, используемых в системе Visual Studio 2013, файл решения не является XML-документом. Он хранит информацию в блоках, как показано в следующем примере:

В этом примере решение состоит из трех проектов (GettingStarted, Information Services и Reference Library), а раздел Global содержит настройки, которые применяются к решению. Например, само решение будет видимым в окне Solution Explorer, потому что настройка HideSolutionNode установлена равной FALSE. Если изменить ее на TRUE, имя решения не будет отображаться в системе Visual Studio.

Свойства решения

Для того чтобы открыть диалоговое окно Properties, необходимо щелкнуть правой кнопкой мыши на узле Solution в окне Solution Explorer и выбрать команду Properties. Это диалоговое окно содержит два узла: Common properties и Configuration properties, как показано на рисунке ниже:

Более подробно узлы Common properties и Configuration properties описываются в следующих разделах.

Узел Common Properties

Определяя проект Startup Project для приложения, пользователь имеет три возможности, которые являются практически очевидными. Выбор Current Selection запускает проект, который в данный момент находится в фокусе окна Solution Explorer. Вариант Single Startup гарантирует, что каждый раз будет запускаться один и тот же проект. Эта установка задается по умолчанию, поскольку большинство приложений имеют только один стартовый проект. Последний вариант, Multiple Startup Projects, позволяет запускать несколько проектов в определенном порядке. Это может быть полезным при работе с приложением клиент/сервер в рамках одного решения, причем требуется, чтобы и клиент, и сервер выполнялись одновременно. При выполнении нескольких проектов важно контролировать порядок их запуска. Для управления порядком запуска проектов можно использовать навигационные кнопки, расположенные после списка проектов.

Раздел Project Dependencies используется для того, чтобы задавать другие проекты, от которых зависит конкретный проект. В большинстве случаев система Visual Studio сама управляет этими свойствами, когда пользователь добавляет или удаляет связи между проектами и данным проектом. Однако иногда пользователь может самостоятельно создать связи между проектами, чтобы они собирались в заданном порядке. Система Visual Studio использует этот список зависимостей, для того чтобы определить порядок сборки проектов. Окно этого раздела предотвращает неосторожное добавление циклических связей и удаление необходимых зависимостей между проектами.

В разделе Debug Source Files можно создать список каталогов, в которых система Visual Studio может искать исходные файлы при отладке. Этот список задается по умолчанию и просматривается перед открытием диалогового окна Find Source. Кроме того, пользователь может перечислить исходные файлы, которые система Visual Studio не должна искать. Если щелкнуть на кнопке Cancel в момент, когда система предлагает найти конкретный исходный файл, то он будет добавлен в этот список.

Раздел Code Analysis Settings доступен только в версии Visual Studio Team Suite. Это позволяет выбирать набор правил статического анализа кода, которые будут применяться к конкретному проекту. Более подробно раздел Code Analysis обсуждается далее.

Узел Configuration Properties

И проекты, и решения имеют конфигурации для сборки, определяющие, какие элементы должны быть собраны и почему. Это может сбить пользователя с толку, потому что на самом деле между конфигурацией проекта, определяющей, как должны собираться элементы, и конфигурацией решения, определяющей, какие проекты должны быть собраны, нет никакой корреляции, кроме случаев, когда они имеют одинаковые имена. Новое решение определит конфигурации Debug и Release (решения), что эквивалентно сборке всех проектов в решении с помощью конфигураций Debug и Release (проекта).

Например, может быть создана новая конфигурация решения Test, состоящая из двух проектов: MyClassLibrary и MyClassLibraryTest. Когда пользователь создает свое приложение в конфигурации Test, он хочет, чтобы проект MyClassLibrary был собран в режиме Release, чтобы тестировать его в виде, максимально приближенном к окончательной версии. Однако, чтобы проверить тестируемый код, необходимо собрать тестовый проект в режиме Debug.

Когда пользователь собирает проект в режиме Release, он не хочет, чтобы решение Test было собрано или развернуто вместе с приложением. В данном случае в конфигурации решения Test можно указать, что пользователь хочет, чтобы проект MyClassLibrary был собран в режиме Release, а проект MyClassLibraryTest вообще не собирался.

Пользователь может легко переключаться между этими конфигурациями с помощью меню Configuration стандартной инструментальной панели. Однако, переключаться между платформами не так легко, потому что меню Platform нет ни в одной инструментальной панели. Для того чтобы сделать ее доступной, необходимо выбрать команду View --> Toolbars --> Customize. Затем элемент Solution Platforms из категории Build на закладке Command можно перетащить на инструментальную панель.

Следует отметить, что, выбрав узел Configuration Properties в диалоговом окне Solution Properties, как показано на рисунке ниже, можно получить доступ к раскрывающимся спискам Configuration и Platform. Раскрывающийся список Configuration содержит все доступные конфигурации решения: Debug и Release (заданные по умолчанию), Active и All Configurations. Аналогично в раскрывающемся списке Platform перечислены все доступные платформы. Как только пользователь получит доступ к этим раскрывающимся спискам, он может на этой же странице задать настройки для каждой конфигурации и/или платформы. Для того чтобы добавить новые конфигурации и/или платформы для решения, пользователь может также использовать кнопку Configuration Manager.

При добавлении новых конфигураций решения существует возможность (предусмотренная по умолчанию) создания соответствующих конфигураций для существующих проектов (по умолчанию все проекты будут собираться в новой конфигурации решения), а также возможность создать новую конфигурацию на основе существующих. Если флажок Create Project Configurations установлен и новая конфигурация основана на существующей, то новые конфигурации проекта будут копировать конфигурации проекта, заданные для существующей конфигурации.

Возможности, доступные для создания новых платформенных конфигураций, ограничены типами доступных центральных процессоров: Itanium, x86 и x64. Новая платформенная конфигурация также может основываться на существующих платформенных конфигурациях, и существует возможность создания платформенной конфигурации для проекта.

В конфигурационном файле решения можно также задать тип центрального процессора, для которого оно собирается. Это особенно удобно, если нужно развернуть приложение для компьютеров с 64-битовой архитектурой. Установить настройки для всех этих решений можно непосредственно в контекстном меню, которое открывается после щелчка правой кнопкой мыши на узле Solution node в окне Solution Explorer. В то время как команда Set Startup Projects открывает окно конфигурации решения, команды Configuration Manager, Project Dependencies и Project Build Order открывают окно Configuration Manager and Project Dependencies. Команды Project Dependencies и Project Build Order отображаются в окне, только если решение состоит из нескольких проектов.

Команда Project Build Order открывает окно Project Dependencies и перечисляет порядок сборки, как показано на рисунке ниже:

Закладка Build Order демонстрирует порядок, в котором должны собираться проекты в соответствии с зависимостями между ними. Это может оказаться полезным, если пользователь поддерживает ссылки на бинарные сборки проектов, а не ссылки на проекты. Кроме того, эту возможность можно использовать для двойной проверки того, что проекты будут собраны в правильном порядке.

Читайте также: