[C#] vrije ruimte op Hd ophalen

[noot101]

Ik ben in Visual C# 2005 Express Beta een console applicatie aan het schrijven. Hierin wil ik weten wat de grootte en de vrije ruimte is op de harde schijven van het systeem waar het programma op draait.

Met een Windows applicatie is het me wel gelukt door de performance counters te gebruiken. Maar deze zijn niet beschikbaar in een console application. Verder heb ik ook al verschillende scripts gevonden via google, maar hierbij wordt overal gebruik gemaakt van System.management. Maar deze management class bestaat bij mij niet.
Kan het zijn dat de functies hiervoor in een andere class verstopt zitten? of moet ik op een andere manier de vrije ruimte opvragen?

[SlowMeDown]

Met onderstaande code kun jij denk ik een heel eind komen.

code:

[DllImport("kernel32.dll", CharSet=CharSet.Auto, SetLastError=true)] 
public static extern bool GetDiskFreeSpaceEx(
  [MarshalAs(UnmanagedType.LPTStr)] string lpDirectoryName, 
  ref long lpFreeBytesAvailable, 
  ref long lpTotalNumberOfBytes, 
  ref long lpTotalNumberOfFreeBytes);

[__fred__]

http://msdn2.microsoft.co...bt1306t(en-us,vs.80).aspx

[whoami]

Waarom zijn performance counters niet beschikbaar in een console app ?
Een console app is ook een Windows app.

Je moet gewoon de System.Diagnostics namespace usen, en je kan gebruik maken van de PerformanceCounter class.
In de MSDN staat er trouwens een voorbeeld van een console-app die een perf-counter gebruikt.

Maareh, als je .NET 2.0 gebruikt, dan kan je evengoed gebruik maken van de DriveInfo class zoals hierboven al aangegeven werd.

[ Voor 18% gewijzigd door whoami op 27-06-2005 12:07 ]

[noot101]

Bedankt voor de oplossingen.
Ik heb het gedaan via de dll-import zoals hierboven staat. Dit werkt goed.

[whoami]

En dan kies je dus maar ff voor de moeilijkste, meest onlogische en minst standaard oplossing.

Heb je dat nu gekozen omdat je het stukje kant en klaar voorgekauwd kreeg, en je maar hoefde te copy / pasten, of heb je er ook een logische verklaring voor ?

[SlowMeDown]

Als je inderdaad alleen .NET 2.0 gebruikt, zou ik ook voor de DriveInfo class gaan. Is een stuk netter dan een DllImport of een System.Management class. Maar dat is mijn mening.

[Alex]

SlowMeDown schreef op maandag 27 juni 2005 @ 12:16:
Als je inderdaad alleen .NET 2.0 gebruikt, zou ik ook voor de DriveInfo class gaan. Is een stuk netter dan een DllImport of een System.Management class. Maar dat is mijn mening.

Kun je dat beargumenteren?
Het zou mij niets verbazen als de DriveInfo class een mooie presentatie laag is van de System./Diagnostics?
De meetse nieuwe features in .Net 2.0 zit hem in een hoop syntax sugar, wat leuke dingetjes voor ASP.Net en daarnaast het heel veel eenvoudiger maken van een hoop classes in het Framework...

[Zr40]

Alex de Groot schreef op maandag 27 juni 2005 @ 22:15:
[...]
Kun je dat beargumenteren?
Het zou mij niets verbazen als de DriveInfo class een mooie presentatie laag is van de System./Diagnostics?
De meetse nieuwe features in .Net 2.0 zit hem in een hoop syntax sugar, wat leuke dingetjes voor ASP.Net en daarnaast het heel veel eenvoudiger maken van een hoop classes in het Framework...

Door het framework de onderliggende API aan te laten roepen, zorg je ervoor dat je eigen code zonder problemen op andere platforms werkt, zoals Mono onder Linux. Daarnaast hoef je je code niet aan te passen, als de onderliggende API zou wijzigen.

Volgens Reflector roept DriveInfo.TotalFreeSpace inderdaad GetDiskFreeSpaceEx aan.

[whoami]

Alex de Groot schreef op maandag 27 juni 2005 @ 22:15:
[...]


Kun je dat beargumenteren?

Dat hoeft niet beargumenteerd te worden; waarom zou je de abstractie die het .NET framework biedt niet gebruiken ?

De meetse nieuwe features in .Net 2.0 zit hem in een hoop syntax sugar

partial classes, generics, indigo, noem ik anders geen syntax sugar.

[Alex]

whoami schreef op dinsdag 28 juni 2005 @ 08:38:
[...]
Dat hoeft niet beargumenteerd te worden; waarom zou je de abstractie die het .NET framework biedt niet gebruiken ?

Aangezien ik uit ervaring zie dat als iets op meerdere keren in één framework op vrijwel exact dezelfde manier kan, dat je dan op den duur een wildgroei van features ziet, en verbastering van het Framework.
Ik ben er niet explicit tegen, maar 'netter' is het sowieso niet.

partial classes, generics, indigo, noem ik anders geen syntax sugar.

Waar hebben we het over? Het opsplitsen van classes over meerdere files? Typebased lists? Niets nieuws aan, slecht gejat van Java, en nog makelijk zelf te maken ook.
En tsja, dat er Indigo, in zit, waar Longhorn op gebaseerd is, wat het Framework moet worden van Blackcomb, ach niet schokkend, hoe wil je ander je nieuwe platform innoverend gaan noemen? Overigens heb je het dan meer over nóg een DLL-Hell-Geval aangezien Indigo ook niet volledig .Net is, maar vast goed geport is. Dat stond laatsts zo mooi op de FP ;-).
Als ze voor native support van Avalon zouden zorgen, dan kunnen me praten
Maar dat zal wel niet gebeuren tijdens de release van 2.0...

* Alex is XAML prol337

[ Voor 11% gewijzigd door Alex op 29-06-2005 00:05 ]

[SlowMeDown]

Kun je dat beargumenteren?

Via de DllImport wordt een win32 api functie aangeroepen. Als er een managed .NET equivalent is, is dat zeker niet aan te raden. Zul je met mij eens zijn. De System.Management (via WMI) classes zijn een beetje overkill vind ik, maar dat is een persoonlijke opinie. Als er een dedicated .NET class is, verdient die mijn voorkeur.

De meetse nieuwe features in .Net 2.0 zit hem in een hoop syntax sugar, wat leuke dingetjes voor ASP.Net en daarnaast het heel veel eenvoudiger maken van een hoop classes in het Framework...

Als je nog iets korter door de bocht gaat, raak je de binnenkant. Ik ga hier niet serieus op in, want dan ontaard dit topic toch in een wel/niet discussie, maar als jij echt denkt dat de nieuwe zaken in .NET 2.0 wat 'sugar' en niets meer zijn, zou ik VS2005 nog eens starten en eens heel goed gaan kijken. Ik vind de voortuitgang in ieder geval gigantisch. En dat meen ik.