Для чего нужна папка obj

3D форматы

Импортирование мешей в Unity может быть выполнено с помощью двух основных типов файлов:

1. Экспортированные 3D форматы файлов, такие как .FBX или .OBJ
2. Собственные файлы 3D приложений, например такие как .Max и .Blend файлы из 3D Studio Max и Blender.

Любой из этих типов позволит вам добавлять свои меши в Unity, но есть соображения относительно того типа, который вы выберите:

Экспортированные 3D файлы

Unity может читать .FBX, .dae (Collada), .3DS, .dxf и .obj файлы, obj или Collada экспортеры могут быть найдены для многих приложений, точно также как FBX экспортеры могут быть найдены здесь

Преимущества:

• Экспортируйте только необходимые данные
• Проверяемые данные (перед импортированием в Unity, переимпортируйте в 3D пакет)
• Как правило файлы меньшего размера
• Поддерживает модульный подход — к примеру разными компонентами для интерактивности и типов коллизий
• Поддерживает другие 3D пакеты, чьи форматы не поддерживаются у нас напрямую

Недостатки:

• Может замедлять процесс прототипирования и итераций
• Легче потерять след между исходной (рабочий файл) и игровой версией данных (к примеру экспортированный FBX файл)

Собственные файлы 3D приложений

Unity также может импортировать, путём конвертации, файлы: Max, Maya, Blender, Cinema4D, Modo, Lightwave и Cheetah3D , например, .MAX, .MB, .MA и др.

Преимущества:

• Быстрый процесс итерации (для повторного импортирования в Unity сохраните исходный файл)
• Изначально просто

Недостатки:

• На машинах, задействованных в работе над Unity проектом, должны быть установлены лицензионные копии данного программного обеспечения
• Файлы, содержащие ненужные данные могут стать неоправданно большими
• Большие файлы могут замедлить процесс автосохранения
• Меньше проверяется, поэтому труднее устранить ошибки

Изменение выходного каталога сборки

Область применения:Visual Studio Visual Studio для Mac Visual Studio Code

Вы можете указать расположение выходных данных проекта для каждой конфигурации (для отладки, выпуска или и того и другого).

Изменение выходного каталога сборки

1. Чтобы открыть страницы свойств проекта, в обозревателе решений щелкните узел проекта правой кнопкой мыши и выберите пункт Свойства.
2. В зависимости от типа проекта выберите соответствующую вкладку.
   • Для C# выберите вкладку Сборка.
   • Для Visual Basic выберите вкладку Компиляция.
   • Для C++ или JavaScript выберите вкладку Общие.
3. В раскрывающемся списке конфигураций в верхней части окна выберите конфигурацию, расположение файла выходных данных которой нужно изменить (Отладка, Выпуск или Все конфигурации).
4. Найдите запись выходного пути на странице— она отличается в зависимости от типа проекта:
   • Выходной путь для проектов C# и JavaScript
   • Выходной путь сборки для проектов Visual Basic
   • Выходной каталог для проектов Visual C++

Введите путь к созданию выходных данных (абсолютным или относительно корневого каталога проекта) или выберите «Обзор «, чтобы перейти к этой папке.

Для некоторых проектов в путь сборки по умолчанию включаются платформа и среда выполнения. Чтобы они не включались, в обозревателе решений щелкните узел проекта правой кнопкой мыши, выберите команду Изменить файл проекта и добавьте следующее:

 false false  

Если выходные данные не создаются в указанном расположении, убедитесь, что выполняется сборка соответствующей конфигурации (например, Отладка или Выпуск), выбрав ее в строке меню Visual Studio.

Изменение выходного каталога сборки

В Visual Studio 2022 существуют разные пользовательские интерфейсы конструктора проектов в зависимости от типа проекта. C# платформа .NET Framework и все проекты Visual Basic используют устаревший конструктор проектов .NET, но проекты C# .NET Core (и .NET 5 и более поздних версий) используют текущий конструктор проектов .NET. Проекты C++ используют собственный пользовательский интерфейс страниц свойств. Действия, описанные в этом разделе, зависят от используемого конструктора проектов.

Изменение выходного каталога сборки с помощью устаревших страниц свойств конструктора проектов .NET или C++

1. Щелкните правой кнопкой мыши узел проекта в Обозреватель решений и выберите «Свойства«.
2. В зависимости от типа проекта выберите соответствующую вкладку.
   • Для C# выберите вкладку Сборка.
   • Для Visual Basic выберите вкладку Компиляция.
   • Для C++ или JavaScript выберите вкладку Общие.
