[VisualStudio] Brak?

[Sebazzz]

Korte probleembeschrijving:
Ik heb dit stukje code

C#:

                TextWriter w = new StreamWriter("database.xml", false, Encoding.UTF8);
                XmlSerializer s = new XmlSerializer(typeof(Database));
                s.Serialize(w, this.DB);
                w.Close();
                w.Dispose();

Dit werkt wel in een executable die ik gisteren heb gecompileerd, maar nu totaal niet meer. Hij blijft maar de fout geven dat bestand niet toegangelijk is omdat het door een ander proces wordt gebruikt. Oké, misschien zou dat zo zijn maar het probleem is dat het bestand pas op regel 1 hier aangemaakt wordt! Kortom, dat ie bij regel 3 crasht zou niet mogen kunnen omdat ie dezelfde stream gebruikt. Wie weet wat het probleem kan zijn?

Dit is wel heel frustrerend! Zelfs de disassembly is volgens Dis# hetzelfde.

[asfaloth_arwen]

Solution cleanen/rebuilden? Computer rebooten? Helpt vaak bij vage errors in mijn ervaring.

[Sebazzz]

asfaloth_arwen schreef op donderdag 29 januari 2009 @ 19:12:
Solution cleanen/rebuilden? Computer rebooten? Helpt vaak bij vage errors in mijn ervaring.

Cleanen en rebooten had ik al gedaan. Geen effect. Met de oude build van de applicatie kan ik hetzelfde bestand overigens wel opslaan op dezelfde manier.

[Snake]

Je hebt 'm gisteren gecompileerd, je hebt dus de source. Plaats eens breakpoints en kijk wat fout is.

[asfaloth_arwen]

with ^^. Je kunt overigens met process explorer / file explorer(of even testen met een ander bestand) bekijken of het probleem idd is dat het bestand niet toegankelijk is of dat er toch een ander probleem is.

[Sebazzz]

Tsja, ik heb al 50 keer gedebugged maar hij crasht steeds bij s.Serialize(w, this.DB). Ook als ik handmatig een FileStream met of zonder FileShare open. Het maakt totaal niet uit

Met Unlocker en Explorer zie ik wel dat het bestand pas op regel 1 aangemaakt wordt, en dat alleen het programma er een lock op heeft. Als ik het lock weghaal voordat ie ernaar geschreven heeft verklaard .NET de uitvoerstroom ongeldig en gooit een System.IOException in plaats van System.InvalidOperationException op.

[Snake]

2 instances van de app draaiend? Andere manier waarop je het bestand opent? (Read, ReadWrite, ...)

En wat is de innerexception?

[Sebazzz]

Snake schreef op donderdag 29 januari 2009 @ 19:29:
2 instances van de app draaiend? Andere manier waarop je het bestand opent? (Read, ReadWrite, ...)

En wat is de innerexception?

Nee, maar één instance open. En aangezien het bestand bij regel 1 gecreerd wordt kan er nooit een andere instance zijn. Manier van open maakt geen drol uit. Innerexception is een System.IOException die mij dus vertelt dat het bestand in het gebruik is, terwijl de bovenliggende InvalidOperationException verteld dat er iets fout ging.

[urk_forever]

Misschien kan je even een kleine test case online zetten, dan kan iemand hier die even draaien, kijken of het probleem in jouw pc of in de code zit.

Een ander idee is om misschien de filenaam aan te passen om te kijken of het dan wel werkt.

[whoami]

Heb je een virusscanner draaien ?
Wat gebeurt er als je je app draait buiten VS.NET ?

[Stukfruit]

Gebruik je toevallig Vista?

Pardon, ik had niet goed gelezen, nm

[ Voor 48% gewijzigd door Stukfruit op 29-01-2009 20:53 ]

[Sebazzz]

Ik draai alleen een passieve Clamwin virusscanner, en Spybot Teatimer voor het register. Vanmidden om 12.00 deed alles het nog, het begon pas na het avondeten te bokken. Ik snap niet dat de oude executable geen problemen heeft terwijl de disassembly hetzelfde is. Uiteraard draai ik het ultieme developer platform: XP. Administrator SP3, .NET SP3.

Eerder heb ik ook al een topic in DTE gemaakt, en dat was een probleem dat zichzelf oploste. Ik hoop dat het met dit ook gaat gebruiken en ik kijk er morgenmiddag wel weer naar maar toch zou ik ook graag een verklaring willen weten, wat het-hoort-niet.

[ Voor 39% gewijzigd door Sebazzz op 29-01-2009 20:54 ]

[Snake]

1) XP is niet ultiem... het kan nog niet eens meer als 3.2GB addresseren.
2) Post meer code aub.

[ Voor 31% gewijzigd door Snake op 29-01-2009 21:02 ]

[RobIII]

Snake schreef op donderdag 29 januari 2009 @ 21:01:
1) XP is niet ultiem... het kan nog niet eens meer als 3.2GB addresseren.

