Я много слышал о том, что все, написанное для .NET компилится в одинаковый байт-код, поэтому обеспечивается совместимость между различными языками программирования, но вот как с этим работать мало где написано. Прошу тех, кто знает написать подробнее, как например использовать в C# код, написанный на VB.NET.

В проект на шарпе можно добавить reference на сборку, скомпилированную из исходников на VB.NET (и наоборот) - вот и всё, если в двух словах.

Потом обращайся к этой сборке как будто она была написана на C#.

Для ясности - в одном проекте использовать и C#, и VB нельзя. Многоязычность работает только в пределах решений (solutions)

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

Т.е. как я понял, нужно подключать сборки .Net'овские и все будет ок. А там никаких хедеров не недо, типа как в C++?

Добавлено @ 09:07 
А сборка, как я понимаю, это .Net'овская dll'шка, правильно?

Нет... Просто стандартный Using (для C#)



Да

Да, а потом используй что-то типа Using, как в C#. Здесь у каждого .Net-языка слово Using может варьироваться.

Не только, это ещё может быть ".Net'овская exe'шка" (на сколько я знаю). Главное, ты получаешь доступ ко всем классам сборки.

Т.е. можно и из exe-шки классы грузить?

Добавлено @ 17:36 
Я восхищаюсь этим творением Микрософта (имею ввиду .Net), но если там еще и из ехе-шек можно код загружать, то это просто супер.  

Просто не проверял, но это должно быть доступно. Там, наверное, только метод main нельзя будет запускать.

Cr@$h, вывеси кусок кода, как это можно сделать или же опиши последовательность действий в Visual Studio

Всё же уже было сказано:

• По проекту правой, Add Reference... Указываешь сборку.
• Пишешь using пространство_имён;

Используешь классы, как обычно. Можно через пространство имён: пространство_имён.класс.

Стоп.

Действия такие же, как и при использовании DLL-сборки.

 
Да, exe-шник --- та же длл-ка, только с точкой входа-запуска

Которую, интересно, можно ли будет запускать из другой, основной, сборки?

Указываю ему .Net exe-шку, сделанную в той же VisualStudio, а он ругается, мол: "A reference ... coudn't be added. This is not a valid assembly or COM component only assemblies with extention 'dll' and COM components can be refenenced. Please make sure that the file is accessible, and it is a valid assembly or COM component." Ну так, какие соображения по этому поводу?

Вообще можно что угодно запустить из сборки 

А по сути --- не понял вопроса   
Зачем что-то запускать из запущенной сборки (кроме совершенно независимого приложения, см. выше)? Просто можно пользоваться кодом сборки как своим.

Добавлено @ 16:24 

Все работает   Только что проверял

Добавлено @ 16:25 
И код выполняется.
Подключил к C# приложение на ВБ   

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




using открывает пространство имён, а не даёт ссылку на сборку.



Начиная с версии 2.0.



Вероятно, да.

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

Вот, например

Похоже, так и есть.


Модуль? Это dll'ка будет что ли?

Если к нему есть доступ, то да. Но по умолчанию она объявлена как private (как и весь класс Program)

?

Нет, это будет модуль с расширением .netmodule. Потом его можно прилинковать при компиляции к другой сборке.

Добавлено @ 18:51 


Я не догоняю, Main() ведь всегда public static...

Вот и я про то. Можно ли вызвать во втром ДотНете из исполняемой сборки метод main?

Создайте новый проект и загляните в класс Program? в котором и находиться Main. Так вот ни для main ни для его класса Program не стоит модификатора доступа. Следовательно оба они Private.


Более того, если сборку подключить к другой, то доступа к main не будет, но если сделать их Public, то достучаться до них легко: WindowsApplication1.Program.Main

Я ответил выше 

А что будет? Второй процесс, второй поток, или всё в том же потоке будет запускаться, как обычный метод?

Ах вон оно что. Значит у меня просто проблемы со средствами: у меня стоит Visual Studio 2003, значит поставлю 2005-й и все будет ок

Main запустится в том же потоке, но так как там форма, то она уже будет крутиться в отдельном потоке

Добавлено @ 21:27 

да так  Ведь при подключении сборки мы просто имеем доступ к ее коду и ресурсам и все  А main это просто метод, только с него все начинается 

  

Да вот и не такой уж и простой...

Класс Program - Internal, a не Private:)