3. В раскрывающемся списке конфигураций в верхней части окна выберите конфигурацию, расположение файла выходных данных которой нужно изменить (Отладка, Выпуск или Все конфигурации).
4. Найдите запись выходного пути на странице— она отличается в зависимости от типа проекта:
   • Выходной путь для проектов C# и JavaScript
   • Выходной путь сборки для проектов Visual Basic
   • Выходной каталог для проектов Visual C++

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

Для некоторых проектов в путь сборки по умолчанию включаются платформа и среда выполнения. Чтобы они не включались, в обозревателе решений щелкните узел проекта правой кнопкой мыши, выберите команду Изменить файл проекта и добавьте следующее:

 false false  

Изменение выходного каталога сборки с помощью текущего конструктора проектов .NET

1. Щелкните правой кнопкой мыши узел проекта в Обозреватель решений и выберите «Свойства«.
2. Разверните раздел «Сборка » и выберите подраздел «Вывод«.
3. Найдите базовый выходной путь для C#и введите путь, чтобы создать выходные данные в (абсолютный или относительный к корневому каталогу проекта) или выберите «Обзор «, чтобы перейти к этой папке. Обратите внимание, что имя конфигурации добавляется к базовому выходному пути для создания фактического выходного пути.

Примечание. Для некоторых проектов в путь сборки по умолчанию включаются платформа и среда выполнения. Чтобы они не включались, в обозревателе решений щелкните узел проекта правой кнопкой мыши, выберите команду Изменить файл проекта и добавьте следующее:

 false false  

Если выходные данные не создаются в указанном расположении, убедитесь, что выполняется сборка соответствующей конфигурации (например, Отладка или Выпуск), выбрав ее в строке меню Visual Studio.

Сборка в общий выходной каталог

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

Помещение всех выходных данных решения в общий каталог

1. Щелкните один проект в решении.
2. В меню Проект выберите пункт Свойства.
3. В каждом проекте в зависимости от типа выберите «Компиляция» или «Сборка» и задайте путь вывода или базовый выходной путь к папке, используемой для всех проектов в решении.
4. Откройте файл проекта и добавьте следующее объявление свойства в первую группу свойств.

  true  

Задание промежуточного выходного каталога для проекта (проекты .NET)

1. Откройте файл проекта.
2. Добавьте следующее объявление свойства в первую группу свойств.

  path  

rd "$(ProjectDir)obj" /s /q 

Связанный контент

