Apsolutno.

Bez obzira koji .Net jezik se koristi, rezultujući asembli se može koristiti u bilo kom sledećem projektu (koji god jezik da se koristi).

To je jedna od glavnih prednosti .Net Frameworka.

Tako je i zamisljen.
Mada u praksi to ne izgleda tako.
Ja sam imao problema prilikom koriscenja reference na dll pisan u C#, inace pisem u VB-u i ne vidim razlog zasto bi se preorjentisao na C#, jer imaju istu funkcionalnost u .NET-u.

Zbog specifičnosti VB.Net-a oko prenosa parametara i tipova struktura koje poznaje (ovo je problem VB.NET-a kao jezika, ne samog .Net frameworka) kada pišete C# asembli koji će biti korišćen od strane VB.NET-a, o tome se mora voditi računa.

Što se izbora jezika tiče, to je manje-više stvar ukusa - sve što uradite u jednom, može i u drugom (sem minornih stvari, kao što je nedostatak podrške za "unsafe" kod u VB.NET-u)

C# je napravljen specijalno kao "glavni" jezik za .Net framework i kao odlična platforma za prelazak C++ i Java programera; on je i "pravi" Object Oriented jezik, tj. pisan je kao takav, dok je OO kod VB-a nastao "nasilnim" načinom.

VB.NET je kao i svi VB-ovi basic u koji je silom ugurano sve što treba za .Net programiranje; po mojoj ličnoj oceni, a i oceni VB programera firme u kojoj radim, C# je bolji za migraciju na .Net nego učiti rogobatne sintaksne konstrukcije u VB.NET-u. Glavna prednost, a to je laka migracija sa postojećih VB 6.0 aplikacija na VB.NET prosto ne postoji (ovo je probano na više od 20 veoma velikih aplikacija).

So, ako ste srećni sa VB-om, ne želite ništa više / drugačije, koristite VB.NET.

Ako hoćete moderan OO jezik koji je pisan zajedno sa .Net frameworkom, preporučujem C# (moj lični favorit).

Opet, ovo nije da bi se počeo flame war - sve ovo je moje lično mišljenje i ništa više.

<sub>[Shadowed: obrisan nepotreban citat.]

[Ovu poruku je menjao Shadowed dana 19.06.2006. u 04:19 GMT+1]</sub>

Malo sam sada zbunjen.

Znam ja da C# ima prednosti nad VB.Net-om ali nije mi bas najjasnije da li mogu
VB.Net dll-ove da iskoristim u C# projektu.

Mozes.

Vidim da su ti vec odgovorili da moze, ali niko ne rece kako.

postoje dva nacina:

1. Ukljuci VB.NET projekat kao deo istog solution-a gde ti je c# projekat. Iz C# uradi Add Reference i ziaberi VB.NET projekat iz "Project" tab-a. To ce osigurati da ako napravis izmene u VB.NET projektu C# dobije najsveziju verziju dll-a i omogucavati da debagujes vb,net kod kad se poziva iz C# aplikacije.

2. Ako hoces samo da koristis DLL bez sorsa, postavi ga negde na HD, i idi u Add Reference, u tab "Browse" (ako je vs2005) ili klikni na dugme "Browse" (ako je vs 2003) i "otvori" taj DLL, to ce ga dodati u listi referenci.

...i zasto :-)

Kada kompajliras VB.NET ili C# u stvari ih prevodis u Intermediate Language a tek onda po izvrsavanju (sad u .NET 2.0 je drugacije) se dobija pravi kompajlirani kod za izvrsavanje.

Pozdrav

Kako je drugacije? Mozda sam nesot propustio, ali MSIL/JIT kompajliranje je i dalje mehanizam po kojem .NET 2.0 radi...

Pa nije sve bas tako, da bi se koristio asembli napisan u jednom programskom jeziku u nekom drugom jeziku, npr asembli u vb.net da koristis u C#. Trebao bi, ili makar bilo bi pozelljno da asembli oznacis atributom

