[VB.NET] App. compileren voor omg. zonder .NET framework

[nljuggler]

Ik heb een aantal stukjes gevonden over managed en unmanaged code in VB.NET. Van wat ik er tot zover van begrijp, maakt unmanaged code geen gebruik van het .NET framework.

Mijn vraag: Is het mogelijk een VB.NET project zo te compileren, zodat het op een machine kan draaien waar het framework niet geïnstalleerd is?

[whoami]

Nee.

Je hebt het .NET framework nodig:
- Je app draait onder de runtime
- Je hebt de classlib's nodig

unmanaged code wordt niet 'beheerd' door de CLR.

[ Voor 96% gewijzigd door whoami op 29-03-2004 09:47 ]

[nljuggler]

Kort, krachtig, duidelijk.

[SeeSharp.nl]

Het framework moet geinstalleerd zijn op de pc waar je de software wil draaien.

[GX]

Om de vraag dan uit te breiden;

Is er een tool beschikbaar die managed code om kan zetten naar unmanaged? Of moeten we dan zelf l337 alles handmatig om gaan zetten, of gewoon stoer doen en vanaf het begin af aan unmanaged coden?

Laatste lijkt mij een schoner resultaat te geven, maar toch kan een tool handig zijn in een situatie die ik nu niet kan bedenken

[gorgi_19]

GX schreef op 29 maart 2004 @ 10:15:
Om de vraag dan uit te breiden;

Is er een tool beschikbaar die managed code om kan zetten naar unmanaged? Of moeten we dan zelf l337 alles handmatig om gaan zetten, of gewoon stoer doen en vanaf het begin af aan unmanaged coden?

Laatste lijkt mij een schoner resultaat te geven, maar toch kan een tool handig zijn in een situatie die ik nu niet kan bedenken

Als je toch alles wilt gaan omzetten, waarom werk je dan nog in VB.Net en neem je niet een andere taal?
Afaik moet het Framework gewoon geinstalleerd worden en kan je geen unmanaged code in VB.Net kwijt. Alleen C# kan dit aan.

[whoami]

Ik zat ook te twijfelen of je in VB.NET unmanaged code kon hebben. Maar zelfs als je unmanaged code hebt, wil dat nog niet zeggen dat die code zonder het .NET framework kan draaien.

Ik vraag me trouwens -net als gorgi_19- af, waarom je in .NET zou gaan programmeren, als je dan geen gebruik wilt maken van het .NET framework?

[gorgi_19]

Sowieso lijkt me dat het idee van 1 centraal framework een beetje teniet wordt gedaan als alle applicaties alsnog hun eigen versie van het framework, of gedeelte, meegestuurd gaat worden.

[pjvandesande]

Ik snap niet waarom er zo moeilijk wordt gedaan over het .NET Framework. Je kan dit gewoon meenemen in je installatie en het is gratis te downloaden op de Microsoft site. Het is ook al standaart megenomen in de Windows Updater. En straks zit het in je OS ingebakken en heeft niemand het er meer over.

Je hebt voor VB ook je runtimes nodig en voor JAVA je Virtual Machine.

[GX]

gorgi_19 schreef op 29 maart 2004 @ 10:18:
[...]

Als je toch alles wilt gaan omzetten, waarom werk je dan nog in VB.Net en neem je niet een andere taal?
Afaik moet het Framework gewoon geinstalleerd worden en kan je geen unmanaged code in VB.Net kwijt. Alleen C# kan dit aan.

Bijvoorbeeld omdat iemand anders een boel geschreven heeft, en ik wil geen framework-code hebben
Ik doel niet op een reele situatie met m'n post, maar het zou kunnen gebeuren, vooral als je iemands positie overneemt.

questa schreef op 29 maart 2004 @ 10:29:
Ik snap niet waarom er zo moeilijk wordt gedaan over het .NET Framework. Je kan dit gewoon meenemen in je installatie en het is gratis te downloaden op de Microsoft site. Het is ook al standaart megenomen in de Windows Updater. En straks zit het in je OS ingebakken en heeft niemand het er meer over.

Je hebt voor VB ook je runtimes nodig en voor JAVA je Virtual Machine.

Het probleem eraan vind ik dat het geheugen vreet als een gek, een simpele VB.net "Hello world" eet al 18 mb aan geheugen hier! (Framework eet 9 en de app ook - Maar dat kan ook liggen aan mijn gebrek aan VB.Net kennis ). Echter weet ik niet of het evenredig omhoog klimt als de applicatie groeit. Verder is de opzet van .Net wel fijn. Vooral als je ook met PEAR werkt raak je snel gewend aan de standaard classes...

[ Voor 4% gewijzigd door GX op 29-03-2004 11:32 ]

[gorgi_19]

GX schreef op 29 maart 2004 @ 11:31:
Bijvoorbeeld omdat iemand anders een boel geschreven heeft, en ik wil geen framework-code hebben
Ik doel niet op een reele situatie met m'n post, maar het zou kunnen gebeuren, vooral als je iemands positie overneemt.

