Hello Folks
Har läst in mig lite på .net "VB 7". Känner behov att kräkas lite.

Vb Net kommer att bli en "Flopp" varför i helv....... skall
man jobba med detta verktyg med sina stora brister när
det finns Borlands C++ och Delphi ?

"Sanna mina ord sa krösa Maja"

mvh
Sven

Jag tror på .NET.
Det är en platform som kommer bli tillvis del platforms oberoende pga sin runtime motor. Fokuseringen mot Web service öppnar öpp möjligheten att knyta samman applikationer och låta dem arbeta över internet. Man kan välja vilket språk man vill arbeta med och till och med kompilera en exe/dll som består av flera olika språk. Om man vill hålla sig till vb har den nu mognat lite och stödjer trådar och arv.

Jag tror att man bara begränsas av sin fantasi. Man får omfamna sina visioner...

>Vb Net kommer att bli en "Flopp" varför i helv....... skall
>man jobba med detta verktyg med sina stora brister när
>det finns Borlands C++ och Delphi ?

Är det några speciella brister du vill diskutera så säg det. Att bara komma hit och gnälla är inte så konstruktivt.


MS

>till och med kompilera en exe/dll som består av flera olika språk

Nix, stöd för något sånt finns inte än.


MS

Platsformsoberoende? Menar du då att det kan köra på alla Windows OS? Det är väl det minsta man kan begära.

Kör det på Linux/Unix t.ex?

/Frans

Läste ett inläg i ett annat forum... Gränssnittet stödjewrr det inte men om man använder sig av komandorader för kompilatorn så påstod han att det gick... :O)

Igen
>Att bara komma hit och gnälla är inte så konstruktivt.

Svårt att vara konstruktiv när man läser vilken smörja det är
till det priset och det omfånget. över 1Gb vid installation phuu.

DS

Om man skapar en runtim motor för .NET applikationer för linux /Unix så finns det väl inget som hindrar en från att köra .Net applikationer på dem... Möjlighet finns...

kommer .NET att kräva runtimefiler? oavsätt vilket språk man använder? då kan man ju lika gärna använda det simpla VB istället... eftersom C++ isåfall kommer bli lika trögt och äckligt dåligt...
finns det verkligen ingen som vill utveckla "vanliga" program längre... sådana som fungerar utmärkt som platformsspecifika fristående exe-filer...

.Net runtime kommer att bli väldigt utbredt. Antagligen, efter ett tag, så behöver man inte ha med Runtime när man lanserar program för att det finns på alla datorer. Har givetvis också att göra med vilken målgrupp programmet är riktat till.

Göra en .NET motor till Linux kan vara svårt.. ta DirectX till exempel. man försöker att göra ett motsvarande bibliotek men problemet är att DirectX innehåller så mycket kod som är anpassad till Windows(t.ex. minneshantering). Att porta .NET till Linux kommer nog inte att handla om de släpper källkoden, snarare hur 'snävt ' det är skrivet, dvs hur mycket 'Windows' det är i det.

mvh Frans

>Läste ett inläg i ett annat forum... Gränssnittet stödjewrr det inte men om man använder sig av komandorader för kompilatorn så påstod han att det gick...

Det är i alla fall fel. VB kompilatorn fattar bara VB, C# kompilatorn fattar bara C# osv. Och eftersom de producerar körbara filer direkt, inte några sammanlänkningsbara LIB filer, så finns det inte mycket du kan göra åt saken.


MS

>när man läser vilken smörja det är

Du kanske skulle testa det och bilda dig en egen uppfattning.

.NET är förresten väldigt omfattande, och att diskutera det som helhet är svårt. Det omfattar många delar som man var och en kan tycka är mer eller mindre bra.


>till det priset

Vilket pris? .NET SDK kan du ladda ner gratis, och där ingår fullt fungerande kompilatorer.

VS.NET betan kan du beställa för knappt 200:- har jag för mig. Inte överdrivet dyrt direkt.

Slutprodukten kommer givetvis att kosta mer, men inget pris har satts offentligt än, så det är inte mycket att kommentera i dagsläget.


>och det omfånget. över 1Gb vid installation phuu.

Tänk på att det är en tidig beta du talar om. En beta som har en massa icke-optimerad kod och debugkod kvar i sig. Jag tror definitivt att den färdiga releasen kommer vara mindre. Dessutom kommer du har fler val vid installationen, så du kan välja bort saker du inte behöver. Behåller du t.ex. MSDN på skivan sparar du över 600 MB bara där.