sto normalno znaci da je csl kompatibilan, tj da su svi njegovi tipovi u clanovima koji su vidljivi izvan klase cls kompatibilni(clanovi koji nisu vidljivi izvan klase nisu ni bitni posto im nemozes pristupiti iz van klase tj iz asemblia u C#), normalno mozes ako hoceh da izlozis i metode koje nisu kompatibilne ali onda moras da ih oznacis sa

Ovaj atribut ako se koristi tip koji nije cls kom. prilikom kompajliranja javlja error kao npr

Normalno ovo nemoras da koristis ali neces biti siguran da je tvoj asembli cls kompatibilan.

I da i ne
CLSCompliant atribut je tu iz generalno tog razloga, ali u ovom slucaju to nema veze. Radi se u glavnom o nekoliko value types koji imaju specijalno procesiranje u MS kompajlerima a koji nisu obavezni niti predvidjeni CLS standardom i ovaj atribut je tu da te dovede u red kako bi assembli radio i kroz 3rd party designere/kompajlere van MS sveta. VB.NET i C# su Microsoft kompajleri i oba podrzavaju to specijalno procesiranje i nema preke potrebe da se kod kiti ovim atributom (btw, kompajler izbacuje warning, ne gresku)

A ipak bih najtoplije preporučio korišćenje ovog atributa ako pišete komponente koje bi trebalo da se koriste i iz drugih jezika. A povrh toga i FxCop :)

A moze i tako :)

Ja i dalje nisam rad da to preporucujem kao narodni lek. Da se razumemo, ne zalazem se ja ovde za anarhiju u kodiranju, ali se zalazem za to da svaki tim sam odabere kojim ce putem ici. Za projekte koji su kompletno inhouse i za koje se zna gde ce i kako raditi, dodatni trosak za compliance-u sa standardom i nije uvek pozeljan.


PS: I da, FxCop je grozomoran. :) Mislim da je compliance sa ovim alatom definitivan overkill :) Da ne pominjem da ni .NET fabricki asembliji ne prolaze kroz FxCop (System.Data ima 13346 issues :D)

Naravno, zavisi od scenarija upotrebe. Ako je ceo projekat rađen u C#-u ne vidim razlog da se izbegava uint u interfejsu. Ako praviš komponente za širu upotrebu, ili možda čak prodaju, CLSCompliant je vrlo preporučljiv.

A FxCop je lek za pacere :) Kad sam radio u timu koji je više koristio .NET, propustio sam kod nekih lokalnih "gurua" i mnogo ih iznervirao, hehehe.

Haha, moram da priznam da je i mene prvobitno uhvatio "nespremnog" . Dodatna nezgodacija je sto analiza ume da potraje i po minut pa si izlozen i dodatnom stresu da gledas kako issue brojac ide ne kroz desetine, nego kroz hiljade otkrivenih issue-a i efekat je tako obeshrabrujuci da taman imas vremena da prodjes kroz svih pet psiholoskih faza: negiranje, bes, racionalizacija, depresija i na kraju prihvatanje situacije da ti u stvari nemas pojma sa programiranjem

Sad ga redovno osvezavam iz slicnih razloga kao i ti. Surovo ali veoma zabavno

Pozdrav svima.

Imam problem i trazim praktican odgovor.

Koristim c# i VS.NET 2003. Problem se sastoji u sledecem:

Imam projekat A ( windows aplikacija) koji je glavni i radi odlično. Za taj projekat su mi
potrebne slike koje sam odlucio da stavim u resursni dll. To sam uradio tako sto sam sve slike stavio u Slike.resX fajl. Napravio sam novi prazan projekat B i sa Project\Add Existing Item dodao mu Slike.resX. U properties projekta podesio sam da Output Type bude Class Library. Kompajlirao u Release konfiguraciji i dobio B.dll fajl.

Jedan od obrazaca projekta A treba da koristi slike iz B.dll ali kako?

Znam da postoji mogucnost da Slike.resX ubacim u A projekat direktno ali su slike prevelike.

Tesko, trivijalno pitanje ili se jednostavno nema vremena ?

Uzmi Reflector ( http://www.aisto.com/roeder/dotnet/ ) i proveri rezultujući DLL, odnosno da li su resursi iz novodobijenog asemblija uopšte dostupni ostalima (da li imaju public atribut).

Pa prvo moras da stavis referencu (Add reference) na projekat B.
U kodu moras da uvezes taj projekat Import B....

a nakon toga u okviru projekta A napravis instancu te klase( ili sta god da je ) i pozoves slike.
Nadam se da sam ti pomogao.

Ako nisam posalji mi kod pa cu da ti vrati ispravljen ili napisi malo detaljnije opisi problem.