Distribution af filer i exe, dll og assemblies..

Jeg ved ikke om det er .NETs måde at gøre det på at samle det hele i een og samme exe.
Det er vel en fordel at bruge 4 dll'er at du kan udskifte tilgengæld betyder det (lidt) længere opstarts tid da dll'erne skal loades.
Det passer fint med Assembly begrebet fordi din application er et Assembly og et Assembly kan bestå af en eller flere dll eller exe filer.
Opslitningen laves ved at du compilerer det der skal være dll som libraries og under compilationen af exe'en refererer du dll'erne.

Ah, hvad mener du egentligt med at Server og klient lag? De skal vel ikke lige i samme Assembly?

Man kan vel godt tolke en del af noget software, som en klient der kommunikerer med kernen (serveren) af softwaren, som leverer data ?

Du laver 5 separate filer der hver indeholder sit eget lag og definerer hvert sit sub namespace, f.eks. MinApp.Lag1, MinApp.Lag2, etc. De 4 nederste lag (som jeg går ud fra mangler entry points) kompilerer du med /target:library. I sourcen i det 5. lag bruger du using MinApp.Lag1, using MinApp.Lag2, etc. Det 5. lag (det der har et entry point) kompilerer du med /target:winexe /r:lag1.dll /r:lag2.dll /r:lag3.dll /r:lag4.dll og så sørger du naturligvis for at distribuere alle 5 filer samlet!

Bemærk, Namespaces har ikke noget med filer at gøre.

som odegaard så rigtigt siger det, så er der tale om server-/klient-lag, som begge ligger på samme maskine. de er lavet så man senere kan skifte dem ud, og derved have en LAN-baseret tcpip applikationion, eller en WAN-baserest http-appikation.

> z42cool: Hvert lag består af 2 filer. et interface og den implementerede klasse. Eks. iSQLConnection.vb og MSSQLConnection, som er interface og implementeringen til MS SQL SERVER. dette lag skal i en dll....

men du nævner sub-namespaces... hvordan laver jeg disse ??

Tj.

har set eksempler på at namespaces erklæres i koden ??

som :
NameSpace 'tekst'

End Namespace

vil det sige at en vb-fil godt kan indrholde flere namespaces ??

Damm det her er besværligt !

Jeg har altså 5 lag, hvert lag med 2 til flere klasser (og .vb-filer).

Jeg skal nu have kompileret 5 dll'er (4 som lag og 1 som samling af mine andre klasser) og 1 exe.

nedeste dll skal indeholde 2 *.vb filer...
Men hvordan fanden får jeg kompileret dem sammen.

i min kommandoPrompt skriver jeg:
"c:\xxx\vbc /target:library iSQLConnection.vb"

men den tager kun en fil som argument. Derfor fejler den når den ikke kan finde den klasse der implementerer den. Desuden fejler den fordi den ikke kan fine system.data (framework-namespace jeg benytter).

Hvad gør jeg galt ??

Tj.

hvad fanden gør jeg galt ?
hvorfor kan den ikke finde system.data og de andre jeg importerer...

Det virker jo fint når VS selv kompilerer det....

E:\Database>vbc /t:library /out:sqlcon.dll ISQLConne
ction.vb SqlServerConnection.vb
Microsoft (R) Visual Basic .NET Compiler version 7.00.9466
for Microsoft (R) .NET Framework version 1.00.3705.209
Copyright (C) Microsoft Corporation 1987-2001. All rights reserved.

E:\Vss Projects\Tecnical Layer\Database\ISQLConnection.vb(4) : error BC30466: Na
mespace or type 'Data' for the Imports 'System.Data' cannot be found.

Imports System.Data
        ~~~~~~~~~~~
E:\Vss Projects\Tecnical Layer\Database\ISQLConnection.vb(5) : error BC30466: Na
mespace or type 'SqlClient' for the Imports 'System.Data.SqlClient' cannot be fo
und.

Imports System.Data.SqlClient
        ~~~~~~~~~~~~~~~~~~~~~
E:\Vss Projects\Tecnical Layer\Database\ISQLConnection.vb(19) : error BC30002: T
ype 'SqlDataReader' is not defined.

        Function qSelect(ByVal s As String) As SqlDataReader
 

og så videre......... Dammm

Du kan sagtens give compileren mere end en source fil,

"c:\xxx\vbc /target:library iSQLConnection.vb source_file2.vb"

ja det har jeg fundet ud af, men det er dog ikke problemet nu!
Problemet er at den mangler alle de inbyggede namespaces som jeg bruger i mit program... eks:

System.data
System.net
osv....... (se mit tidligere indlæg..)

Hvad gør jeg galt ?

