[VS200x] Rebuild leegt \bin map

[plofkip]

Beste Tweakers!

Vandaag ben ik echt een irritant probleem tegen gekomen.
Ik heb een Visual Studio solution (ASP.NET Web). Deze bevat in de \bin map een aantal *.XML bestanden voor intellisense bij de assemblies met diezelfde naam.
Ook staat hier de complete Ajax Control Toolkit in; dus de AjaxControlToolkit.dll en al die localization mapjes (ar\AjaxControlToolkit.resources.dll, cs\AjaxControlToolkit.resources.dll, de\AjaxControlToolkit.resources.dll enzovoorts).
Nu is het vervelende; als je een rebuild doet, wordt de hele \bin map leeg gegooid... Dus de XML bestanden worden weg gesmeten en de resources van de Ajax Control Toolkit ook.
Deze staan namelijk niet als reference van het project (dat kan niet).

Dit lijkt mij toch unwanted behavior?!
Weet iemand of hier iets tegen te doen is?

[Haan]

Deze staan namelijk niet als reference van het project (dat kan niet).

Hoezo niet?

Het is in ieder geval perfect normaal gedrag dat de inhoud van de bin map verwijderd wordt bij een rebuild. Het lijkt er meer op dat je niet helemaal op de goede manier bezig bent qua project-structuur. Kan je wat meer info geven over hoe het e.e.a. nu is ingericht in je project?

[Alex)]

Wat je moet doen is bij de files die je mee wilt nemen naar je output-directory, is bij de Properties de waarde "Copy to Output Directory" instellen op "Copy always".

[plofkip]

Alex) schreef op woensdag 07 juli 2010 @ 21:01:
Wat je moet doen is bij de files die je mee wilt nemen naar je output-directory, is bij de Properties de waarde "Copy to Output Directory" instellen op "Copy always".

Nope, werkt ook niet...

[Alex)]

Ik heb dat zojuist getest, en hier werkt het prima?

In mijn project heb ik de XML-file toegevoegd, en daarna verschijnt hij keurig in de output-map:

[ Voor 33% gewijzigd door Alex) op 07-07-2010 21:12 ]

[Gomez12]

@kipusoep : je snapt de tip toch wel?

Het voorkomt idd niet dat de bin map leeggegooid wordt, het zorgt er enkel voor dat zolang je die libs / xml's buiten je bin map opslaat dat ze elke keer na een rebuild wel in de bin-map staan.

[plofkip]

Alex) schreef op woensdag 07 juli 2010 @ 21:09:
Ik heb dat zojuist getest, en hier werkt het prima?

In mijn project heb ik de XML-file toegevoegd, en daarna verschijnt hij keurig in de output-map:
[afbeelding]

Ok, maar dan zou ik 'dependencies' wel in een map willen hebben, in plaats van dat ze in de root van de solution zweven, maar dan wordt er een map met diezelfde naam aangemaakt in \bin:

[FireDrunk]

Output path instellen? Kan je bij de opties van de file gewoon wijzigen...

[plofkip]

FireDrunk schreef op woensdag 07 juli 2010 @ 21:32:
Output path instellen? Kan je bij de opties van de file gewoon wijzigen...

Bij mijn versie van VS2010 niet:

[FireDrunk]

verander filename eens in dependencies\Examine.xml

[Sebazzz]

Kan je anders niet gewoon een post-build event doet die met robocopy source dest /MIR de boel kopieert?

[ Voor 5% gewijzigd door Sebazzz op 07-07-2010 21:53 ]

[plofkip]

FireDrunk schreef op woensdag 07 juli 2010 @ 21:52:
verander filename eens in dependencies\Examine.xml

Kan niet

Sebazzz schreef op woensdag 07 juli 2010 @ 21:53:
Kan je anders niet gewoon een post-build event doet die met robocopy source dest /MIR de boel kopieert?

Zou denk ik op zich wel kunnen ja, maar ik vraag me af of dat echt nodig is...

[ Voor 22% gewijzigd door plofkip op 07-07-2010 22:14 ]

[Gomez12]

kipusoep schreef op woensdag 07 juli 2010 @ 22:13:
[...]
Zou denk ik op zich wel kunnen ja, maar ik vraag me af of dat echt nodig is...