MS

>kommer .NET att kräva runtimefiler?

Ja


>oavsätt vilket språk man använder?

Så länge du har .NET plattformen som grund, ja. Men VC++ 7 kan du använda som tidigare, utan .NET, om du så vill.


>då kan man ju lika gärna använda det simpla VB istället...

Visst, det kommer säkerligen användas länge till.


>eftersom C++ isåfall kommer bli lika trögt och äckligt dåligt...

Varför sätter du likhetstecken mellan runtimefiler och tröghet? Det är vitt skilda saker. Tröga program beror oftast på dåligt skriven kod.

Runtimebiblioteket bör du snarare se som en stor mängd fördigskriven funktionalitet du kan använda. Du slipper skriva hela rasket själv, vilket ger kortare utvecklingstid.


>finns det verkligen ingen som vill utveckla "vanliga" program längre... sådana som fungerar utmärkt som platformsspecifika fristående exe-filer...

Jodå, och existerande utvecklingsverktyg fungerar utmärkt till det.


MS

Inte för att jag bryr mig mycket om vad det kostar men:
Vad betan kostar är ganska ointressant(igentligen borde den inte kosta någonting alls). Det som är intressant är kostnaden på den riktiga releasen och den kommer absolut att vara mer än 200kr. Antagligen i samma nivå som Visual Studio.

Angående storleken. När man tänker på vad man får för 1gb så är det inte mycket att gnälla över: Vem har sagt att ett komplett paket med kompilatorer/editors för en mängd olika språk skulle vara litet/billigt? När man även ser på hur billiga hårdiskar man kan köpa i nuläget så är det lugnt.

/Frans

Om dotNet blir en flopp är bra/dåligt får väl tiden utvisa. Det som jag tycker är svårt är att det finns massor av olika ideer om vad .Net är hur det funkar m.m, märks t.e.x i denna tråd. Känns som alla har sin tolkning av hur det funkar och hur man kan använda .Net.
Länk som tar upp lite av detta: http://www.computerworld.com/cwi/story/0,1199,NAV47_STO60254,00.html

Kanske en svår fråga att besvara men vad krävs av en utvecklingsmiljö för att man ska kunna använda plattformen .Net? Måste den skapa IL-kod som sedan "kompileras" av .Net eller kan man anända klassbiblioteket(CLR?) i vanliga applikationer(istället för win-api). SOAP, XML m.m går ju bra att anväda utan .Net. Altså vad är det som utmärker en .Net applikation och som inte går att göra med existerande utvecklingsmiljöer? (Mycket troligt att jag använt någon av alla dessa förkortningar fel)

Hmm..ytterligare en artikel som inte gör annat än förvirrar. Men så är det ju också en av IDGs tidningar (väl?). Det som folk inte riktigt fattar är att .NET != CLR != Visual Studio.NET != Webservices etc...

Bland annat hängde jag upp mig på uttrycket i artikeln att "Microsoft gjorde ett misstag när de döpte alla sina serverprodukter till .NET Enterprise Servers, trots att de inte har något med webservices att göra" (fri översättning). Nej, de har inte något med webservices att göra, men det har inte heller .NET (eller rättare sagt, webservices är bara en liten (minimal) del av .NET). Jag brukar försöka förklara att .NET i sig är en vision, ingenting annat. Den är allt som Microsoft kommer att arbeta med inom de närmaste fem åren (samt har arbetat med de senaste 2-3 åren). Den innefattar allt från Windows, serverprodukter, .NET Framework (med CLR, IL och allt därtill), utvecklingsverktyg, webservices, .NET Building Blocks (Passport etc), standardarbete (XML, SOAP etc), kort sagt, hela Microsofts verksamhet (möjligen undantaget 'spin-offs' som t ex X-box).

För att svara på din fråga, ja, källkod i en utvecklingsmiljö måste kompileras till IL för att kunna hanteras av CLR och på så sätt utnyttja klassbiblioteket i .NET Framework. Däremot kan man genom interop utnyttja .NET applikationer i 'vanliga' applikationer, och tvärtom. Däremot behöver en applikation inte hanteras av CLR för att utnyttja många av de idéer och produkter som ingår i visionen/strategin/sfären .NET, precis som du nämner har XML och SOAP inget med .NET att göra mer än att .NET stödjer och utnyttjar dem. Likaså kan man ju t ex arbeta med en SQL Server utan att använda klassbiblioteket i .NET.

