отсутствует исходный код для данного объекта поскольку он относится к компилированной библиотеке
Динамически компилировать класс в App_Code, предварительно компилируя остальную часть проекта/библиотеки
Проблема в том, что я создаю веб-приложение, а не динамически скомпилированный веб-сайт. Но мне бы хотелось иметь возможность сохранять значения конфигурации непосредственно на С#, а не обслуживать через XML и читать в течение Application_Start и хранить в HttpContext.Current.Application
Итак, у меня есть следующий код в /App_Code/Globals.cs :
Что может быть в любом месте приложения следующим образом:
Цель состоит в том, чтобы иметь возможность хранить любые литералы в настраиваемой области, которые могут быть обновлены без повторной компиляции всего приложения.
Q: существует ли способ идентифицировать некоторые части проекта, которые должны динамически компилировать, позволяя предварительно скомпилировать остальную часть проекта?
Обзор проблемы
Нам нужно преодолеть две различные проблемы:
- Первый имеет один файл, который может быть скомпилирован во время сборки, а также повторно скомпилирован во время выполнения.
Во-вторых, это решение двух разных версий этого класса, созданных путем решения первой проблемы, поэтому мы можем фактически использовать их.
Первая проблема заключается в попытке получить класс, который скомпилирован и не скомпилирован. Нам нужно скомпилировать его во время разработки, чтобы другие разделы кода знали, что он существует, и могут использовать его свойства с сильной типизацией. Но, как правило, скомпилированный код исключается из вывода, поэтому не существует нескольких версий одного и того же класса, вызывающих конфликты именования.
В любом случае нам нужно сначала скомпилировать класс, но есть две возможности для сохранения повторно скомпилируемой копии:
Как минимум, это сложная задача, связанная с компилятором. Любой код, который использует класс, должен иметь гарантию, что он существует во время компиляции. Все, что динамически скомпилировано, будь то через App_Code или иначе, будет частью совершенно другой сборки. Таким образом, получение идентичного класса рассматривается как картина этого класса. Основной тип может быть одним и тем же, но ce n’est une pipe.
У нас есть два варианта: используйте интерфейс или перекресток между сборками:
Если мы используем интерфейс, мы можем скомпилировать его с помощью начальной сборки, и любые динамические типы могут реализовать тот же интерфейс. Таким образом, мы надежно полагаемся на то, что существует во время компиляции, и наш созданный класс можно безопасно поменять как свойство поддержки.
Существующие ответы
Per evk Мне нравится идея опроса AppDomain.CurrentDomain.GetAssemblies() при запуске, чтобы проверить наличие новых сборок/классов. Я соглашусь, что использование интерфейса, вероятно, является целесообразным способом унифицировать предварительно скомпилированные/динамически скомпилированные классы, но в идеале я хотел бы иметь один файл/класс, который можно просто перечитать, если он изменится.
Per S.Deepika, мне нравится идея динамической компиляции из файла, но не нужно перемещать значения в отдельный проект.
Выпуск App_Code
/App_Code/, будет динамически скомпилирован при запуске приложения. Поэтому в Visual Studio мы можем создать один и тот же класс дважды, добавив его в App_Code и установив Сборка Action в Скомпилировать.
Действие сборки и копирования:
Мы можем идентифицировать оба типа:
Скомпилированные и динамические типы:
Это действительно близко к решению проблемы №1. Мы имеем доступ к обоим типам каждый раз, когда приложение работает. Мы можем использовать скомпилированную версию во время разработки, и любые изменения самого файла будут автоматически перекомпилированы IIS в версию, доступ к которой мы можем получить во время выполнения.
Мы можем попытаться заставить свою руку как скомпилировать файл в сборку проекта, так и скопировать файл в выходной каталог. Но App_Code не работает ни в одном из этого волшебства внутри
/bin/App_Code/. Он будет работать только на корневом уровне
Источник компиляции App_Code:
С каждой публикацией мы можем вручную вырезать и вставлять созданную папку App_Code из корзины и размещать ее на корневом уровне, но в лучшем случае это нестабильно. Возможно, мы могли бы автоматизировать это в событиях сборки, но мы попробуем что-то еще.
Решение
Компилировать + (копировать на вывод и вручную компилировать файл)
Позвольте избежать использования папки App_Code, поскольку она добавит некоторые непредвиденные последствия.
Просто создайте новую папку с именем Config и добавьте класс, в котором будут храниться значения, которые мы хотим динамически изменять:
Опять же, мы захотим перейти к свойствам файла ( F4 ) и установить компиляцию AND для вывода на печать. Это даст нам вторую версию файла, которую мы можем использовать позже.
Мы будем использовать этот класс, используя его в статическом классе, который выдает значения из любого места. Это помогает разделить проблемы, особенно между необходимостью динамической компиляции и статического доступа.
И мы можем использовать его следующим образом:
Вкратце, вот что мы хотим сделать внутри конструктора:
Utilities.cs
Здесь полный исходный код для методов Utility сверху
Но почему Tho?
Хорошо, поэтому есть и другие более традиционные способы достижения одной и той же цели. В идеале мы снимаем для Конвенции > Конфигурация. Но это обеспечивает самый простой и гибкий, строго типизированный способ хранения значений конфигурации, которые я когда-либо видел.
В любом случае выход сновидений этого процесса должен состоять в том, чтобы писать и потреблять С# напрямую. В этом случае, если я хочу добавить дополнительное, полностью настраиваемое свойство, это так же просто, как добавление свойства в класс. Готово!
Он будет доступен сразу и автоматически перекомпилируется, если это значение изменится без необходимости публикации новой сборки приложения.
Динамическое изменение класса Demo:
Отсутствует исходный код для данного объекта поскольку он относится к компилированной библиотеке
Устранение Проблем, связанных с Библиотеками
Для получения дополнительной информации выберите одну из перечисленных проблем, связанных с библиотеками:
Отсутствующие Библиотечные Элементы и Отчет Загрузки Библиотеки
• Эти объекты располагались в библиотеках, которые были удалены из проекта или перемещены в другое место. Чтобы восстановить эти объекты, повторно добавьте в проект их библиотеки, воспользовавшись Менеджером Библиотек, и нажмите кнопку Перезагрузить и Применить.
Отсутствующие объекты не отображаются в проектах и заменяются размытыми точки.
Список отсутствующих объектов отображается в разделе Предупреждения, находящемся в Менеджере Библиотек. В этом списке указывается следующая информация:
• имя исходной библиотеки объекта, если она существовала, и последним известным местом ее расположения;
• количество отсутствующих объектов и количество размещенных экземпляров каждого отсутствующего объекта. Для каждого отсутствующего объекта количество его размещенных экземпляров отображается в круглых скобках.
Окно Отчета Загрузки Библиотеки появляется в том случае, если в проекте отсутствуют какие-либо объекты или если в загруженных библиотеках обнаружены дубликаты. В Отчете Загрузки Библиотеки приводится количество отсутствующих объектов с указанием в скобках общего количества размещенных экземпляров.
Временно Отсутствующие Объекты
В Менеджере Библиотек или в Отчете Загруженной Библиотеки проекта Teamwork можно увидеть папку, называющуюся “Временно Отсутствует”. Это может произойти в том случае, если пользователь вносит изменения в Библиотеку BIMcloud/BIM Сервера, приводящие к каким-либо обновлениям размещенных объектов. Если эти объекты зарезервированы любым пользователем, то все пользователи, подключенные к проекту, будут уведомлены о «Временном Отсутствии» библиотеки.
Эта проблема устраняется автоматически: все объекты перестают быть «отсутствующими» после активации пользователем команды Отправить и Получить; после этого объекты перестают быть отсутствующими.
Эти файлы относятся к неподдерживаемым форматам изображений.
Поиск и Выбор Отсутствующих Библиотечных Элементов
Для поиска и выбора отсутствующих библиотечных элементов используется функция «Найти и Выбрать».
1. В первой строке “Критериев” диалога «Найти и Выбрать» укажите Объект GDL.
2. В следующей строке критериев выберите “Библиотечный Элемент.”
3. В качестве значения выберите “Отсутствует”.
Примечание: Доступен также выбор значения “Не отсутствует”; в этом случае произойдет выбор всех экземпляров указанного типа объекта GDL за исключением отсутствующих.
4. Нажмите кнопку с изображением знака Плюс, чтобы активировать поиск.
Переименованные или перемещенные библиотеки отображаются в Менеджере Библиотек как Отсутствующие.
Список размещенных объектов из недоступных библиотек приводится в папке “Отсутствующие Библиотечные Элементы», находящейся в Отчете Загрузки Библиотеки. В проекте эти объекты заменяются размытыми точками.
Дублирующиеся Библиотечные Элементы
Список Дублирующихся Библиотечных Элементов отображается в разделе Предупреждения, находящемся в Менеджере Библиотек. Для каждого библиотечного элемента указывается место его расположения в библиотеке.
В открывшемся диалоге нажмите на черную стрелку, чтобы выбрать нужный формат отображения списка:
• Список размещенных дубликатов;
• Список всех дубликатов;
• Список всех размещаемых дубликатов;
• Список всех неразмещаемых дубликатов.
Решение Проблемы Дублирующихся Библиотечных Элементов
Наличие множества объектов-дубликатов вызывает следующие две проблемы: всякий раз при загрузке библиотек происходит загрузка лишних объектов и/или библиотек, что приводит к существенному снижению скорости работы; кроме того, наличие дубликатов приводит к дополнительной неопределенности при необходимости изменения объекта-дубликата библиотеки или сохранения его под другим именем.
Имеется несколько способов решения проблемы наличия дубликатов:
• Если библиотеки с дубликатами являются Библиотеками ARCHICAD, то лучше всего Консолидировать их.
• Если все размещенные объекты являются дубликатами одной из библиотек (то есть эти объекты также присутствуют в другой библиотеке), можно удалить первую библиотеку.
• Если библиотеки-дубликаты не являются Библиотеками ARCHICAD, можно просмотреть содержимое двух библиотек вручную (откройте папку библиотеки и просмотрите ее объекты), а затем удалить дубликаты в одной из этих библиотек.
• Если дубликаты размещенных объектов являются специфическими для проекта, можно вложить их в проект. Это также приведет к удалению библиотеки из проекта.
Объекты из этой категории размещены в проекте, но есть заменяющие их объекты (то есть объекты с таким же ID, что и у размещенных объектов, даже если их имена не совпадают) как минимум в двух связанных библиотеках. ARCHICAD случайным образом использует тот или иной объект в качестве исходного для его размещенных экземпляров.
Во избежание такой ситуации требуется вручную заменить экземпляры «заменяемых объектов» их дубликатами из загруженных библиотек.
(Для поиска размещенных экземпляров заменяемых объектов можно воспользоваться функцией Найти и Выбрать. Выберите конкретный объект из загруженных библиотек для замены этого замещаемого объекта.)
Консолидация Нескольких Библиотек ARCHICAD
При добавлении новой библиотеки ARCHICAD в проект, уже использующий библиотеку, происходит автоматическое обнаружение старых версий библиотек ARCHICAD (версии 10 и позже). В этом случае в Менеджере Библиотек появляется желтая кнопка Консолидации библиотек.
Примечание: Кнопка Консолидации появляется в Менеджере Библиотек, если в проект добавлена хотя бы одна устаревшая Библиотека, то есть Библиотека, которая не является самой последней.
Выполнение Консолидации библиотек ARCHICAD рекомендуется по следующим причинам:
• она приводит к замене старых библиотек ARCHICAD библиотеками последней версии
• загружаются нужные Библиотеки Миграции, обеспечивающие доступ к устаревшим библиотечным элементам, размещенным в проекте
• в проект не загружаются ненужные элементы, так как Библиотеки Миграции значительно меньше полных библиотек ARCHICAD
• она позволяет избежать появления ошибок, возникающих при размещении библиотечных элементов с идентичными именами из нескольких загруженных библиотек
Удаление Неиспользуемых Связанных Библиотек
В Менеджере Библиотек отображается список размещенных объектов из связанных библиотек. Если таковые объекты отсутствуют, то библиотеку можно удалить из проекта. В приведенном примере видно, что из выбранной библиотеки ARCHICAD не был размещен ни один объект; поэтому ее можно удалить.
Для удаления выбранной папки библиотеки нажмите в Менеджере Библиотек кнопку «Удаления», помеченную синим крестом.
Слишком Длинный Путь Библиотеки
Операционная система имеет ограничение в 260 символов на длину пути имени библиотечного элемента. В связи с этим может появиться сообщение о невозможности сохранения локальной копии библиотеки BIMcloud/BIM Сервера из-за слишком длинного пути.
Чтобы устранить эту проблему, воспользуйтесь одним из следующих решений:
• Упростите структуру файлов библиотеки.
Загрузите библиотеку BIMcloud/BIM Сервера в локальную папку.
Затем выполните одно из следующих действий:
— При помощи команды Файл > Библиотеки и Объекты > Создать Контейнер создайте файл контейнера (.lcf) из папки загруженной библиотеки.
— Можно также создать другую упрощенную структуру папок библиотеки (например, переместив папку библиотеки на более высокий уровень в иерархии папок, чтобы путь стал короче).
Локальные копии Библиотек BIMcloud/BIM Сервера сохраняются в Папке Локальных Данных, находящейся на жестком диске вашего компьютера.
Вы можете переместить эту папку, чтобы сократить путь к ней.
Новое место расположения должно быть на более высоком уровне иерархии папок, что делает длину пути короче.
Ошибка средств компоновщика LNK2001
Скомпилированный код создает ссылку или вызов символа. Символ не определен ни в одной из библиотек или объектных файлов, поиск которого осуществляется компоновщиком.
Это сообщение об ошибке после неустранимой ошибки LNK1120. Чтобы устранить ошибку LNK1120, сначала исправьте все ошибки LNK2001 и LNK2019.
Что такое неразрешенный внешний символ?
Символ — это внутреннее имя функции или глобальной переменной. Это форма имени, используемая или определенная в скомпилированном объектном файле или библиотеке. Глобальная переменная определяется в объектном файле, где для него выделяется хранилище. Функция определена в объектном файле, где размещается скомпилированный код для тела функции. Внешний символ является ссылкой в одном файле объекта, но определен в другой библиотеке или объектном файле. Экспортированный символ — это открытый объект, который становится общедоступным для файлового файла или библиотеки, определяющей его.
Для создания приложения или библиотеки DLL в каждом используемом символе должно быть определено определение. Компоновщик должен Разрешить или найти определение сопоставления для каждого внешнего символа, на который ссылается каждый файл объекта. Компоновщик создает ошибку, если не удается разрешить внешний символ. Это означает, что компоновщику не удалось найти соответствующее определение экспортированного символа в любом из связанных файлов.
Проблемы компиляции и компоновки
Эта ошибка может возникать:
Если в проекте отсутствует ссылка на библиотеку (. LIB) или Object (. OBJ-файл). Чтобы устранить эту проблему, добавьте в проект ссылку на требуемую библиотеку или файл объекта. Дополнительные сведения см. в разделе lib files as input компоновщика.
Если проект содержит ссылку на библиотеку (. LIB) или Object (. OBJ), который, в свою очередь, требуются символы из другой библиотеки. Это может произойти даже в том случае, если не вызываются функции, вызывающие зависимость. Чтобы устранить эту проблему, добавьте в проект ссылку на другую библиотеку. Дополнительные сведения см. в разделе понимание классической модели для связывания: использование символов в качестве пути.
Если при построении отладочной версии приложения вы связываетесь с библиотеками в режиме выпуска. Аналогично, если вы используете параметры /MTD или /MDD или определяете, _DEBUG а затем связываетесь с библиотеками выпусков, то во многих других случаях следует рассчитывать на множество потенциальных неразрешенных внешних значений. Связывание сборки в режиме выпуска с отладочными библиотеками также вызывает аналогичные проблемы. Чтобы устранить эту проблему, убедитесь, что вы используете отладочные библиотеки в отладочных сборках и розничных библиотеках в ваших розничных сборках.
Если код ссылается на символ из одной версии библиотеки, но вы связываете другую версию библиотеки. Как правило, нельзя смешивать объектные файлы или библиотеки, созданные для разных версий компилятора. Библиотеки, поставляемые в одной версии, могут содержать символы, которые не могут быть найдены в библиотеках, включенных в другие версии. Чтобы устранить эту проблему, создайте все объектные файлы и библиотеки с одной и той же версией компилятора, прежде чем связывать их друг с другом. Дополнительные сведения см. в разделе C++ двоичная совместимость 2015-2019.
Если пути к библиотекам устарели. в диалоговом окне средства > параметры > проекты > VC++ каталоги в области выбор файлов библиотеки можно изменить порядок поиска в библиотеке. Папка Компоновщик в диалоговом окне страницы свойств проекта может также содержать неактуальные пути.
при установке нового Windows SDK (возможно, в другое расположение). Необходимо обновить порядок поиска библиотеки, чтобы он указывал на новое расположение. Как правило, путь следует поместить в новый каталог include и lib для пакета SDK перед расположением Visual C++ по умолчанию. Кроме того, проект, содержащий внедренные пути, может по-прежнему указывать на старые пути, которые являются допустимыми, но устарели. Обновите пути для новых функций, добавленных новой версией, которая установлена в другое расположение.
При построении в командной строке и создании собственных переменных среды. Убедитесь, что пути к инструментам, библиотекам и файлам заголовков имеют одинаковую версию. Дополнительные сведения см. в статье Использование набора инструментов MSVC из командной строки.
Проблемы кодирования
Эта ошибка может быть вызвана следующими причинами.
Проект, использующий встраивание функций. Это может произойти при определении функций inline в исходном файле, а не в файле заголовка. Встроенные функции не отображаются за пределами исходного файла, который их определяет. Чтобы устранить эту проблему, определите встроенные функции в заголовках, где они объявляются.
Вызов функции C из программы на языке C++ без использования extern «C» объявления для функции C. Компилятор использует разные внутренние соглашения об именовании символов для кода C и C++. Внутреннее имя символа — это то, что ищет компоновщик при разрешении символов. Чтобы устранить эту проблему, используйте extern «C» обертку для всех объявлений функций C, используемых в коде C++, в результате чего компилятор должен использовать внутреннее соглашение об именовании языка c для этих символов. Параметры компилятора /TP и /TC заставляют компилятор компилировать файлы как C++ или C соответственно, независимо от расширения имени файла. Эти параметры могут привести к тому, что имена внутренних функций отличаются от предполагаемых.
Вызов функции, который использует типы возвращаемых значений и параметров или соглашения о вызовах, которые не соответствуют объектам в определении функции. В объектных файлах C++ декорирование имен кодирует соглашение о вызовах, область класса или пространства имен, а также типы возвращаемых данных и параметров функции. Закодированная строка становится частью окончательного декорированного имени функции. Это имя используется компоновщиком для разрешения или сопоставления вызовов функции из других объектных файлов. Чтобы устранить эту проблему, убедитесь, что в объявлении функции, определении и вызовах используются одни и те же области, типы и соглашения о вызовах.
Код C++, который вызывается при включении прототипа функции в определение класса, но не включает реализацию функции. Чтобы устранить эту проблему, обязательно предоставьте определение для всех членов класса, которые вы вызываете.
Попытка вызвать чисто виртуальную функцию из абстрактного базового класса. Чистая виртуальная функция не имеет реализации базового класса. Чтобы устранить эту проблему, убедитесь, что все вызванные виртуальные функции реализованы.
Попытка использовать переменную, объявленную в функции (Локальная переменная), за пределами области этой функции. Чтобы устранить эту проблему, удалите ссылку на переменную, которая не находится в области действия, или переместите переменную в область более высокого уровня.
При построении окончательной версии проекта ATL создается сообщение о том, что код запуска CRT является обязательным. Чтобы устранить эту проблему, выполните одно из следующих действий.
Удалите _ATL_MIN_CRT из списка определений препроцессора, чтобы разрешить включение кода запуска CRT. Дополнительные сведения см. в разделе Страница свойств General (Project).
Проблемы согласованности
В настоящее время нет стандарта для декорирования имен C++ между поставщиками компиляторов или даже между разными версиями одного и того же компилятора. Объектные файлы, скомпилированные с разными компиляторами, могут не использовать одинаковую схему именования. Связывание их может вызвать ошибку LNK2001.
Смешивание встроенных и невстроенных параметров компиляции в разных модулях может вызвать ошибку LNK2001. Если библиотека C++ создается с включенной функцией встраивания функций (/Ob1 или /Ob2), но соответствующий заголовочный файл, описывающий функции, отключен (без inline ключевого слова), возникает эта ошибка. Чтобы устранить эту проблему, определите функции inline в файле заголовка, который включается в другие исходные файлы.
Эта ошибка может возникать, если опустить параметр LINK/NOENTRY при создании библиотеки DLL только для ресурсов. Чтобы устранить эту проблему, добавьте параметр/NOENTRY в команду Link.
Ошибки экспортированного файла DEF
Эта ошибка возникает, когда экспорт, указанный в DEF-файле, не найден. Это может быть вызвано тем, что экспорт не существует, написан неправильно или использует декорированные имена C++. DEF-файл не имеет декорированных имен. Чтобы устранить эту проблему, удалите ненужные экспорты и используйте extern «C» объявления для экспортированных символов.
Использовать декорированное имя для поиска ошибки
Компилятор и компоновщик C++ используют декорирование имен, также называемое искажением имени. Декорирование имен кодирует дополнительные сведения о типе переменной в ее имени символа. Имя символа для функции кодирует свой возвращаемый тип, типы параметров, область и соглашение о вызовах. Это декорированное имя — это имя символа, которое компоновщик ищет для разрешения внешних символов.
Ошибка связи может возникнуть, если объявление функции или переменной не полностью соответствует определению функции или переменной. Это связано с тем, что все различия становятся частью имени символа для сопоставления. Ошибка может возникать даже в том случае, если один и тот же файл заголовка используется как в вызывающем, так и в коде, определяющем код. Это может произойти, если вы компилируете исходные файлы с помощью различных флагов компилятора. Например, если код компилируется для использования __vectorcall соглашения о вызовах, но вы связываетесь с библиотекой, которая ожидает, что клиенты будут вызывать его с помощью соглашения по умолчанию __cdecl или __fastcall вызова. В этом случае символы не совпадают, поскольку соглашения о вызовах различаются.
Чтобы помочь вам найти причину, в сообщении об ошибке отображаются две версии имени. В нем отображается «понятное имя», имя, используемое в исходном коде, и декорированное имя (в круглых скобках). Вам не нужно знать, как интерпретировать декорированное имя. Вы по-прежнему можете выполнять поиск и сравнивать его с другими декорированными именами. Программы командной строки могут помочь найти и сравнить ожидаемое имя символа и фактическое имя символа:
В некоторых случаях Компоновщик может сообщать только о декорированном имени символа. Для получения недекорированной формы декорированного имени можно использовать программу командной строки UNDNAME.