Asso hvis du refererer et assembly der indeholder et namespace kan du enten skrive Imports 'navn' eller fx.
System.Console.WriteLine.
Men du skal huske at refererer den dll fx. system.net ligger i, under compileringen. Til csc compileren skriver man /r: mon ikke oxo det kan bruges her

Det hænger da ikke rigtigt sammen.
Hvordan skulle jeg nogensinde kunne gætte i hvilken dll System.net ligger i (den ligger ikke som selvstændig fil).

Desuden kan man jo have programmer der importerer mange andre namespaces...

Har prøvet /r: - men aner ikke hvad jeg skal linke til...

ja det er ikke nemt. Men det er sådan det virker. Hvordan finder man så ud af i hvilken dll et namespace ligger? Tjah msdn, ellers prøv ildasm på dll'erne. (De ligger sammen med .NET installationen) Eller den sidste udvej er at bruge anakrino som laver (C#) dekompilering af assemblies

men stadigvæk.. hvorfor?

jeg importerer dem jo i starten af min applikation... De må da ligge i .NET frameworket at abstrahere fra deres fysiske placering når først de er registrret som assembly....

Nej. namespace og assemblies er forskellige ting. Et namespace er en compilerteknisk foranstaltning. Det eneste et namespace gør er, at inddele variabel navne i grupper. Dermed kan man mere frit selv finde på variabel navne i store projekter.

korrekt!

men det kan da ikke være rigtigt at jeg skal sidde og kigge alle Dll'er igennem for at finde System.Net -> det tror jeg simpelthen ikke på passer..

Desuden kan jeg ikke finde det omtalt nogen steder på nettet...

Se evt. her :: http://www.dotnetextreme.com/code/GETComputernameandIP.asp

Der omtales system.net.dll... jeg har dog ikke denne fil ?

én ting er system.net... men den kan fanme heller ikke finde ud af at kompile når man bruger en ArrayList....

Se, ArrayList er jo en del System.Collections

det kan simpelthen ikke være sandt!
men hvis jeg skal tro dig, må du hjælpe med at finde dll'er til følgende namespaces..

Imports System.Security.Principal
Imports System.Net
Imports System.IO
Imports System.Resources

Ellers kan jeg ikke få det testet igennem...

man skulle tror at System.Sequrity indeholder alt med sequrity.. men nej nej, principal er ikke i denne...

i System.Squrity er kun: System.Squrity.Cryptography.xml <- DAMM !!

OK.. dette burde kompile mit program:

vbc /t:library /out:methods.dll /r:system.dll /r:mscorlib.dll /r:System.drawing.dll methods.vb

Da mscorlib.dll indeholder: "IO", "Collections", "Resources" & "Principal".
System.dll indeholder: "Net".

Det virker dog stadigvæk ikke......
Den melder fejl på ArrayList... men den ligger altså i System.dll !!!

Det kan simpelthen ikke være måden..

Det ER måden, men hvis den giver en compiler fejl på ArrayList er det en manglende "Imports System.Collections". I øvrigt bliver mscorlib.dll og system.dll automatisk refereret af c-skarp kompileren, mon ikke også det gælder for vb kompilere´n?

det kan jeg fortælle at de ikke gør...

Har fået hul på bylden! den første dll er kompilet..

NU er jeg igang med den næste, og der skal jeg bruge den første jeg har lavet...

Den første:
vbc /t:library /out:methods.dll /r:system.dll /r:mscorlib.dll /r:System.drawing.dll methods.vb

Den anden:
vbc /t:library /out:sqlcon.dll /r:methods.dll  /r:system.data.dll /r:system.dll /r:mscorlib.dll iSQLConnection.vb SqlServerConnection.vb

Men nr. 2 fejler på "imports nn2002.methods (som er mit namespace for den 1. dll)". Den siger :
error BC30466: Namespace or type 'Methods' for the imports 'nn2002.Methods' cannot be found.

Hvordan klarer jeg den ?

når jeg åbner methods.dll via min assemblySpy (ser indholdet af en assembly), så er der ingen data i den. methods.dll indeholder ingen klasse, men et et modul med statiske metoder (getNTUser() osv...).

når jeg åbner den exe-fil vs selv laver, kan jeg se alle mine namespaces:

nn2002.classes
nn2002.sqlcon
nn2002.storage
osv...

men nn2002.method figurer ikke... er det derfor den ikke kan finde den? og hvad er løsnignen ?

så snart jeg fjerner referencen til mit namespace "nn2002" (specifikt: nn2002.methods (og samtidigt alle kald til metoder i denne)) så kompiler alt fint...

hvordan kompiler jeg så referencen til mit eget namespace "nn2002" kommer til at virke?