Angående om det blir segt (mm)...

När man kompilerar ett .net projekt får man Microsoft Intermediate Language (MSIL eller IL), som sedan JITtern får ta hand om (JIT = Just In Time). JITtern och CLR kan väl jämföras med Java och JRE...
Och JA man får segare program. Jag läste nyligen en sammanfattning av .net i microsoft press bok (introducing microsoft.net) och där medger författaren att program skrivna för .net kommer sluka mer minne och vilja ha en snabbare processor. Han tycker dock att det är ett litet pris att betala för vad .net har att erbjuda...
Fast efter vad jag fått ut av boken (och även annan litteratur, sajter mm) håller jag inte med. För webb-applikationer är det defenitivt ett lyft. Då jämför jag asp.net med asp. Det iof är möjligt att tex javas servlets är lika bra som asp.net, men jag är inte tillräckligt insatt för att kommentera vidare...
Man kan dock göra ett net-program som ett icke net-program, med hjälp av command-line programmet Ngen.exe. Detta resulterar att programmet enbart körs EN gång i JITtern - vid tex installation.

Den största fördelen som jag ser der är att man slipper dll-hell ( = ständiga versionsproblem, referenser som hålls kvar fast de inte borde det osv). Bakåtkompabiliteten till com verkar också fungera - man kan både ha net som server med com-klienter och com-server med net klienter. Detta görs med sk wrappers: Runtime Callable Wrapper (rcw) och Com Callable Wrapper (CCW).
Fast hur löser net då transaktions hanteringen? Jo genom att kapsla in net-dll'en i com för att sedan köras i com+... öh, va? ville man inte komma ifrån dll-hell och com? nu krävs ju ändå registrering i registret.

Nu orkar jag inte skriva mer, men det finns även annat i .net att klanka ner på tex finalizerns komplexitet, nur garbage collection fungerar, hur segt vs.net är (jag vet - det är bara en beta...) mm
För att avsluta positivt måste jag säga att asp.net är väldigt trevligt för oss som redan kör asp, samt att jag ändå ser fram emot att börja jobba med .net "på riktigt"!

Klart du ska wrappa in dina .NET komponenter i COM+ om du vill använda de tjänster COM+ erbjuder.. Men däremot behöver du inte göra en COM wrapper runt din .NET app för att använda COM+ tjänster..

Microsoft gjorde ett stort misstag när de kallade nya MTS för COM+. COM? har ingenting med COM att göra utan erbjduder en rad tjänster vilka du kommer åt nekelt via basclass library.

COM+ 1.5(XP, .NET servers) kommer dessutom vara mer optimerat mot .NET och således kommer den att fungera bättre i framtiden.

En annan sak med COM+ är att du verkar tycka det är en dålig sak!?! Den har inte de problem som COM har med registret, visst saker och ting hamnar där, men du kommer kunna köra Side-By-Side execution lika bra i COM+ som ngn annanstans i systemet.

Fråga: Vad med finilizern är det som ät så dåligt? Personligen tycker jag att GC'n och hur den hanterar heapen är ett underbart komplent som kommer ge stabilare och mindre minnesslukande applikationer i slutändan ...

<snip>
Fast hur löser net då transaktions hanteringen? Jo genom att kapsla in net-dll'en i com för att sedan köras i com+... öh, va? ville man inte komma ifrån dll-hell och com? nu krävs ju ändå registrering i registret.
</snip>

Du behöver inte kapsla in din .Net-applikation i COM för att få transaktionshantering. Det räcker att sätta nödvändiga attribut på klassen, så kommer .Net automatiskt att skapa en COM+ applikation åt dig första gången klassen används. Ingen registrering överhuvudtaget behövs.

*asg* Tror att det var precis det jag skrev ;o)

ok, det hade jag missat...

Ang. om jag tycker com+ är dåligt så var inte det meningen att få det att framstå så... com+ är ju kanon jämfört med med com när det gäller registrering. Vad jag däremot tyckte var tveksamt var att wrappa in net i com bara för att komma åt transaktionshanteringen. Men ni poängerade ju att det kommer en ny version, vilket jag inte visste om.