Wat wil je dan? Als het je enkel om een ja/nee antwoord op de vraag in je TS gaat, dan zou ik zeggen maak een extra user aan die eigenaar van die bestandjes wordt, maak je huidige build-user admin-af en geef deze alleen maar leesrechten op die bestandjes. Je breekt redelijk wat coding-guidelines en misschien dat je wat fout-meldingen krijgt bij het rebuilden, maar afaik zou het moeten werken.

Je wens gaat ongeveer tegen alle normale regels etc in. Dan kan je of je omgeving aanpassen naar normaal gedrag of je kan gewoon blijven vasthouden aan je eigen methodiek...

[plofkip]

Gomez12 schreef op woensdag 07 juli 2010 @ 22:58:
[...]

Wat wil je dan? Als het je enkel om een ja/nee antwoord op de vraag in je TS gaat, dan zou ik zeggen maak een extra user aan die eigenaar van die bestandjes wordt, maak je huidige build-user admin-af en geef deze alleen maar leesrechten op die bestandjes. Je breekt redelijk wat coding-guidelines en misschien dat je wat fout-meldingen krijgt bij het rebuilden, maar afaik zou het moeten werken.

Je wens gaat ongeveer tegen alle normale regels etc in. Dan kan je of je omgeving aanpassen naar normaal gedrag of je kan gewoon blijven vasthouden aan je eigen methodiek...

Maar hoe doen anderen dat dan?

En met dat bedoel ik:
Een externe assembly includen (reference) inclusief de documentatie XML? Met als voorwaarde dat deze .dll en .xml ergens in dezelfde map als de solution zitten (werkt vind ik makkelijker via SVN)

[Sebazzz]

Robocopy lijkt mij de makkelijkste optie. Die post-build events zijn er niet voor niets

Ik gebruik voor een game het ook. Ik heb een content map in me solution, en die mirror ik met robocopy. Bij een clean build duurt het een paar secondes maar anders is het hardstikke snel omdat ie alleen kopieert wat er veranderd is.

[ Voor 149% gewijzigd door Sebazzz op 07-07-2010 23:53 ]

[plofkip]

Sebazzz schreef op woensdag 07 juli 2010 @ 23:37:
Robocopy lijkt mij de makkelijkste optie. Die post-build events zijn er niet voor niets

Ik gebruik voor een game het ook. Ik heb een content map in me solution, en die mirror ik met robocopy. Bij een clean build duurt het een paar secondes maar anders is het hardstikke snel omdat ie alleen kopieert wat er veranderd is.

Ok, heb het opgelost met robocopy, alleen niet de post-build event, maar de pre-build event (anders bestaan de references nog niet tijdens het bouwen):

code:

robocopy "$(SolutionDir)references" "$(SolutionDir)bin" *.pdb *.dll *.exe *.config *.xml /XO /NJH /NP /S
if errorlevel 4 goto BuildEventFailed
if errorlevel 0 goto end
:BuildEventFailed echo FILECOPY for $(ProjectName) FAILED
exit 1
:end echo FILECOPY for $(ProjectName) COMPLETED OK
exit 0

[Janoz]

kipusoep schreef op woensdag 07 juli 2010 @ 23:05:
[...]

Maar hoe doen anderen dat dan?

En met dat bedoel ik:
Een externe assembly includen (reference) inclusief de documentatie XML? Met als voorwaarde dat deze .dll en .xml ergens in dezelfde map als de solution zitten (werkt vind ik makkelijker via SVN)

Euhm, zeg je hier nu dat je de bin map ook in SVN hebt staan ?

[plofkip]

Janoz schreef op donderdag 08 juli 2010 @ 11:22:
[...]


Euhm, zeg je hier nu dat je de bin map ook in SVN hebt staan ?

Ja, exclusief de dll en pdb van het project zelf (anders krijg je inderdaad conflicten).
Opzich is het nu niet meer nodig, aangezien alle references nu in een aparte map staan. Als die aan svn is toegevoegd is het al voldoende.

[Janoz]

De bin is je output directory. Daar gaan je targets heen. Alles in je bin zou afgeleid moeten zijn uit wat er verder in je project zit. Pas wanneer je echt een release gaat maken wordt het tijd om misschien eens te kijken of hetgeen in de bin directory ook ergens voor langere tijd opgeslagen zou moeten worden.

Je vroeg hoe anderen het deden? Nou, het is standaard om de bin directory NIET in je versie beheer op te nemen. Daaruit volgt vervolgens vanzelf dat het helemaal geen enkel probeelm hoeft te zijn dat die map leggegooit wordt (je wilt absoluut niet hebben dat een vervuilde build map invloed heeft op je deliverable).

