Lagd en dll men my.app.info.version gir feil verdi

[Wubbable]

Har lagd en DLL i visual basic 2005 som har en funksjon som skal returnere versjonen dens (definert i "My Project")

 

        
Public Function getversion()
     getversion = My.Application.Info.Version
End Function

 

Så lager jeg en knapp i programmet som skal bruke den, og gir knappen kommandoen "getversion()"

Problemet er at verdien som blir returnert er programmets versjon, ikke DLLens versjon...

 

Noen måte å fikse dette på?

 

 

Også et annet problem:

Er det mulig å finne ut hvilke versjoner programmets referanser (DLL filer) har?

Vil at folk ikke skal bruke en gammel versjon av DLL filen når jeg gir ut nye versjoner av programmet....

 

I hovedsak, DLLen gir versjonen sin til programmet med getversion(), og programmet sjekker om det er den DLLen den er referenced til

Endret 14. januar 2007 av Vigilant

[flyndrefjes]

Har lagd en DLL i visual basic 2005 som har en funksjon som skal returnere versjonen dens (definert i "My Project")

 

        
Public Function getversion()
     getversion = My.Application.Info.Version
End Function

 

Så lager jeg en knapp i programmet som skal bruke den, og gir knappen kommandoen "getversion()"

Problemet er at verdien som blir returnert er programmets versjon, ikke DLLens versjon...

...klipp...

Dette er ikke noe direkte svar. Jeg har selv i mange år programert i VB. Glem det, det har ingen fremtid. Gå over til andre prog.språk!!

[Wubbable]

Spurte jeg om hva du hadde, eller om det hadde noen fremtid?

 

--> NEI <--

[j000rn]

System.Reflection.Assembly.GetExecutingAssembly().GetName().Version

[GeirGrusom]

System.Reflection.Assembly.GetExecutingAssembly().GetReferencedAssemblies()

 

Jeg forstår ikke hvorfor det er så mange som klager på Visual Basic, jeg bruker det ikke selv, men jeg fatter ikke hva som er så ille med det.

Selv har jeg mange års erfaring med Visual Basic, og det er egentlig helt greit å bruke, og så lenge det er et .NET språk, så spiller det i og for seg liten rolle, siden det er lett for folk som ikke kan Visual Basic fra før å forstå hva koden gjør.

Endret 14. januar 2007 av GeirGrusom

[Wubbable]

System.Reflection.Assembly.GetExecutingAssembly().GetName().Version

7718147[/snapback]

Takker... Men hvordan sjekker jeg hvilken DLL programmet ble bygd med?

Går det an å finne disse verdiene på en måte:

 

EDIT: Den i overnevnte post, er det den?

EDIT2: Prøvde den du sa geirgrusom, men forstår ikke helt hvordan jeg bruker den... Prøvde textbox1.text = System.Reflection.Assembly.GetExecutingAssembly().GetReferencedAssemblies().ToString()

Men det hjalp lite

Endret 14. januar 2007 av Vigilant

[GeirGrusom]

Public Function GetRefList() As String
   Dim output As String = ""

   Dim refs As System.Reflection.Assembly() = System.Reflection.Assembly.GetExecutingAssembly().GetReferencedAssemblies()

   For Each asm As System.Reflection.Assembly In refs
       output &= asm.Name & Environment.NewLine
   Next

   Return output
End Function

[Wubbable]

Den koden din fungerte ikke helt

[HDSoftware]

Dette er ikke noe direkte svar. Jeg har selv i mange år programert i VB. Glem det, det har ingen fremtid. Gå over til andre prog.språk!!

7716649[/snapback]

Hvorfor sier du dette? Har du noe som helst belegg for å si det?

 

Jeg har selv valgt å gå over fra Clarion til Visual Basic og det av følgende grunner:

1. Det støtter .NET

2. Det har en glimrende database tilkobling

3. Streng håndtering er av ypperste kvalitet

4. All form for kalkulering støttes 100%

5. OCX'er "sklir" rett inn i utviklings språget

6. Det er enkelt å lage DLL'er

7. Hele utviklings miljøet VS har et genialt oppbygget GUI

8. Basic er utrolig enkelt å programmere og lære

9. Og hastigheten er slett ikke værst.

10. Dette er et av Microsoft's satsningspunkter

 