Ага, только это для классов, объявленных в namespace; а вот для nested-классов уже работают все пять модификаторов: public, protected, protected internal, private и internal 

Добавлено @ 23:23 

В C# без модификатора => internal? Давно я серьезно не кодил на шарпе, все барсик, да барсик     

ИМХО, он такой же метод как и все. И если бы разработчики сняли бы ограничения (только main может быть стартовым методом), то можно было бы начинать прогу с любого метода. 
Вся работа по созданию домена, открытия потока, ... , ИМХО, ведется фрэймворком, а уже потом, когда все необходимое готово, вызывается main, как стартовая точка приложения.
Точно так же в майн можно, ИМХО, прописать какую-нить, все равно какую, логику. Правда чаще всего main используется для старта главной формы.

P.S. Товарищ Cr@$h, объясните пожалуйста почему вы смеетесь      

Добавлено @ 08:00 

Program -- не nested класс, он лежит сразу в нэймспейсе (рефлектор вам в руки)

P.S. Хоть и оба (и класс и метод без модификаторов) класс имеет достум internal, а вот метод main -- private   

Не верите мне, поверьте рефлектору:

ivashkanet, да мы тебе верим , у нас тут пошли отвлечённые разговоры на общую тему...

В каком месте? Я не заметил  

Добавлено @ 11:11 

Аааа, ты говоришь о том, что только невложенные классы без модификаторов имеют доступ internal, а вложенные --- private? 

да

здравствуйте, мне нужно в солюшене C# использовать класс (наследоватать, создавать объекты и т.п.)   из другого проекта, который на C++
 оба проекта скомпиллированы и у них в папке Debug есть exe-шка
вот я жму правой кнопкой на проект в C#, Add Reference, Browse и выбираю exe-шку с++ проекта 
ну и выскакивает ошибка как у когото кто уже об этом написал.

"A reference ... coudn't be added. This is not a valid assembly or COM component only assemblies with extention 'dll' and COM components can be refenenced. Please make sure that the file is accessible, and it is a valid assembly or COM component.

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

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

а ведь можно добавить в солюшен C# проект из С++..?..как тогда всё сделать чтоб юзать с++-совские классы?.. чем же это отличается от "Add Reference"

Это сообщение отредактировал(а) Kvazilol - 7.12.2006, 23:03

M mr.DUDA

Kvazilol, одна тема - один вопрос, пожалуйста. Здесь совсем другая проблема: С++ длл нельзя подключить к C#-овскому проекту.

mr.DUDA, даже, если имеется в виду С++.NET? 

дадада конечно на .NET (2005). 
ну как это может быть что сборка VB конектится к C# а C++ не конектится!?       не-ве-рю    

Если сборка на Managed C++, то должны добавляться референсы без проблем.

