VS2010 debug is anders dan project en release build

[mad_max234]

Ik zit zins vrijdag avond met probleemje dat de debug niet meer veranderd als ik aanpassing aanbreng. Heb dit al eens eerder gehad, leeghalen van debugmap verhielp het probleem. Maar dit keer lijkt het een andere probleem te zijn.

Ik vermoed dat programma dus zijn files uit andere map haalt maar heb alles nagekeken. En na het leeghalen van de debug map als ik dan debug dan word de debug map gewoon opnieuw gevuld met de bestanden en exe file, maar exe bevat de veranderingen niet.

Als ik build uitvoer en in de release map kijk dan klopt het wel, dan zijn de aanpassingen wel aangepast.

Enige wat ik heb aangepast is backup(kopie) gemaakt van de map, verder niks bewust aangepast.

Heb aantal oplossingen gevonden.
1. Meerdere projecten. (niet het geval, in solution staat maar 1 project)
2. configuration manager (kan niet vinden)
3. Working directory aangepast (geen effect)
4. Solution settings nagelopen (Zover ik kan zien niks vreemds, had er ook niks aan veranderd)

Heeft iemand dit ook wel eens, is erg vervelend. Zeker als je niet gelijk door heb dat je debug niet mee veranderd met de code die je hebt aangepast, je zoekt je rot naar fouten in de code die gewoon juist is.

[eBoR]

om welke files gaat het dan ?

de exe file is dus een oudere versie van je programma ?
al eens een clean solution gedaan ed ?

[ Voor 64% gewijzigd door eBoR op 21-10-2012 12:06 ]

[leuk_he]

Mik ook de release en backup weg ( rename), en kijk dan eens of het helemaal build.

Kijk ook eens naar de volleidge log wat hij aan het doen is.

[mad_max234]

Als ik de exe verwijder uit debug map met alle andere files, daarna opnieuw debug dan krijg ik in de debug exe die niet overeenkomt met project. Het is waarschijnlijk een oudere versie. Stel in verplaatst een textbox in het project dan is die verandering niet van kracht in debug exe maar wel in de release exe.

Waar vind ik clean solution in VS2010? Kan die optie niet vinden.

[eBoR]

als je een breakpoint zet op een regel. word die dan wel rood ?

[eBoR]

Bij Build --> clean solution

[mad_max234]

Geen clean bij build menu, alleen build, rebuild en publish.

Ik gebruik overigens C# WPF, wellicht handig om erbij te vermelden, wellicht is de interface en optie iets anders.

Ga zo(klein uurtje) even breakpoint testen, moet even snel bootschapje doen.

[Haan]

Kijk ook eens even in de build configuration, (Build -> Configuration manager) of je build settings wel goed staan.

[mad_max234]

Neem aan dat je build menu bedoeld in menubalk bovenin? Daar staat geen Configuration manager.

https://dl.dropbox.com/u/69089896/foto/screen1.jpg

Edit/
Mijn project bevind zich overiges buiten de standaard project map in mijn documenten, misschien dat dat nog van belang is.

[ Voor 30% gewijzigd door mad_max234 op 21-10-2012 13:10 ]

[mad_max234]

Het lijkt opgelost, heb map obj renamed(na alle andere tips geprobeerd te hebben) en nu doet die het wel weer.

Had al ergens iets geleze dat mensen die hier ook last van hadden de optie cpu van x86 naar any cpu veranderen en weer terug dat debug het dan weer deed, nu kan ik die optie ook al nergens vinden, maar in obj map zit dus de x86 map en daar zitten ook nog hoop bestanden in, door die te verwijderen heeft VS waarschijn;ijk alles opnieuwe aangemaakt en nu werkt het wel weer.

Weet dus nog steeds niet de oorzaak, alleen de oplossing.

Edit/
Sorry voor dubbelpost, moet beter opletten.

En het is echt opgelost, heb aantal zaken aangepast en debug programma laat nu wel weer netjes de veranderingen zien.

[ Voor 14% gewijzigd door mad_max234 op 21-10-2012 13:41 ]

[MSalters]

Als je de Debug versie in de IDE start, dan staat er in het output window welke modules er allemaal geladen worden, inclusief de gebruikte paden. Dat is de simpelste check om te zien of je debugged wat je wil debuggen

[mad_max234]

Bedankt voor de tip, is soms behoorlijk zoeken in VS alle trucjes zijn dus welkom.

Even voor de duidelijkheid, obj map verwijderen was de oplossing. Pads waren allemaal juist, had ook verder niks veranderd, maar dacht misschien door het kopieren van de mapen dat er iets fout was gegaan.

Heb dit probleem overigens ook wel eens met avrstudio, dat hex file niet meer geupdate word na compileren met nieuwe aanpassingen in de source file. Moet dan ook mappen verwijderen. Schijnbaar iets raars wat in het framework zit van studio.

[RobertMe]

Als het bij C# hetzelfde is als C en C++ (wat ik wel aanneem) compiled elke cs file naar een corresponderende object file (in de obj map). Al deze lossen object files worden dan samengevoegd naar een dll, exe, whatever. De object file zal waarschijnlijk ook alleen opnieuw gemaakt worden als een van de cs files veranderd is. Waarschijnlijk had VS dus niet door dat de cs files veranderd waren (ten opzichte van de object files), waardoor hij alleen een nieuwe exe deed maken op basis van de nog steeds oude object files.

Tip: als je gaat verwijderen, altijd bin & obj verwijderen (/renamen). Dan weet je ook zeker dat alles opnieuw moet. Bij een groot project zul je ook merken dat er geen verschil in compile tijd is tussen gewoon compilen en compilen na het verwijderen van bin, verwijder je bin en obj zal het een stuk langer duren. Omdat die tussenliggende object files weer gemaakt moeten worden.