Dat heeft geen drol met XP te maken maar met de hoeveel-bits-heid van je OS En XP64 kan prima tot (ik meen) 128GB addresseren.

[Snake]

RobIII schreef op donderdag 29 januari 2009 @ 21:06:
[...]

Dat heeft geen drol met XP te maken maar met de hoeveel-bits-heid van je OS En XP64 kan prima tot (ik meen) 128GB addresseren.

Heeft wel met de XP kernel te maken, omdat het een 32-bit kernel is...

Maar de TS heeft het obviously over de 32-bit versie omdat hij SP3 draait, en die's er niet voor XP64.

Anyway, als TS blifjt weigeren om code te posten kan ik niets doen om 'm te helpen.

[ Voor 23% gewijzigd door Snake op 29-01-2009 21:16 ]

[SKiLLa]

De code in de losse .exe werkt wel, maar vanuit VS niet ? Of is het dezelfde code in een ander project (b.v. een web-project) ?

En heb je gewoon niet iets aan je Database klasse veranderd, waardoor die niet meer goed serialiseerbaar is ?

PS: XP kan braaf gewoon 4 GB adresseren en gebruiken hoor; alleen is die adresruimte wegens legacy en backwards-compatibility redenen (oa. de standaard BIOS boot-modus) niet volledig "vrij" bruikbaar. Dat is eerder de schuld van IBM en Intel dan MS hoor ...

[ Voor 35% gewijzigd door SKiLLa op 29-01-2009 21:27 ]

[Phyxion]

Sebazzz schreef op donderdag 29 januari 2009 @ 19:10:
Korte probleembeschrijving:
Ik heb dit stukje code

C#:

                TextWriter w = new StreamWriter("database.xml", false, Encoding.UTF8);
                XmlSerializer s = new XmlSerializer(typeof(Database));
                s.Serialize(w, this.DB);
                w.Close();
                w.Dispose();

Dit werkt wel in een executable die ik gisteren heb gecompileerd, maar nu totaal niet meer. Hij blijft maar de fout geven dat bestand niet toegangelijk is omdat het door een ander proces wordt gebruikt. Oké, misschien zou dat zo zijn maar het probleem is dat het bestand pas op regel 1 hier aangemaakt wordt! Kortom, dat ie bij regel 3 crasht zou niet mogen kunnen omdat ie dezelfde stream gebruikt. Wie weet wat het probleem kan zijn?

Dit is wel heel frustrerend! Zelfs de disassembly is volgens Dis# hetzelfde.

Als je eens de append van de streamwriter op true zet, werkt ie dan wel?

[roy-t]

Sebazzz schreef op donderdag 29 januari 2009 @ 19:10:
Korte probleembeschrijving:
Ik heb dit stukje code

C#:

                TextWriter w = new StreamWriter("database.xml", false, Encoding.UTF8);
                XmlSerializer s = new XmlSerializer(typeof(Database));
                s.Serialize(w, this.DB);
                w.Close();
                w.Dispose();

Dit werkt wel in een executable die ik gisteren heb gecompileerd, maar nu totaal niet meer. Hij blijft maar de fout geven dat bestand niet toegangelijk is omdat het door een ander proces wordt gebruikt. Oké, misschien zou dat zo zijn maar het probleem is dat het bestand pas op regel 1 hier aangemaakt wordt! Kortom, dat ie bij regel 3 crasht zou niet mogen kunnen omdat ie dezelfde stream gebruikt. Wie weet wat het probleem kan zijn?

Dit is wel heel frustrerend! Zelfs de disassembly is volgens Dis# hetzelfde.

kleine opmerking over je code, je doet:

code:

TextWriter w = new StreamWriter...

Maak daar is van

code:

StreamWriter w = new StreamWriter

Ik denk niet dat je code daar op breekt, maar StreamWriter is blijkbaar een class die vanuit TextWriter inherit, dus die kun je sowieso in s.Serialize gooien als een TextWriter zonder dingen te hoeven boxen e.d. (Gaat vanzelf).

Maarja verder lijkt je code vrij normaal. Waar staat het database.xml bestand? Probeer eens een 'echt' pad als @"C:\database.xml"


@Snake's XP rant: waar the fuck heb je het over, totaal offtopic en onzinnig. (En XP kan juist precies 4GB aanspreken maar door video+geluidskaart geheugen + nog wat speciale dingtjes blijft er vaak tussen de 3.2 en 3.6GB over voor RAM)

[Niemand_Anders]

Kan de vhost.exe (debugger instance van vs) toevallig het bestand nog in gebruik hebben? Je kunt anders met FileMon (SysInternals) kijken welke process het bestand nog in gebruik heeft.

p.s. Overigens is het gebruik van de using statement netter dan handmatig Dispose aanroepen.

[Sebazzz]

Krijg nou wat. Nu werkt het allemaal weer
Wel even Visual Studio een repaire install gedaan. Toch mag dit niet zomaar gebeuren dat je IDE corrupt raakt. En vooral niet dat het vaag gaat doen. Vorige keer was het nog een beetje duidelijk, toen kreeg ik een EngineException.

