c# как изменить файл сборки, чтобы разрешить создание DLL для унаследованных классов?

Я создаю проект подключаемого модуля winforms с Visual Studio 2013 Express. Это будет «набор инструментов», куда можно добавить различные «инструменты», скопировав их библиотеки DLL в какую-либо папку, откуда их можно будет просмотреть, загрузить и добавить на новую вкладку. Я решил запустить одну копию VS для фрейма подключаемого модуля и одну для создания подключаемых модулей.

Я нашел этот поток о том, как создавать DLL со студийного проекта и для первого теста все прошло нормально. Хороший рабочий процесс. Но когда я изменил первый инструмент, чтобы он происходил не напрямую из UserControl, а из базового класса пользовательского плагина, который наследуется от UserControl, я получил ошибку компилятора. (тип или пространство имен «База» не найдено...)

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

  • Итак, как следует изменить файл сборки, чтобы разрешить создание DLL для унаследованных классов?
  • Также: есть ли объяснение параметров, таких как «Плагин», «Зависимый Upon» или «Подтип»?
  • Кстати: в реальной версии мне пришлось объединить части частичного класса UserControl, чтобы заставить его работать. (Это было до перехода к базовому классу.) Можно ли изменить файл .csproj, чтобы разрешить частичные классы?

     
        using System;
        //..
        namespace test_cx1
        {
            class Base
            {
            }
        }

    using System; //.. namespace test_cx1 { class Tool1 : Base { } } <ItemGroup> <Compile Include="Base.cs"> <Plugin>true</Plugin> </Compile> <Compile Include="Tool1.cs"> <Plugin>true</Plugin> <!-- does not compile --> </Compile> .. .. <Target Name="BuildPlugins"> <CSC Condition="%(Compile.Plugin) == 'true'" Sources="%(Compile.FullPath)" TargetType="library" OutputAssembly="$(OutputPath)%(Compile.FileName).dll" EmitDebugInformation="true" /> </Target> <Target Name="AfterBuild" DependsOnTargets="BuildPlugins"> </Target>

person TaW    schedule 05.03.2014    source источник
comment
Под запуском копии VS вы имеете в виду, что запускаете два экземпляра Visual Studio с двумя разными решениями для набора инструментов и инструментов?   -  person Sploofy    schedule 05.03.2014
comment
Верно. Я также добавил xcopy после сборки, чтобы скопировать dll в другое решение. Работает как шарм.   -  person TaW    schedule 05.03.2014


Ответы (1)


Проблема в том, что способ установки MSBuild в csproj в вашем решении будет компилировать только один файл .cs, отмеченный True, в один plugin.dll. Таким образом, компиляция завершается ошибкой, потому что ваш базовый класс не скомпилирован, и по этой же причине частичные файлы не будут работать.

Простое решение этой проблемы — пропустить всю истинную фильтрацию в csproj и просто добавить строку CSC в цель BuildPlugins для каждого плагина, который вы хотите скомпилировать, следующим образом:

<CSC Sources="Base.cs;Tool1.cs" TargetType="library" OutputAssembly="$(OutputPath)Tool1.dll" EmitDebugInformation="true" />

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

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

person Sploofy    schedule 05.03.2014
comment
Прохладно! Это как раз правильный компромисс. Что касается проекта по предложению инструмента: я думаю, я сделаю это для инструментов, которые не связаны между собой и не имеют много общего. Однако я столкнулся с двумя новыми проблемами. Один из них о том, что XCOPY копирует старую версию, другой о приведении к базовому классу с ошибкой недопустимого преобразования. см. ссылку и ссылка. - person TaW; 05.03.2014
comment
Хорошо, вот окончательный ответ: приведенное выше предложение близко, но не совсем верно. Если я скомпилирую базовый класс в DLL напрямую, добавив его в исходники, он не будет идентичен любой другой сборке. который пытается сослаться на него. Поэтому я не могу перейти к базе в программе-потребителе. Поэтому ссылку необходимо добавить в строку csc следующим образом: <CSC Sources="PIC_Clock.cs" References="d:\p\c#13\toolbox\pi_base\pi_base\bin\debug\pi_base.dll" TargetType="library" OutputAssembly="$(OutputPath)PIC_Clock.dll" EmitDebugInformation="true" /> - person TaW; 07.03.2014
comment
Добавить и добавить к окончательному ответу: по непостижимым причинам файл сборки также не учитывает другие зависимости, особенно соединение частичных классов, скажем, пользовательских элементов управления; поэтому я должен добавить «usercontrol.designer.cs» к источникам. Вздох.. (Вышеупомянутое сработало, потому что я вырезал Designer.cd и вставил патч в файл cs. (аааа..)) - person TaW; 13.03.2014
comment
Из-за всех этих проблем я рекомендовал вам вместо этого использовать отдельные проекты. :) - person Sploofy; 13.03.2014
comment
Ага. Хорошо. У меня уже готово около дюжины мелких инструментов, и их число будет расти. Можно хранить некоторые в общих библиотеках, но для более крупных я использую отдельные библиотеки. Менеджер библиотек в тулбоксе на месте и работает нормально. Но мне очень нужны все варианты. Кстати: мне до сих пор не удалось включить файл ресурсов в сборку. Должен быть способ.. - person TaW; 14.03.2014