[visual studio] commandline build bouwt anders dan normaal

[BasieP]

Beste mensen,

zoals te lezen in dit topic:
[visual studio]commandline publish doen

doe ik dmv een command line commando builden.
dit doe ik alsvolgt:
devenv.exe d:\path\to\solution.sln /rebuild "release"

Hierbij pakt hij de buildsettings van de solution, en bouwt hiermee op commandline je solution.
Echter, nu heb ik het probleem dat bij 1 van mijn solutions ik meer dll's krijg dan bij een normale build (Dus devenv opstarten, solution openen en build->rebuild all doen.
Een van de dll's die in /bin/release zou moeten komen te staan is er niet wanneer ik het via de commandline doe.
Dit is niet een directe reference van een project, maar een reference van een reference.

Nu is het voor mij vrij lastig om te testen of die dll echt gebruikt wordt door mijn applicatie. Maar buiten dat, weet iemand hoe het komt dat de twee manieren van builden verschillende resultaten leveren?

en misschien belangrijker: hoe los ik dit op?

[whoami]

Wat gebeurt er als je msbuild gebruikt om je solution te builden ?

[BasieP]

whoami schreef op vrijdag 30 januari 2009 @ 12:13:
Wat gebeurt er als je msbuild gebruikt om je solution te builden ?

dat heb ik nog niet gedaan ik ken msbuild niet. MSbuild werkt toch met eigen configs enzo? en bouwt alleen project files?

nu kan ik solutions bouwen, en dan wordt automatisch dezelfde configuratie meegenomen die ik normaal ook gebruik.

maar zelfs als het werkt, dan lost het mijn probleem niet op

[Niemand_Anders]

Visual Studio gebruikt zelf ook MSBuild. MSBuild gebruik de sln bestanden voor de build. Zie ook http://msdn.microsoft.com/en-us/library/z7f65y0d.aspx.

Daarnaast is MSBuild niet heel erg anders dan (N)ant en andere buildtools. Voor het gebruik van MSBuild verwijs ik naar de MSDN die daarover zeer veel informatie bevat.

[BasieP]

maar als visual studio ook msbuild gebruikt maakt dat dus geen klap uit voor mijn probleem of wel?

[Niemand_Anders]

Helaas toch wel. Waar het probleem precies zit durf ik niet te zeggen, maar op het moment dat je de sln gebruikt om je project te builden, genereert VS om de een of andere reden niet elke keer dezelfde build config.

Projecten waarvan geen bestanden zijn gewijzigd komen dan niet voor in de build config. Op het moment dat het project van je reference geen build nodig heeft (en dus geen onderdeel van de build is), wil VS nog wel eens 'vergeten' om de dependencies van dat project te kopiëren. Is het middels de commandline ook mogelijk om een 'clean build' commando te geven?

[BasieP]

ja, ik doe /rebuild (dat is clean en build)
Verder is het zo dat in Visual studio zelf ook niet de dependency hoef te bouwen. Die heb ik namelijk al gebouwd. Echter kopieert hij dan wel de dll's...

het 'gewijzigd zijn van bestanden' maakt dus mijns inziens niet uit, omdat dit gewoon niet zo is (in beide gevallen zijn er geen bestanden gewijzigd. Ik open de .sln file en build hem. in beide gevallen bestaat er nog geen /bin directory. De solution is dus 'clean'.

[roy-t]

BasieP schreef op vrijdag 30 januari 2009 @ 13:01:
[...]

dat heb ik nog niet gedaan ik ken msbuild niet. MSbuild werkt toch met eigen configs enzo? en bouwt alleen project files?

nu kan ik solutions bouwen, en dan wordt automatisch dezelfde configuratie meegenomen die ik normaal ook gebruik.

maar zelfs als het werkt, dan lost het mijn probleem niet op

Het kan juist wel je probleem oplossen, je ziet een verschil tussen het bouwen via VS en via de commandline, dit komt omdat VS bouwt via MSbuild en jij via de commandline. Om het net zo te krijgen als in VS moet je dus MSbuild via de commandline aanroepen .

[Niemand_Anders]

BassieP gebruikt MSBuild nu indirect van devenv. VS roept vanaf versie 2005 niet meer zelf de compiler aan, maar besteed deze taak uit aan MSBuild. Om te voorkomen dat alle developers eigen build scripts moeten schrijven, hebben ze de sln import task geschreven. Op het moment dat je met een prototype van een GUI client bezig bent heb je natuurlijk geen eigen build script nodig.

Omdat onze 'release' releases gesigned en ondertekend met AuthentiCode dienen te worden (anders accepteren banken de software niet) hebben wij een aangepast build script nodig. Developer en nightly builds zijn wel gesigned (met een dev key), maar niet ondertekend.

[roy-t]

hmm, ik wist niet dat devenv ook MSBuild gebruikte, misschien net op een andere manier, wat gebeurt er als je manueel MSbuild gebruikt, helpt dat?

[corné]

Ik dacht juist dat devenv aanroepen hetzelfde effect had als gewoon (re)builden vanuit de IDE?
Ik heb op me werk een cruisecontrol (automated build) server opgezet en ik gebruik daar ook devenv.com (deze geeft console output) ipv msbuild, omdat deze soms problemen gaf bij incremental builds.
Nu heb ik bij alle projecten precies dezelfde output als builden in de IDE zelf.

Heb je de console output van devenv al vergeleken met die in de IDE?

[Niemand_Anders]

Open in VS het 'output' scherm (ctrl + alt + O) en doe dan maar eens een build. Je ziet dan de output van MSBuild voorbij schieten. Althans dit is zo in VS versies Professional en VSTS Architect edition.

Ook bij options onder 'Projects and Solutions' en 'Build en Run' kun je aangeven hoe uitgebreid je de output wilt hebben.

Of deze output ook zichtbaar is als devenv wordt aangeroepen durf ik niet te zeggen.

[corné]

Als ik "devenv.com /rebuild project.sln" doe zie ik in de cmd echt letterlijk de output die ik anders in de output van visual studio (2008 standard edition) zie.

[Niemand_Anders]

Misschien dat de standard editions zonder MSBuild worden geleverd en dat deze nog een opgepoetste builder gebruikt uit de 2002/2003 versies? Ten tijde van VS2003 gebruikte wij nant omdat devenv toen ook een aantal irritante issues had.

BassieP gebruik jij toevallig ook de standard edition?

Ik lees nu net even in MSDN de command switches van devenv eens door, maar het voorbeeld daar gebruikt de buildconfig name voor de sln, terwijl BassieP hem in de openings topic hem erachter zet.

code:

devenv /rebuild Debug "C:\Documents and Settings\someuser\My Documents\Visual Studio\Projects\MySolution\MySolution.sln"

Het zou toch niet zo zijn dat dat van zulke vage probleme oplevert??

[BasieP]

Ik gebruik de TeamSystem editie, en daarvan is de output van een manual build hetzelfde als die van een commandline build.

Ik heb er inmiddels op msdn ook een thread over gestart.
http://social.msdn.micros...75-4cb6-82c7-914dd9ea7604

Daarvoor heb ik een testcase aangemaakt waarin een solution een leeg project bevat. Deze wordt door de commandline build niet meegenomen, maar door de 'manual' build wel.

beide zijn 'rebuild all' dingen, en de output ervan is dus tot op de letter hetzelfde.