• Сведения о странице сборки в конструкторе проектов (C#)
• Сведения о странице свойств «Общие» (проект)
• Компиляция и сборка

Сборка проекта

Доброго времени суток, не знаю, правильно ли я назвал вопрос, но суть такова: Есть WPF проект, заходу в папку с проектом, там есть папки: bin, obj, Properties, Resourses и все мои исходники. В папке bin есть папка Debug, там есть exe к моей программе. Как мне в кучу собрать весь этот проект? Я имею ввиду, собрать все нужные для работы файлы в одну папку. Какие файлы нужные, какие нет?(звучит глупо,но иначе не знаю как сформулировать).

Отслеживать
51.4k 86 86 золотых знаков 267 267 серебряных знаков 505 505 бронзовых знаков
задан 13 фев 2013 в 22:19
3,339 6 6 золотых знаков 31 31 серебряный знак 54 54 бронзовых знака
Все файлы лежат в bin/Release. (Только не забудьте откомпилировать target = Release)
13 фев 2013 в 22:30

@alex91, может вам лучше подумать о создании установщика? Тогда голова не будет болеть о том, какие файлы нужны/не нужны. В Visual Studio установщик легко генерируется.

14 фев 2013 в 5:23
target = Release — Это нужно в assembly файле указать?
14 фев 2013 в 7:30
это в «Пакетном построении» лучше указать и откомпилировать.
14 фев 2013 в 8:05

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

Офигенная статья в самом MSDN: http://msdn.microsoft.com/en-us/library/e2444w33.aspx В подробностях расписано, какие виды инсталлеров можно сделать, и в чем их отличия друг от друга. Если в общем, то есть 2 пути:

• ClickOnce Application
• Windows MSI Installer

Первый — очень классный, легкий, быстрый установщик, да ещё и с автообновлялкой приложения при выходе новой версии.

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

На опыте развертывания в организации могу сказать, что использую ClickOnce, так как для небольших проектов оно подходит очень классно (кстати, GitHub и Google Chrome тоже его используют).

Устранение неполадок гибридных приложений

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

Перекрывающиеся элементы управления

Элементы управления могут не перекрываться должным образом. Windows Forms использует отдельный HWND для каждого элемента управления. WPF использует один HWND для всего содержимого на странице. Это отличие в реализации вызывает неожиданные перекрывающиеся поведения.

Элемент управления Windows Forms, размещенный в WPF, всегда отображается поверх содержимого WPF.

Содержимое WPF, размещенное в элементе управления ElementHost, отображается в z-порядке элемента управления ElementHost. Возможно перекрытие элементов управления ElementHost, но размещенное содержимое WPF не объединяется и не взаимодействует.

Дочернее свойство

Классы WindowsFormsHost и ElementHost могут размещать только один дочерний элемент управления или элемент. Для размещения нескольких элементов управления или элементов необходимо использовать контейнер в качестве дочернего содержимого. Например, можно добавить элементы управления флажка и кнопки Windows Forms к элементу управления System.Windows.Forms.Panel, а затем назначить панель свойству Child элемента управления WindowsFormsHost. Однако нельзя добавить элементы управления кнопки и флажка отдельно к одному и тому же элементу управления WindowsFormsHost.

Масштабирование

WPF и Windows Forms имеют разные модели масштабирования. Некоторые преобразования масштаба WPF являются показательными для элементов управления Windows Forms, а некоторые — нет. Например, масштабирование элемента управления Windows Forms к 0 будет работать, но если попытаться масштабировать тот же элемент управления обратно на ненулевое значение, то размер элемента управления останется равным 0. Дополнительные сведения см. в разделе Вопросы, связанные с макетом элемента WindowsFormsHost.

Адаптер

При работе с классами WindowsFormsHost и ElementHost может возникать путаница, так как они содержат скрытый контейнер. Оба класса WindowsFormsHost и ElementHost имеют скрытые контейнеры, называемые адаптером, которые они используют для размещения содержимого. Для элемента WindowsFormsHost адаптер является производным от класса System.Windows.Forms.ContainerControl. Для элемента управления ElementHost адаптер является производным от элемента DockPanel. При появлении ссылок на адаптер в других разделах взаимодействия, этот контейнер становится контейнером, о котором шла речь.

Вложенные операторы

Вложение элемента WindowsFormsHost в элемент управления ElementHost не поддерживается. Вложение элемента управления ElementHost в элемент WindowsFormsHost также не поддерживается.

Фокус

Фокус работает по-разному в WPF и Windows Forms, что означает, что в смешанном приложении могут возникать проблемы с фокусом. Например, если имеется фокус внутри элемента WindowsFormsHost и нужно свернуть или восстановить страницу либо показать модальное диалоговое окно, фокус внутри элемента WindowsFormsHost может быть потерян. Элемент WindowsFormsHost по-прежнему имеет фокус, но элемент управления внутри него может не иметь.

Фокус также влияет и на проверку данных. Проверка работает в элементе WindowsFormsHost, но не работает при выходе за пределы элемента WindowsFormsHost или между двумя разными элементами WindowsFormsHost.

Сопоставление свойств

Некоторые сопоставления свойств требуют всесторонней интерпретации для того, чтобы связать отличающиеся реализации между технологиями WPF и Windows Forms. Сопоставления свойств позволяют коду реагировать на изменения в шрифтах, цветах и других свойствах. В общем случае сопоставление свойств работает посредством прослушивания событий PropertyChanged или вызовов OnPropertyChanged и установки свойств либо в дочернем элементе управления, либо в его адаптере. Дополнительные сведения см. в разделе Сопоставление свойств Windows Forms и WPF.

Связанные с макетом свойства в размещенном содержимом

При назначении свойства WindowsFormsHost.Child или ElementHost.Child некоторые связанные с макетом свойства в размещенном содержимом устанавливаются автоматически. Изменение этих свойств содержимого может привести к неожиданным поведениям макета.

Размещенное содержимое присоединяется для заполнения родителя WindowsFormsHost и ElementHost. Чтобы включить это поведение заполнения, некоторые свойства задаются при установке дочернего свойства. В следующей таблице перечислены свойства содержимого, которые задаются классами ElementHost и WindowsFormsHost.

Класс узла	Свойства содержимого
ElementHost	Height

Не устанавливайте эти свойства непосредственно в размещенном содержимом. Дополнительные сведения см. в разделе Вопросы, связанные с макетом элемента WindowsFormsHost.

Приложения навигации

Приложения навигации могут не поддерживать состояние пользователя. Элемент WindowsFormsHost восстанавливает свои элементы управления в случае его использования в приложении навигации. Восстановление дочерних элементов управления происходит, когда пользователь выходит за пределы страницы, размещающей элемент WindowsFormsHost, а затем возвращается на нее. Любое содержимое, введенное пользователем, будут потеряно.

Взаимодействие с циклом обработки сообщений

При работе с циклами обработки сообщений Windows Forms сообщения могут обрабатываться не так, как ожидалось. Метод EnableWindowsFormsInterop вызывается конструктором WindowsFormsHost. Этот метод добавляет фильтр сообщений к циклу обработки сообщений WPF. Этот фильтр вызывает метод Control.PreProcessMessage в случае, если System.Windows.Forms.Control являлся целью сообщения, и преобразует либо отправляет сообщение.

Если отобразить Window в цикле обработки сообщений Windows Forms с Application.Run, то вы не сможете что-либо печатать до тех пор, пока не вызовете метод EnableModelessKeyboardInterop. Метод EnableModelessKeyboardInterop принимает объект Window и добавляет System.Windows.Forms.IMessageFilter, который перенаправляет связанные с ключом сообщения в цикл обработки сообщений WPF. Дополнительные сведения см. в разделе Windows Forms и архитектура ввода взаимодействия WPF.

Непрозрачность и организация по уровням

Класс HwndHost не поддерживает многоуровневую структуру. Это означает, что задание свойства Opacity в элементе WindowsFormsHost не дает результата, и не произойдет смешения с другими окнами WPF, свойству AllowsTransparency которых присвоено значение true .

Утилизация

Неудаленные классы вполне могут дать утечку ресурсов. Убедитесь, что в смешанных приложениях удалены классы WindowsFormsHost и ElementHost, в противном случае можно потерять ресурсы. Windows Forms удаляет элементы управления ElementHost, если закрывается его немодальный родительский элемент Form. WPF удаляет элементы WindowsFormsHost при завершении работы приложения. Элемент WindowsFormsHost можно отобразить в Window в цикле обработки сообщений Windows Forms. В этом случае код может не получить уведомление о том, что приложение завершает работу.

Включение визуальных стилей

Визуальные стили Microsoft Windows XP в элементе управления Windows Forms могут быть не включены. Метод Application.EnableVisualStyles вызывается в шаблоне для приложения Windows Forms. Несмотря на то что этот метод не вызывается по умолчанию, если вы используете Visual Studio для создания проекта, вы получите визуальные стили Microsoft Windows XP для элементов управления, если доступен Comctl32.dll версии 6.0. Метод EnableVisualStyles необходимо вызвать до создания маркеров в потоке. Дополнительные сведения см. в разделе Практическое руководство. Включение визуальных стилей в гибридном приложении.

Лицензированные элементы управления

Лицензированные элементы управления Windows Forms, отображающие в окне сообщения информацию о лицензировании, могут вызвать непредвиденное поведение для смешанного приложения. Некоторые лицензированные элементы управления отображают диалоговое окно в ответ на создание обработчика. Например, лицензированный элемент управления может информировать пользователя о том, что нужна лицензия, или о том, что у пользователя осталось три пробных запуска элемента управления.

Элемент WindowsFormsHost является производным от класса HwndHost, а обработчик дочернего элемента управления создается внутри метода BuildWindowCore. Класс HwndHost не позволяет сообщениям обрабатываться в методе BuildWindowCore, но отображение диалогового окна вызывает отправку сообщений. Чтобы включить этот сценарий лицензирования, вызовите метод Control.CreateControl в элементе управления перед тем, как назначить его дочерним элементом для WindowsFormsHost.

Конструктор WPF

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

Во время разработки игнорируется BackColorTransparent

Во время разработки свойство BackColorTransparent может не работать должным образом.

Если элемент управления WPF не находится на видимом родителе, среда выполнения WPF игнорирует значение BackColorTransparent. Причина того, что значение BackColorTransparent может быть проигнорировано, заключается в том, что объект ElementHost создается в отдельном AppDomain. Однако при запуске приложения BackColorTransparent не работает должным образом.

При удалении папки obj появляется список ошибок времени разработки

Если удаляется папка obj, появляется список ошибок времени разработки.

При разработке с использованием ElementHost конструктор Windows Forms использует созданные файлы в папке Debug или Release внутри папки проекта obj. При удалении этих файлов появляется список ошибок времени разработки. Для устранения этой проблемы следует перестроить проект. Дополнительные сведения см. в разделе Ошибки во время разработки в конструкторе Windows Forms.

ElementHost и IME

Элементы управления WPF, размещенные в ElementHost, сейчас не поддерживают свойство ImeMode. Изменения, внесенные в ImeMode, будут проигнорированы размещенными элементами управления.

См. также

• ElementHost
• WindowsFormsHost
• Взаимодействие в конструкторе WPF
• Windows Forms и архитектура ввода взаимодействия WPF
• Практическое руководство. Включение визуальных стилей в гибридном приложении
• Вопросы, связанные с макетом элемента WindowsFormsHost
• Сопоставление свойств Windows Forms и WPF
• Ошибки во время разработки в конструкторе Windows Forms
• Миграция и взаимодействие систем

Совместная работа с нами на GitHub

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