Ang. vad som inte är så bra med GC är tex att man inte kan sätta object till nothing när man vill, man vet heller inte i vilken ordning det städas upp bland object. Man kan dock forca en GC, men inte enbart på ett objekt vilket leder till en del overhead.
Dessutom verkar det väldigt rörigt och suger en hel del minne. Läs tex artikeln på http://msdn.microsoft.com/msdnmag/issues/1100/GCI/GCI.asp

Vad du gör är att du sätter din referens variabel till Nothing. När sedan GC'n upptäcker att ett objekt inte har ngn referens till sig längre så markerar den objekt för collect. Alltså sätter vi inte längre objektet till Nothing utan bara referensen och GC'n tar över hela jobbet. Collects sker sedan när det finns processor tid ledig eller det krävs mer minne från app domainen till applikationen<br><br>


Detta kommer innebära att du inte har en aning om när resursen för objektet släpps, men det behöver man inte som programmerare bry sig om längre. GC står som yttersta skyddet för minnesläckor i applikationen och faktikst som ett skydd för Circular References, vilket varit ett stort problem bland mindre erfarna programmerare. <br><br>


Det vi som programmerare förlorar på är att vi inte kan släppa resurser i finilize metoden, men för mig känns det inte som en större förlust då det är en dålig approach ändå på objekt som ska rulla i stora skalbara lösningar.<br><br>

Vill man däremot fortsätta och lämna ifrån sig resurser (vilket jag starkt förslår att man låter bli) innan/när man släpper referensen till objektet, då kan man ovverrida en funktion från System.ComponentModel.Component som heter Dispose. <br><br>

Dispose är 'calling convention' för en metod vilken släpper alla resurser innan man sätter ett objekt till Nothing och gör en sk Object Clean Up. Du blir tyvärr tvungen att göra det för hand dock :)<br><br>

ex)<br><br>

<code>
Public Class Component1
Inherits System.ComponentModel.Component

Public Sub New()
MyBase.New
End Sub

Protected Ovverides Sub Finilize()
End Sub

Public Overloads Overrides Dispose()
MsgBox("I've been thrown away like a pair of old rags."
End sub

Public Sub DoSomething()
End Sub
End Class

Private sub button1_click(ByVal sender as System.Object, ByVal e as System.Eventargs) Handles button1.click
Dim obj as New Component1()

obj.DoSomething
obj.Dispose
obj = Nothing
End Sub
</code>
<br><br>
BTW, även COM+ 1.0 klarar sig bra utan COM wrapper för att köra .NET komponenter ...

>Alltså sätter vi inte längre objektet till Nothing utan bara referensen

Det är ju vad vi alltid har gjort.


>Det vi som programmerare förlorar på är att vi inte kan släppa resurser i finilize metoden

Menar du Class_Terminate? Finalize går aldeles utmärkt att använda till att rensa upp, även om det inte alltid är så bra.


>lämna ifrån sig resurser (vilket jag starkt förslår att man låter bli)

Varför?


>kan man ovverrida en funktion från System.ComponentModel.Component som heter Dispose.

... eller helt enkelt implementera IDisposable, om man inte vill ärva från Component.


>Du blir tyvärr tvungen att göra det för hand dock :)

Inte om man använder C# ;-)


MS

>Alltså sätter vi inte längre objektet till Nothing utan bara referensen
>Det är ju vad vi alltid har gjort.
Nja, i vb programmerares ögon har det varit objektet.

>Det vi som programmerare förlorar på är att vi inte kan släppa resurser i finilize metoden
>Menar du Class_Terminate? Finalize går aldeles utmärkt att använda ¨
>till att rensa upp, även om det inte alltid är så bra.
Självklart är det terminate jag menar, men i .NET är samma funktion finilize, vilken inte släpps förrän gc har gjort en collect, lagt den i finilizer kön och kört en finilize.

>lämna ifrån sig resurser (vilket jag starkt förslår att man låter bli)
>Varför?
Därför att om du ligger och håller en massa resurser som du inte använder under objektets livstid bara för att det är bekvämt, kommer du få problem med througput ganska snart, bättre då att allokera och release resurser snabbt i metod anrop.

>kan man ovverrida en funktion från >System.ComponentModel.Component som heter Dispose.
>... eller helt enkelt implementera IDisposable, om man inte vill ärva f
>rån Component.
Klockrent ..

>Du blir tyvärr tvungen att göra det för hand dock :)
>Inte om man använder C# ;-)