так, в одном солюшене win32 проект и проект на C# (консольные)
( просто друг делает сокеты на win32 а я интерфейс на C#..  )
вот я создал класс в его проекте(класс называется Serega, а проект называется w32) , затем делаю build нашим проектам, затем добавляю моему (C#) проекту референс на проект друга.. ура! он добавился)))
а вот как теперь в C# создать экземпляр этого класса?
надо в мейне у C#  написать
w32.Serega mySerega = new w32.Serega(); // это без using Serega
???
но компиллятор ваще не видит неймспейса w32, тоесть когда пишу using w32 то происходит ошибка 

Error    1    The type or namespace name 'w32' could not be found (are you missing a using directive or an assembly reference?)    C:\Projects\с#\sharp\sharp\Program.cs    4    7    sharp

 вот что я не так делаю?

Это сообщение отредактировал(а) Kvazilol - 8.12.2006, 13:15

Win32 С++ проект и .NET C++ проект - это разные вещи. Пусть для начала твой товарищ поставит в свойствах проекта "Use common language runtime = true" и попробует скомпилировать.

ну он делает проект в той же самой Microsoft Visual Studio 2005 и у него он соответственно .NET но тип проекта Win32 Console Application
вот мне сегодня продвинутый человек показывал как соединить проекты, у него вначале чото не получилось но потом они соединились но он так быстров всё нажимал что я не успел всё запомнить( 
никаких Use common language runtime = true он не делал, всё запустилось без этого..(
а где в свойствах проекта найти Use common language runtime  ???
млин всё наверное делается просто а я чтото не сделал и пропустил..

Это сообщение отредактировал(а) Kvazilol - 8.12.2006, 14:25

а должен быть Console Application(.NET).
Именно об этом тебе говорил mr.DUDA.

Где логика   

уууй блииин я уже со всем запутался.
ну вот такой проект у моего товарища:
http://slil.ru/23537824
этож в среде .NET сделано! знчит и  проект .NET!? ни-чо не понимаю.....

Нет. То, что IDE называется VisualStudio.NET ещё не означает, что компилироваться всё будет исключительно в .NET структуры...(на заборе слово из трех написано, а там - дрова лежат )
Для того, чтоб получить управляемый код, надо создавать проект, нацеленный на использование управляемого кода.

ЭТО СДЕЛАНО В VISUAL STUDIO. КОТОРАЯ МОЖЕТ ДЕЛАТЬ КАК .NET ТАК И ПОД WIN32 (Т.Е. NAITIVE).

ЭТОТ ПРОЕКТ СДЕЛАН ПОД WIN32

ой а как же тогда из   win32 сделать  win32.NET чтобы он референсился к c# ???
тоесть получается что если создать проект на с++ то он будет Nativ а не managed!? ну и ну!
а,  Use common language runtime = true чо делает?.. и самое главное, где его найти в свойства проекта ? а кстатии какого проекта? который на с++, да?

я нашел Common language runtime support в настройках проекта win32, какое значение нужно ему сопоставить???

Это сообщение отредактировал(а) Kvazilol - 8.12.2006, 15:45

Может, лучше вашего коллегу пригласите, пусть он всё сам сделает.

да коллега ваще не разбирается в .NET а я про .NET в книжке читал) вот такие мы hi expirience developers   
а может лучше ктонибудь кто знает напишет как прально объединить win32 и c#..    или скажет что это 100% невозможно..

Это сообщение отредактировал(а) Kvazilol - 9.12.2006, 01:11

Проще всего сделать win32 dll и подключать её через [DllImport]. Примеры уже были в разных темах.

как мне найти такие примеры? дайте мне ссылки, пажалста

Ну вот, к примеру, код использующий "некую" user32.dll, и в частности функцию SendMessage:



P.S. найти тучу примеров можно тыкнув на кнопку "Поиск" вверху страницы, выбрав в списке ".NET (Подкатегория") и набрав в поле "Ключевое поле для поиска" строку DllImport

А кто-то применял на практике смешение языков в своем приложении? С реальной пользой?

QryStaL, неоднократно.

Вот пример из последних : нужно разработать некое подобие самопальной СУБД для хранения двоичных данных в таких масштабах, какие M$ Access не снились. Причём это хранилище ориентировано на двоичные потоки с последовательностями повторяющихся значений-пустот, который нехитрым образом маркируются. Так вот, сам формат, адаптеры из других форматов и низкоуровневые функции обработки мне удобнее всего накрутить на платформонезависимом C/C++, основанный на нём высокоуровневый интерфейс - на CLI.C++, ну а сервис для удалённой работы - уже на C#. Нахожу в этом две пользы : а) эффективность разработки (для меня) б) эффективность (быстрота работы) кода в чувствительных моментах.

Смешение часто можно увидеть у приложение<->COM, клиент<->сервер-ов или у ядро<->интерфейс-ов. Скажем, Civilization IV частично написана на Python-e  Или же Regex - хоть встраиваемый в .NET или в Perl, но тоже язык. А у ремесленников в веб-дизайне - вообще одно сплошное смешение.

Это сообщение отредактировал(а) marcusmae - 13.6.2008, 01:10