[c#] "could not copy temporary files to output directory"

[mOrPhie]

Ik heb een c# solution met 4 projecten. Project 1 vormt het hart van de andere 3 projecten. Dat project is dan ook gerefereerd in de andere 3 projecten. In 1 van de 3 projecten gebruik ik een ManifestResource. Om die reden moet ik daarom soms dit project apart Rebuilden, echter gaat dit fout. Hij geeft de volgende fout op het Project 1.

"could not copy temporary files to output directory"

Volgens onderstaande kan dit komen omdat CopyLocal op true gezet moet worden. Dit is echter bij mij het geval. Het klopt dus gewoon. Op de 1 of andere manier lijkt VS.NET de output van Project 1 dus "Locked" te houden. Restarten van Visual studio, restarten van de computer, restarten van IIS, het heeft allemaal niet geholpen. Alleen als ik dus de bin-directory leeg (terwijl visual studio uit staat), dan werkt het weer. Het heeft een hele tijd goed gewerkt, en na het inpassen van een nieuwe klasse is het fout gegaan:

http://msdn.microsoft.com...ilestooutputdirectory.asp

Heeft iemand dit probleem ook 'ns gehad en weet diegene ook hoe ik dit moet oplossen? Tnx.

[ Voor 104% gewijzigd door mOrPhie op 26-11-2002 16:31 ]

[Verwijderd]

Komt me inderdaad bekend voor . Ik had dit altijd wanneer ik meerdere projecten naar dezelfde directory laat builden. Ik loste dit geloof ik altijd op door de reference opnieuw aan te maken oid.

[Verwijderd]

Komt ook mij bekend voor . Meestal helpt een rebuild all. Anders moet je idd de output directory leeg maken.

[mOrPhie]

Verwijderd schreef op 26 November 2002 @ 20:15:
Komt me inderdaad bekend voor . Ik had dit altijd wanneer ik meerdere projecten naar dezelfde directory laat builden. Ik loste dit geloof ik altijd op door de reference opnieuw aan te maken oid.

Da's inderdaad wat ik doe. Doordat ik CopyLocal van de referentie naar mijn Hart-project (1e project) op true zet, komen ze in dezelfde bin-dir terecht. Ik zal de referentie 'ns opnieuw aanmaken idd, dat had ik idd nog niet geprobeerd

Verwijderd schreef op 26 november 2002 @ 20:58:
Komt ook mij bekend voor . Meestal helpt een rebuild all. Anders moet je idd de output directory leeg maken.

Nou een rebuild werkt hiero dus sowieso niet omdat ie voor elk project (of het gerefereerde, of het 1e project zelf) die lock krijgt. Het steeds leeghalen van de output/bin-dir is IMO _geen_ oplossing. Het is gewoon een vette bug in visual studio.NET dus

Ik probeer de referentie nog opnieuw aan te maken, m'n gevoel zegt dat dat gaat werken

[Verwijderd]

domme vraag wellicht maarre... wat IS je project? Is het een windows service? Zo ja: dan is de file locked omdat de executable draait. Ik krijg deze error alleen als ik een winform wil builden en ik ben de instance vergeten af te sluiten die ik had opgestart na de vorige build.

[mOrPhie]

Neej het is geen windows-service, anders had ik dat zelf ook nog wel kunnen bedenken
Het is een ASP.NET webapplication. Althans, 1 van de 4 projecten binnen die solution. De andere 3 zijn mijn functionele classes onderverdeeld.

[mOrPhie]

Nou, het is opgelost. Thank god, want ik stond al met mijn monitor voor het raam om hem eruit te gooien

Maar goed, hoe opgelost:
Het 1e project (wat dus door allen wordt gerefereerd) heb ik gewoon naar z'n eigen output directory laten compilen. Aangezien de andere 3 projecten tóch een "CopyLocal" doen, kan ik dit dus gewoon doen. Waar het dus op leek is dat ie een dubbele actie wilde doen: Compilen naar de gezamelijke output directory, en de 3 andere projecten die em van die directory naar dezelfde directory willen "CopyLocal"-en. Dit heb ik nu dus opgelost...

* mOrPhie is blij

[Verwijderd]

ooooooooh! Je had de output dir van de libs laten verwijzen naar de output dir van het 1e project? Ja duh . Je moet die projecten atomair behandelen, en die references vanuit andere projecten zo definieren dat dmv copy local je de dll lokaal in je bin dir van je moederproject krijgt. Anders copieert ie de dll terwijl hij die net heeft gebuild. Watniet wil

[mOrPhie]

Verwijderd schreef op 27 november 2002 @ 12:04:
ooooooooh! Je had de output dir van de libs laten verwijzen naar de output dir van het 1e project? Ja duh .

ja eeh, niks "Ja duh" dus
Het heeft een hele tijd gewerkt, tot ik een nieuwe klasse inpaste. Dus zo "duh" is het niet. Het is wel logischer natuurlijk, maar dan had vs.net hier wel met een mooiere melding mogen komen

Je moet die projecten atomair behandelen, en die references vanuit andere projecten zo definieren dat dmv copy local je de dll lokaal in je bin dir van je moederproject krijgt. Anders copieert ie de dll terwijl hij die net heeft gebuild. Watniet wil

Je kopieerd een bestand naar jezelf. En dat gaat idd niet. Maar toch blijf ik het raar vinden dat hij het een hele tijd goed heeft gedaan. Affin, het is nu helemaal duidelijk

[Verwijderd]

Nog een workaround die bij mij werkt: killen van het asp worker process:
Task Manager, Processes tab, Image Name = aspnet_wp.exe -> End Process
_{want heel soms krijg ik deze foutmelding ook op een volstrekt willekeurig moment...}

[mOrPhie]

Verwijderd schreef op 27 November 2002 @ 14:38:
Nog een workaround die bij mij werkt: killen van het asp worker process:
Task Manager, Processes tab, Image Name = aspnet_wp.exe -> End Process
_{want heel soms krijg ik deze foutmelding ook op een volstrekt willekeurig moment...}

Hmm, da's ook niet echt elegant te noemen. Doet me denken aan de DLL-hell dat we steeds de dllhost.exe moesten killen bij het maken van een dll voor een ASP-pagina.

Ik denk dat jij de oorzaak ook 'ns moet gaan zoeken, check maar de link die ik in mijn begin-post geplaatst heb. Je moet het uiteindelijk zelf weten naturlijk, maar ik zou niet steeds die worker-process willen killen

[Verwijderd]

mOrPhie schreef op 27 november 2002 @ 16:35:
[1] Doet me denken aan de DLL-hell dat we steeds de dllhost.exe moesten killen bij het maken van een dll voor een ASP-pagina.

[2] Je moet het uiteindelijk zelf weten naturlijk, maar ik zou niet steeds die worker-process willen killen

[1] Daar deed 't mij idd in 't begin ook ff aan denken, maar 't vervelende is/was dat 't steeds een andere oorzaak heeft (gehad)/had...

[2] 't komt nu ook niet zo heel vaak meer voor, maar soms lijkt 't wel of bij het afsluiten van VS.Net of van een webpagina oid de asp worker process toch nog stiekum dll'tjes blijft vasthouden, net zoals idd dllhost 'vroeger' deed.

Wat nu ook soms nog wel gebeurt, is dat 't asp worker process bijv. nog de verbinding met de database blijft vasthouden... dan wil je je database droppen oid en dat kan dan niet... In dat geval wil een iisreset soms ook nog wel helpen, maar 't blijven vaagheden...

/me vindt desalnietemin .Net een hele vooruitgang vergeleken met de dllh*ll

[mOrPhie]

Verwijderd schreef op 27 november 2002 @ 17:28:
[...]

--knip knip--

/me vindt desalnietemin .Net een hele vooruitgang vergeleken met de dllh*ll

Daar twijfel ik ook zeker niet aan. Alle hulde naar .NET hoor

[Scare360]

Wat dacht je van je virtuele dir unloaden *tip*. Indien je COM+ gebruikt even VS.NET een batch build laten doen of ff VS.NET afsluiten en de bin folder leegpleuren.

Zorg ook dat je je dependencies goed ingesteld hebt.

ps: onder batch build zit een clean opdracht