Varför skiljer sig C# mot VB.NET's GC, du menar väl inte på allvar att dispose kallas i C# men inte i VB.NET automatiskt???

>Nja, i vb programmerares ögon har det varit objektet.

Inte i mina ögon :-) Förstår ärligt talat inte riktigt hur du menar, men det kanske kvittar.


>Därför att om du ligger och håller en massa resurser som du inte använder under objektets livstid bara för att det är bekvämt, kommer du få problem med througput ganska snart, bättre då att allokera och release resurser snabbt i metod anrop.

Okej, så det är alltså att skapa "stateful" komponenter med medlemsvariabler som måste frigöras som du är emot. Det kan jag förstå. Förut lät det som om du tyckte all form av upprensning var dålig, vilket verkade lite konstigt.



>Varför skiljer sig C# mot VB.NET's GC

Det gör den inte, alla språk har samma.


>du menar väl inte på allvar att dispose kallas i C# men inte i VB.NET automatiskt???

Njo, på sätt och vis. C# har sin using konstruktion

using (X y = new X()) {
// X är en typ som implementerar IDisposable
// kod som använder y här
}

som är ett kortare sätt att skriva

X y = new X();
try {
// kod som använder y här
}
finally {
if ( y != null) ((IDisposable)y).Dispose();
}

Använder man using blocket slipper man alltså själv att tänka på att anropa Dispose. Men det är naturligtvis inte alltid det bästa sättet att göra såhär, och jag vet ärligt talat inte hur användbart using kommer visa sig vara. Time will tell....


MS

Nä inte i mina ögon heller ( objektet till nothing inte variablen), men som frågan var ställd, så kom repsonsen ..

nä all form av upprensing är inte dålig.. men jag tyckerr man borde göra dem i metod anropen, ingen ananstans ..


vad jag menade med GC'n var att om den skiljde sig och kallade på dispose när ett objekt tappade referens, förstod inte annars hur dispose skulle kunna bli kallat när ett objekts _alla_ refernser försvinner ...

Har för lite koll på C# för att kommentera Using, men skulle det vara så att den har en automatisk funktionalitet för att svara på en obj = nothing, då har MS klantat sig rejält vad gäller kompabilitet mellan språken ... är inte bara en liten miss ...

ska kolla om det inte är så att Using finns i VB och kan köras därifrån, återkommer om det ...

>Har för lite koll på C# för att kommentera Using, men skulle det vara så att den har en automatisk funktionalitet för att svara på en obj = nothing

Nej, alltså ett using block är enbart ett kortare sätt att skriva följande (denna gång som VB kod), inget annat

Dim y As New X
Try
' använd y
Finally
If Not y Is Nothing Then CType(y, IDisposable).Dispose
End Try



>ska kolla om det inte är så att Using finns i VB och kan köras därifrån,

Nix, det finns inget liknande. Man får skriva ut det som ovan.


MS

Hmm varför just:

<code>
If Not y Is Nothing Then CType(y, IDisposable).Dispose
</code>

???

Vad i using gör så att typen konverteras till IDisopsable och metoden dispose anropas??

Kan vi bara klara ut GC'n lite...

Jag har läst och kommit fram till följande:
Det finns ingen garanti att finlize anropas i runtime (det är detta som innebär deterministic finalization). Pga detta är det rekommenderat att ha en cleanup-metod i sin klass (typ Dispose). Det är sedan upp till klienten att anropa den. Mao så finns det ingen garanti!

...som sagt -jag gillar det inte riktigt, med jag börjar ändå se att fördelarna (kanske;) överväger nackdelarna.

>Vad i using gör så att typen konverteras till IDisopsable och metoden dispose anropas??


Kompilatorn gör det vid kompilering.


MS

Varför ??? Varför just dispose metoden?

OM jag skull göra samma sake med ICollection, vad skulle hända då och varför ???

>Varför ??? Varför just dispose metoden?

Det är vad using är till för helt enkelt.


>OM jag skull göra samma sake med ICollection, vad skulle hända då och varför ???

Du kan inte påverka vilket gränssnitt som används, det är alltid IDisposable.

Tror inte jag kan förklara mer nu. Om du har VS.NET beta 2 installerat, kolla om denna sida gör saken lättare att förstå:

ms-help://MS.VSCC/MS.MSDNVS/csspec/html/vclrfcsharpspec_8_13.htm


MS