Можно ли упаковать в одну DLL код, написанный и на VB.NET, и на C# (разнородный код находится в разных исходниках)? Языки разные потому, что у кода разные источники. Если можно, то мне это изрядно упростило бы процедуру установки и доставки. Если нет, то оно и так работает , но я буду очень благодарен за ответ.
Заранее прошу прощения за странную просьбу. Я по жизни такой.
Здравствуйте, NPC, Вы писали:
NPC>Всем привет,
NPC>Можно ли упаковать в одну DLL код, написанный и на VB.NET, и на C# (разнородный код находится в разных исходниках)? Языки разные потому, что у кода разные источники. Если можно, то мне это изрядно упростило бы процедуру установки и доставки. Если нет, то оно и так работает , но я буду очень благодарен за ответ.
Вопрос на самом деле звучит иначе. Тебе надо слить две сборки в одну. А этот вопрос на форуме поднимался неоднократно — воспользуйся поиском.
Здравствуйте, NPC, Вы писали:
NPC>Можно ли упаковать в одну DLL код, написанный и на VB.NET, и на C# (разнородный код находится в разных исходниках)? Языки разные потому, что у кода разные источники. Если можно, то мне это изрядно упростило бы процедуру установки и доставки. Если нет, то оно и так работает , но я буду очень благодарен за ответ.
Можно. Но не средствами Visual Studio.
Два варианта:
Или скомпилируй сначала разные исходники в модули, с коммандной строчки. Соответственно csc.exe /t:module ... и vbc.exe /t:module .... Получившиеся .nemodule файлы затем свяжи с помощью al.exe /t:library 1.netmodule 2.netmodule.
Или скомпилируй один модуль (например, vb) vbc.exe /t:module ... и затем привяжи его к остальному с помощью компилятора C#: csc /t:library ... /addmodule:1.netmodule. Или наоборот, C#-ый модуль привязывай к "VB-шной" сборке.
Здравствуйте, Aggtaa, Вы писали:
A>Два варианта: A>Или скомпилируй сначала разные исходники в модули, с коммандной строчки. Соответственно csc.exe /t:module ... и vbc.exe /t:module .... Получившиеся .nemodule файлы затем свяжи с помощью al.exe /t:library 1.netmodule 2.netmodule.
A>Или скомпилируй один модуль (например, vb) vbc.exe /t:module ... и затем привяжи его к остальному с помощью компилятора C#: csc /t:library ... /addmodule:1.netmodule. Или наоборот, C#-ый модуль привязывай к "VB-шной" сборке.
Только описанные тобой варианты никак не упростят процедуру установки и доставки.
Здравствуйте, Aggtaa, Вы писали:
A>Или скомпилируй один модуль (например, vb) vbc.exe /t:module ... и затем привяжи его к остальному с помощью компилятора C#: csc /t:library ... /addmodule:1.netmodule. Или наоборот, C#-ый модуль привязывай к "VB-шной" сборке.
Спасибо за комментарии — мне уже надо убегать, но я попытаюсь воспользоваться именно вторым из предложенных методов — VB.NET-овская сборка у меня будет меняться очень редко, поэтому попытаюсь с помощью параметров компилятора (надеюсь, что их можно в проекте задать) линковать ее к C#-модулю.
Здравствуйте, Lloyd, Вы писали:
A>>Два варианта: A>>Или скомпилируй сначала разные исходники в модули, с коммандной строчки. Соответственно csc.exe /t:module ... и vbc.exe /t:module .... Получившиеся .nemodule файлы затем свяжи с помощью al.exe /t:library 1.netmodule 2.netmodule.
A>>Или скомпилируй один модуль (например, vb) vbc.exe /t:module ... и затем привяжи его к остальному с помощью компилятора C#: csc /t:library ... /addmodule:1.netmodule. Или наоборот, C#-ый модуль привязывай к "VB-шной" сборке.
L>Только описанные тобой варианты никак не упростят процедуру установки и доставки.
Признаться, я не первый такое предлагаю. До меня это успел сделать как минимум Рихтер.
Но уж если ты об этом заговорил, давай разберемся: а в чем же проблемы этого способа, возникающие при установке и доставке. Я не совсем понял, что именно ты имеешь в виду под выделенными словами, буду догадываться.
Сборка без строгого имени устанавливается в каталог с приложением путем копирования файлов. Коль скоро это сборка .dll, то устанавливается, как минимум, еще один .exe файл. То есть копировать в любом случае больше одного файла. 2 или 3 — разницы нет. Проблемы тоже нет.
Сборка со строгим именем устанавливается в GAC, если я ничего не путаю. gacutil /i или /ir зарегистрирует как .dll, так и .netmodule файлы. /u и /ur аналогично их разрегистрирует. Проблемы нет.
Сборка со строгим именем подписывает токеном ключа только файл с метаданными, .dll — это да. Однако все ссылки на внешние модули и на ресурсы хранятся с соответсвующими хэшами закодированных этим же ключом контрольных сумм файлов и путанница здесь возникнуть не может. Проблемы нет.
Что я еще упустил? В GAC .netmodule файлы хранятся в собственных папках и перепутаться не могут. Тоже вроде как нет проблемы.
Зато есть определенные плюсы. В частности, такой: над исходниками работают чаще всего разные люди, причем независимо друг от друга. Используя отдельные файлы для разных исходников можно получить некоторую дополнительную свободу действий. У меня, например, сейчас сидит человек, пишущий отдельный модуль в APL, он очень слабо пересекается в работе с состальными, он вообще финансист по образованию. И выделять отдельную сборку под мат.логику я не хочу. Поэтому в данном случае я посоветовал то, как я сам поступил. Сам проверил. И грабель не нашел.
Так что я со своим небогатым опытом разработки под .Net не вижу, где же тут проблемы. Может быть, плохо смотрю?
Здравствуйте, Aggtaa, Вы писали:
L>>Только описанные тобой варианты никак не упростят процедуру установки и доставки. A>Признаться, я не первый такое предлагаю. До меня это успел сделать как минимум Рихтер.
Не кипятись. Из сообщения было ясно, что человек хочет хочет уменьшить кол-во файлов. Ему так удобнее и не наше дело его убеждать, что 3 — это ничуть не хуже чем 2. Твой вариант действий не уменьшал кол-во файлов и потому не являлся решением его проблемы.
Здравствуйте, Lloyd, Вы писали:
L>>>Только описанные тобой варианты никак не упростят процедуру установки и доставки. A>>Признаться, я не первый такое предлагаю. До меня это успел сделать как минимум Рихтер. L>Не кипятись.
А похоже? Плохо.
L>Из сообщения было ясно, что человек хочет хочет уменьшить кол-во файлов. Ему так удобнее и не наше дело его убеждать, что 3 — это ничуть не хуже чем 2. Твой вариант действий не уменьшал кол-во файлов и потому не являлся решением его проблемы.
Мне показалось, что нужно было упростить процедуру развертывания. Думаю, развертывание многомодульной сборки гораздо проще, чем нескольких сборок, и при этом не сложнее развертывания одномодульной, к тому же не обладает недостатками "сливания" сборок в одну. Ну, ИМХО разумеется, но ты же не ответил на большую часть моего письма, значит согласен.
Здравствуйте, Aggtaa, Вы писали:
L>>Из сообщения было ясно, что человек хочет хочет уменьшить кол-во файлов. Ему так удобнее и не наше дело его убеждать, что 3 — это ничуть не хуже чем 2. Твой вариант действий не уменьшал кол-во файлов и потому не являлся решением его проблемы. A>Мне показалось, что нужно было упростить процедуру развертывания. Думаю, развертывание многомодульной сборки гораздо проще, чем нескольких сборок, и при этом не сложнее развертывания одномодульной,
Развертывание многомодульной сборки сложнее хотя бы потому, что нужно поставить не 1, а как минимум 2 файла.
A>к тому же не обладает недостатками "сливания" сборок в одну.
а какие недостатки развертывания у слитой в одну сборки?
A>Ну, ИМХО разумеется, но ты же не ответил на большую часть моего письма, значит согласен.
Спорить с пересказом Рихтера? Ну уж нет, я же не Vlad2D.
Здравствуйте, Lloyd, Вы писали:
L>Развертывание многомодульной сборки сложнее хотя бы потому, что нужно поставить не 1, а как минимум 2 файла.
Это еще почему? "Поставить" надо именно один файл. Ты же не сможешь инсталлировать сборки, не инсталлировав все ее модули. Да и с дистрибутиве не так-то просто пропустить файлы.
A>>к тому же не обладает недостатками "сливания" сборок в одну. L>а какие недостатки развертывания у слитой в одну сборки?
Развертывания — никаких.
L>Спорить с пересказом Рихтера? Ну уж нет, я же не Vlad2D.
Ну уж. Рихтер нигде не расписывал сравнительные преимущества многомодульных сборок по сравнению с несколькими сборками. Ну, или я не помню.
Здравствуйте, Aggtaa, Вы писали:
A>Это еще почему? "Поставить" надо именно один файл. Ты же не сможешь инсталлировать сборки, не инсталлировав все ее модули. Да и с дистрибутиве не так-то просто пропустить файлы.
В моем понимании поставка — это доставка + инсталляция, а доставлять придется таки несколько файлов.
L>>Спорить с пересказом Рихтера? Ну уж нет, я же не Vlad2D. A>Ну уж. Рихтер нигде не расписывал сравнительные преимущества многомодульных сборок по сравнению с несколькими сборками. Ну, или я не помню.
Здравствуйте, NPC, Вы писали:
NPC>Можно ли упаковать в одну DLL код, написанный и на VB.NET, и на C# (разнородный код находится в разных исходниках)? Языки разные потому, что у кода разные источники. Если можно, то мне это изрядно упростило бы процедуру установки и доставки. Если нет, то оно и так работает , но я буду очень благодарен за ответ.
1. Можно все сборки слить в одну (на www.gotdotnet.com есть утилита ILLINK)
2. Записать все зависимые сборки в .CAB файл (статья в MSDN Deploying a Runtime Application Using .cab Files)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
, но я буду очень благодарен за ответ.