[TheNameless]

kipusoep schreef op woensdag 07 juli 2010 @ 21:29:
[...]

Ok, maar dan zou ik 'dependencies' wel in een map willen hebben, in plaats van dat ze in de root van de solution zweven, maar dan wordt er een map met diezelfde naam aangemaakt in \bin:
[afbeelding]

Dit kan heel erg goed met een "Solution Folder".
Deze kan je creeren door rechts te klikken op je solution en dan Add => New Solution Folder.
Vervolgens klik je op die nieuw gecreerde folder en doe je Add => Existing Item(s).

Zo doe ik het altijd, al gebruik ik geen SVN als versie beheer maar TFS en daarmee werkt het perfect, zelfs de geautomatiseerde builds.

[plofkip]

Janoz schreef op donderdag 08 juli 2010 @ 13:05:
De bin is je output directory. Daar gaan je targets heen. Alles in je bin zou afgeleid moeten zijn uit wat er verder in je project zit. Pas wanneer je echt een release gaat maken wordt het tijd om misschien eens te kijken of hetgeen in de bin directory ook ergens voor langere tijd opgeslagen zou moeten worden.

Je vroeg hoe anderen het deden? Nou, het is standaard om de bin directory NIET in je versie beheer op te nemen. Daaruit volgt vervolgens vanzelf dat het helemaal geen enkel probeelm hoeft te zijn dat die map leggegooit wordt (je wilt absoluut niet hebben dat een vervuilde build map invloed heeft op je deliverable).

Done

TheNameless schreef op donderdag 08 juli 2010 @ 13:58:
[...]

Dit kan heel erg goed met een "Solution Folder".
Deze kan je creeren door rechts te klikken op je solution en dan Add => New Solution Folder.
Vervolgens klik je op die nieuw gecreerde folder en doe je Add => Existing Item(s).

Zo doe ik het altijd, al gebruik ik geen SVN als versie beheer maar TFS en daarmee werkt het perfect, zelfs de geautomatiseerde builds.

Alleen dan is er nog steeds geen mogelijkheid om deze naar de bin map te kopiëren bij een build, toch?

[TheNameless]

kipusoep schreef op donderdag 08 juli 2010 @ 16:54:
[...]

Done

[...]

Alleen dan is er nog steeds geen mogelijkheid om deze naar de bin map te kopiëren bij een build, toch?

Dat klopt
Naast de eerder genoemde pre/post build actions niet inderdaad.

[Haan]

kipusoep schreef op donderdag 08 juli 2010 @ 16:54:
[...]

Alleen dan is er nog steeds geen mogelijkheid om deze naar de bin map te kopiëren bij een build, toch?

Er is dan ook geen noodzaak voor. In de Bin map komt alle output van je build, ik zou niet weten wat je in die map met xml documentatie files zou moeten

[eek]

kipusoep schreef op woensdag 07 juli 2010 @ 20:02:
Nu is het vervelende; als je een rebuild doet, wordt de hele \bin map leeg gegooid... Dus de XML bestanden worden weg gesmeten en de resources van de Ajax Control Toolkit ook.
Deze staan namelijk niet als reference van het project (dat kan niet).

Waarom kan dat niet?

[plofkip]

eek schreef op donderdag 08 juli 2010 @ 18:59:
[...]


Waarom kan dat niet?

Je kan geen XML bestanden referencen (logisch) en de Ajax Control Toolkit resource assemblies hebben allemaal dezelfde naam/namespace

[eek]

Ik heb zelf de ajax control toolkit via een svn:external in mijn project staan. In die directory staat een .dll en een .xml. Als ik vanuit mij project daar een referentie naar toe leg wordt bij een compile zowel de .dll als .xml naar mijn bin directory gekopieerd. Dit gebeurt niet bij jou?

[plofkip]

eek schreef op donderdag 08 juli 2010 @ 22:45:
Ik heb zelf de ajax control toolkit via een svn:external in mijn project staan. In die directory staat een .dll en een .xml. Als ik vanuit mij project daar een referentie naar toe leg wordt bij een compile zowel de .dll als .xml naar mijn bin directory gekopieerd. Dit gebeurt niet bij jou?

Ja wel als ik die inderdaad in een externe map heb staan.
Alles is nu in orde, thanks allemaal voor de vele reacties!