> Z42Cool -> vi har snakket om det før:

Når jeg erklærer mine namespaces så bliver denne:

Namespace classes
    Public Class News
        Private intNId As Integer
        Private strText As String
        Private strHeadline As String
    End Class
End Namespace

..automatisk kaldt via [projektNavn].[Namespace] -> dvs. i mit projekt nn2002.classes... Dette namespace kan importeres i andre klaser i VS.NET uden problemer...

når jeg nu kompiler ovenstående via prompten, kommer [ProjektNavn] jo ikke med, da det er klassen direkte jeg kompiler. News kommer altså til at ligge i namespaces [Classes].

Jeg tror netop dette er mit problem. Efter kopiling i DOS kan jeg ikke henvise til nn2002.classes fra andre filer, da DLL'en indeholder classes UDEN nn2002 foran !!!

Hvordan skal jeg så erklære mine namespaces så

"Namespace classes" betyder opret namespace nn2002.classes

Håber du/I forstår ??

Tj.

????? Du er lidt svær at forstå, men her er hvordan dit problem løses for 2 filer, så kan du selv udvide det:

//SRCFILE 1, LIBRARY (MyLibrary.vb)

Namespace MyLibrary
  Public Class MyClass
    Public Sub MyMethod
    End Sub
  End Class
End Namespace

kompileres med:
vbc /target:library /out:MyLibrary.dll MyLibrary.vb

//SRCFILE 2 - PROGRAM (MyProgram.vc)
'Nu kan vi undlade at fuldt kvalificere klasser fra vores eget namespace
Imports MyNamespace   

Namespace MyProgram
  Public Class App
    Public Shared Sub Main
      Dim myCls As MyClass  'Kun pga. imports
      myCls.MyMethod()
    End Sub
  End Class

kompiler med:
vbc /target:winexe /r:MyLibrary.dll /out:MyProgram.exe MyProgram.vb

Det er vigtigt at have /r med da imports kun er til for at hjælpe med navneresolution!

>> Z42Cool - jeg er egentligt udemærket med på ovenstående..
Men lad mig lige udvide dit eksempel...

Dine 2 vb-filer herover er lavet i VS.NET, og lad os sige at projekt hedder : "WindowsApplikation1". I mit tilfælde vil dit projekt ikke importere MyNameSpace. min vil kun hvis du kalder den med imports Windowsapplication1.MyNamespace.

Windowsapplication1.MyNamespace virker i VS. men når jeg så kompiler i DOS fjernes Windowsapplication1 da det kun er vb-filen der kompileres og ikke hele projektet !!!

Tj.

Er du med? eller ska jeg forklare endnu dybere?

Bare en kommentar angående i hvilket assembly en given klasse, metode etc. ligger: Det fremgår umiddelbart af dokumentationen for den pågældende klasse, metode etc.

>tuxic.. Det man kan se er en henvisning til det tilhørende namespace.. Men du kan ikke ligefrem se hvilken assembly (dll eller exe).

Under System.Net står igenting om at dette namespace findes i filen system.dll

eller hvad med System.collection.arraylist. Den findes i en dll ved navn mscorlib.dll...

Ikke ligefrem indlysende !

Det kan være jeg bilder mig noget ind men det står da klart og tydeligt her:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemcollectionsarraylistclasstopic.asp

Se nederst på siden: Assembly: Mscorlib (in Mscorlib.dll)

mange gange undskyld... det havde jeg ikke set !

jeg har efterhånden fået kompilet mit projekt. Har dog stadig problemer som langtfra er logiske... Men med lidt fuskeri i koden kan jeg kompile via prompten.

eks.

min klasse SqlServerConnection.vb importerer nn2002.classes, da alle mine forretningsmodel-klasser ligger i denne. Dette virker fint i VS-NET.

Når jeg kompiler SqlServerConnection.vb til en dll fra prompten, kan den ikke finde nn2002.classes, da classes jo også er lavet fra prompten, og derfor ikke ligger i nn2002.classes, men bare i classes.

men andre ord at (dll)kompile en klasse skaber altid en klasse i det namespace man angiver (eks. namespace classes), når man kompiler den fra VS, bliver namespacet = [projektet (i VS)].[NAMESPACE].

Derfor er min kode i vs.net som importerer nn2002.classes ikke valid når jeg kompiler fra prompten. Løsningen blev at ændre namespacet (fra classes til nn2002.classes) sætningen i vs.net, og derved bevidst lave en syntaksfejl, derefter kompilere den via prompten (som derfor kommer til at virke). Derefter lave namespacet tilbage i vs og arbejde videre...

Tj.

tak for god debat!