Als je geen frameworkcode wilt hebben, kan je ook geen regel programmeren. Zelfs de standaard / oude VB functies staan in een .Net class, namelijk Microsoft.VisualBasic.
Verder worden applicaties dan ontzettend groot, omdat dubbele code gebruikt moet gaan worden,

Het probleem eraan vind ik dat het geheugen vreet als een gek, een simpele VB.net "Hello world" eet al 18 mb aan geheugen hier! (Framework eet 9 en de app ook - Maar dat kan ook liggen aan mijn gebrek aan VB.Net kennis ). Echter weet ik niet of het evenredig omhoog klimt als de applicatie groeit. Verder is de opzet van .Net wel fijn. Vooral als je ook met PEAR werkt raak je snel gewend aan de standaard classes...

Als het geheugen beschikbaar is, pakt hij deze. Heeft hij geheugen nodig, dan kijkt hij of hij geheugen vrij kan maken (of ondertussen al vrigjemaakt is)

[ Voor 9% gewijzigd door gorgi_19 op 29-03-2004 11:36 ]

[GX]

gorgi_19 schreef op 29 maart 2004 @ 11:34:
Als je geen frameworkcode wilt hebben, kan je ook geen regel programmeren. Zelfs de standaard / oude VB functies staan in een .Net class, namelijk Microsoft.VisualBasic.
Verder worden applicaties dan ontzettend groot, omdat dubbele code gebruikt moet gaan worden,

Volgens mij kan je ergens een unmanaged project aanmaken, ben ik echter niet zeker van. (Ik heb geen VS.Net op deze pc)

Als het geheugen beschikbaar is, pakt hij deze. Heeft hij geheugen nodig, dan kijkt hij of hij geheugen vrij kan maken (of ondertussen al vrigjemaakt is)

Je bedoeld hiermee dat hij een soort van 'pool' aanmaakt en daaruit de nodige resources plukt? Of echt dat hij gewoon alles maar inlaadt wat met framework te maken heeft?

_{Het is maandag, ik ben niet helder.}

[gorgi_19]

GX schreef op 29 maart 2004 @ 11:40:
[...]
Volgens mij kan je ergens een unmanaged project aanmaken, ben ik echter niet zeker van. (Ik heb geen VS.Net op deze pc)

Het zou me niets verbazen als je een c++ project kan aanmaken, welke volledig bestaat uit unmanaged code en welke ook geen .Net nodig heeft. Geen idee; nog nooit dit onderzocht.
Alleen dan werk je niet in VB.Net / C# / C++.Net. VS.Net ondersteunt meerdere talen.

Je bedoeld hiermee dat hij een soort van 'pool' aanmaakt en daaruit de nodige resources plukt? Of echt dat hij gewoon alles maar inlaadt wat met framework te maken heeft?

Nee, Garbage Collection Hij laadt een aantal onderdelen in, en zaken die hij niet meer gebruikt, gooit hij pas later weg. Verder kijkt hij ook naar de hoeveelheid beschikbaar geheugen. Veel geheugengebruik is niet erg, zeker niet als het toch anders maar niets staat te doen.

[ Voor 20% gewijzigd door gorgi_19 op 29-03-2004 11:46 ]

[GX]

gorgi_19 schreef op 29 maart 2004 @ 11:42:
Het zou me niets verbazen als je een c++ project kan aanmaken, welke volledig bestaat uit unmanaged code en welke ook geen .Net nodig heeft. Geen idee; nog nooit dit onderzocht.
Alleen dan werk je niet in VB.Net / C# / C++.Net. VS.Net ondersteunt meerdere talen.

Even m'n laptop aangeslingerd, en inderdaad, het kan tot zover ik gezien heb alleen in C++.

Nee, Garbage Collection Hij laadt een aantal onderdelen in, en zaken die hij niet meer gebruikt, gooit hij pas later weg. Verder kijkt hij ook naar de hoeveelheid beschikbaar geheugen. Veel geheugengebruik is niet erg, zeker niet als het toch anders maar niets staat te doen.

Ok, helemaal gelijk. Maar toch schrok ik van dat geheugengebruik, verder draait een helloworld app nooit zo lang dus die resource vermindering maak ik dan logischerwijs nooit mee.
Bij deze is mijn anti-.Net argumentatie beeindigd

[whoami]

gorgi_19 schreef op 29 maart 2004 @ 11:42:
[...]

Nee, Garbage Collection Hij laadt een aantal onderdelen in, en zaken die hij niet meer gebruikt, gooit hij pas later weg. Verder kijkt hij ook naar de hoeveelheid beschikbaar geheugen. Veel geheugengebruik is niet erg, zeker niet als het toch anders maar niets staat te doen.

Niet helemaal correct.
Garbage collection zorgt ervoor dat geheugen-blokken die ge-alloceerd werden, en die niet meer 'bereikbaar' zijn (waar er geen referenties meer naar zijn) vrijgegeven worden.
Garbage collection 'kicked' trouwens pas op bepaalde momenten in. Wanneer dit gebeurt, wordt door de CLR bepaald op basis van de allocaties enzo die gebeuren.