De enige reden dat het misschien zou zijn is omdat ik net daarvoor records vanuit een SQLite database met dezelfde naam hebt geladen, de database gesloten en dat SQLite dan weer het filelock pakt, maar dat lijkt mij zéér sterk. Het database bestand was ook database.db maar voor de testcase had ik het ondertussen in de debugger naar een hardcoded database.xml veranderd om te kijken of dat veranderde. Niet dus.

roy-t schreef op vrijdag 30 januari 2009 @ 10:18:
[...]


kleine opmerking over je code, je doet:
(...)

Ik denk niet dat je code daar op breekt, maar StreamWriter is blijkbaar een class die vanuit TextWriter inherit, dus die kun je sowieso in s.Serialize gooien als een TextWriter zonder dingen te hoeven boxen e.d. (Gaat vanzelf).

Ja daar heb je gelijk in. Bedankt.

[dotcode]

Je file wordt gewoon gelocked, als je dit in de toekomst wilt voorkomen dan kan je het best using gebruiken als je een disposable resources gebruikt (zoals files).

Als je dan bijvoorbeeld met de debugger door je code heen loopt en je stop voor de close zal de file als nog worden geunlocked. Hierddor voorkom je vage lock problemen. Dit heeft overgens niets te maken met visual studio.


Zo iets:

code:

 using( TextWriter w = new StreamWriter("database.xml", false, Encoding.UTF8) )
{
                XmlSerializer s = new XmlSerializer(typeof(Database)); 
                s.Serialize(w, this.DB); 
                w.Close(); 
 }

[ Voor 31% gewijzigd door dotcode op 30-01-2009 10:50 ]

[Sebazzz]

dotcode schreef op vrijdag 30 januari 2009 @ 10:48:
Hierddor voorkom je vage lock problemen. Dit heeft overgens niets te maken met visual studio.

Ik heb het niet gemeld maar zowel met als zonder using statement heb ik problemen gehad daarmee. Bovendien zou een filelock niet mogen blijven bestaan tussen verschillende keren dat je applicatie draait. Als A.exe een lock op b.xml doet, en ik sluit A.exe af, verander wat code of draai hem opnieuw, zou b.xml niet gelocked mogen zijn door de vorige keer dat A.exe draaide. Door de breakpoints wist ik ook wel dat hij alleen bij die code kwam wanneer nodig. En dan verklaar jij op niet manier alsnog niet waardoor hij gisteren ineens vaag begon te doen en een repairinstallatie moest uitvoeren.

[.oisyn]

Snake schreef op donderdag 29 januari 2009 @ 21:12:
[...]

Heeft wel met de XP kernel te maken, omdat het een 32-bit kernel is...

Bullshit. Dat laatste stukje althans. De 32 bits Windows Server OS'en kunnen tot 64GB aanspreken (afhankelijk van de 'smaak'). De 4GB in XP en Vista is een softwarematige limiet, geen hardwarematige. De hardwarematige limiet is 64GB, en die bestaat al sinds de Pentium Pro.

klik

desktop versions of Windows (Windows XP, Windows Vista) limit physical address space to 4 GB for driver compatibility reasons.

[ Voor 18% gewijzigd door .oisyn op 30-01-2009 13:47 ]

[riezebosch]

Sebazzz schreef op vrijdag 30 januari 2009 @ 13:36:
[...]

Ik heb het niet gemeld maar zowel met als zonder using statement heb ik problemen gehad daarmee. Bovendien zou een filelock niet mogen blijven bestaan tussen verschillende keren dat je applicatie draait. Als A.exe een lock op b.xml doet, en ik sluit A.exe af, verander wat code of draai hem opnieuw, zou b.xml niet gelocked mogen zijn door de vorige keer dat A.exe draaide. Door de breakpoints wist ik ook wel dat hij alleen bij die code kwam wanneer nodig. En dan verklaar jij op niet manier alsnog niet waardoor hij gisteren ineens vaag begon te doen en een repairinstallatie moest uitvoeren.

Als je de applicatie tijdens debuggen afbreekt voordat de filelock vrijgegeven wordt kan het (volgens mij) zijn dat het vshost proces deze lock vasthoudt aangezien dit proces actief blijft terwijl je de debugger al gestopt hebt. Dan gaan usings ook niet helpen als de lock er nog op zit van een vorige debug-run zonder.

[whoami]

Niemand_Anders schreef op vrijdag 30 januari 2009 @ 10:20:
Kan de vhost.exe (debugger instance van vs) toevallig het bestand nog in gebruik hebben? Je kunt anders met FileMon (SysInternals) kijken welke process het bestand nog in gebruik heeft.

p.s. Overigens is het gebruik van de using statement netter dan handmatig Dispose aanroepen.

daar zat ik ook aan te denken, vandaar ook dat ik vroeg wat er gebeurd als de exe gestart wordt buiten de IDE.
Je kan ook eens proberen om vshost hosting uit te schakelen.