Kan sikkert nevne enda flere ting, men siden du hevder det er så ubrukelig så vil jeg gjerne høre dine synspunkter på hvorfor VB er så elendig. Skulle også gjerne vist hva du programmerer i og hva du lager. Også nysgjerrig på hvor fort du fullfører et prosjekt og hvor mye du klarer å tjene på det pr. time. Selv har jeg en timepris på ca 800,- fordi jeg klarer å fullføre raskt. Hadde jeg brukt C eller noe annet lavnivå greier så tipper jeg timeprisen raskt hadde sunket ned til et par hundringser.

 

 

Ole

[Moskus]

Huff da, HD. Nå kommer snart Manfred og sabler oss ned...

[HDSoftware]

Huff da, HD. Nå kommer snart Manfred og sabler oss ned...

7732371[/snapback]

HIHI! Bare var nødt. Verden er full av folk som hele tiden prøver å si noe de har hørt og ikke har belegg for i det hele tatt. Så jo at han hevdet at han hadde programmert VB i mange år, men til hva? Personlig er det viktigste med et programmeringsverktøy å komme rask til mål. Det å kunne håndtere minne er for meg helt uvesentlig. Mine kunder har bruk for administrative programmer som kundelister, møteprotokoller, tekst håndtering etc. etc. Hva påkker skal jeg med pekere og slikt. VB er jo helt genialt til akkurat dette.

 

HIHI!! Rakk det før sabelen kom......

 

Ole

[Moskus]

Personlig er det viktigste med et programmeringsverktøy å komme rask til mål.  Det å kunne håndtere minne er for meg helt uvesentlig.[...] VB er jo helt genialt til akkurat dette.

7732394[/snapback]

 

Helt enig!

Produktivitet og tilgjengelighet foran fullblods nerding.

[GeirGrusom]

Personlig bruker jeg ikke VB fordi jeg synes koden blir veldig urydding og uoversiktelig.

Men som verktøy er det da for pokker ikke noe verre en andre RAD språk,

det har noe med preferanser å gjøre.

[Wubbable]

Synes visual basic er ryddig jeg, i C# må du f.eks. ha en god del med { og }'er

 

Blir jo mer rot av det ^^

[GeirGrusom]

tja, egentlig ikke

public int main()
{
 System.Drawing.Bitmap bmp = new Bitmap(100, 100);
 for(int x = 0; x < 100;x++)
   for(int y = 0; y < 100;y++)
     bmp.SetPixel(x, y, Color.White)
}

Public Function main() As Integer
 Dim bmp As New System.Drawing.Bitmap(100, 100)
 For X As Integer = 0 To 100
   For Y As Integer = 0 To 100
     bmp.SetPixel(X, Y, Color.White)
   Next
 Next
End Function

for meg er C# versjonen mer ryddig og oversiktelig...

men det er vel mest som smak og etc.

[Moskus]

Mangler du ikke noen {'er og }'er i den C# koden? Eller blander jeg med C++?

[ze5400]

Mangler du ikke noen {'er og }'er i den C# koden? Eller blander jeg med C++?

7748468[/snapback]

 

 

Mener å huske at hvis det bare gjelder linja under slipper man {}

[GeirGrusom]

Man trenger ikke { } hvis det går under én linje, samme som at du ikke trenger End If i VB hvis du skriver hele IF setningen på én linje.

 

Samme gjelder for C++ som C# i dette tilfellet (med små endringer er koden gyldig i C++ også)

C++:

public:
int main()
{
System::Drawing::Bitmap *bmp = new System::Drawing::Bitmap(100, 100);
for(int x = 0; x < 100;x++)
  for(int y = 0; y < 100;y++)
    bmp->SetPixel(x, y, System::Color::White)
}

[Moskus]

Ja, jeg tror dere. Men jeg syns bare det er forvirrende da en for-løkke ikke går over en linje...

 

Men min forståelse av C#/++ er forholdsvis begrenset.

Endret 19. januar 2007 av moskus

[GeirGrusom]

I motsetning til VB, kunne alt her blitt skrevet på en linje:

public int main(){ System.Drawing.Bitmap bmp = new Bitmap(100, 100); for(int x = 0; x < 100;x++) for(int y = 0; y < 100;y++)bmp.SetPixel(x, y, Color.White) }

Siden ; er linjeskilleren.

både { og ; betyr at en ny linje med kode begynner.