You can't build inside Visual Studio because of MSBuild's incremental build mechanism that skips targets marked as already run. The real question here is how to break this incremental build. This question is very related.
Up vote 1 down vote favorite 1 share g+ share fb share tw.
I want to build 2 configurations at the same time of a project. Let's say that when I want to build the Release I want to build even the Debug (the opposite isn't true). Starting with Use a single Visual Studio solution to build both x86 and x64 at the same time?
I've tried adding to the . Csproj and if I try to build the project through MSBuild MSBuild ConsoleApplication64. Csproj /p:Configuration=Release /p:Platform=x86 it works correctly.
The two Configurations are built correctly and everything is good. The problem is if I try to build it with Visual Studio: the Release is built correctly, then it begins to build the Debug version and it gives me Copying file from "obj\x86\Debug\ConsoleApplication64. Exe" to "bin\Debug\ConsoleApplication64.
C:\WINDOWS\Microsoft. NET\Framework\v4.0.30319\Microsoft.Common. Targets(2868,9): error MSB3021: Unable to copy file "obj\x86\Debug\ConsoleApplication64.
Exe" to "bin\Debug\ConsoleApplication64. Exe". Could not find file 'obj\x86\Debug\ConsoleApplication64.
Exe'. Pre-conditions: Windows XP SP3 ITA, Visual Studio 2010 SP1 English, the project is an empty Console Application for C# 4.0 (technically it isn't, but I can reproduce the problem with that). (note that to have those messages I've activated the verbosity: normal from Tools->Options->Projects and Solutions->Build and Run->MSBuild project build output verbosity.
After comparing the output of the two "half" runs the difference is that in the "working" half the csc is called, in the other one it isn't: Release half: Task "Csc" (TaskId:13) c:\WINDOWS\Microsoft. NET\Framework\v4.0.30319\Csc. Exe /noconfig /nowarn:1701,1702 /nostdlib+ /platform:x86 /errorreport:prompt /warn:4 /define:TRACE /reference:"C:\Programmi\Reference Assemblies\Microsoft\Framework.
NETFramework\v4.0\Profile\Client\Microsoft.CSharp. Dll" /reference:"C:\Programmi\Reference Assemblies\Microsoft\Framework. NETFramework\v4.0\Profile\Client\mscorlib.
Dll" /reference:"C:\Programmi\Reference Assemblies\Microsoft\Framework. NETFramework\v4.0\Profile\Client\System.Core. Dll" /reference:"C:\Programmi\Reference Assemblies\Microsoft\Framework.
NETFramework\v4.0\Profile\Client\System. Dll" /debug:pdbonly /filealign:512 /optimize+ /out:obj\x86\Release\ConsoleApplication64. Exe /target:exe Program.
Cs Properties\AssemblyInfo. Cs "C:\Documents and Settings\m. Alberti-cons\Impostazioni locali\Temp.
NETFramework,Version=v4.0,Profile=Client. AssemblyAttributes. Cs" (TaskId:13) Done executing task "Csc".
(TaskId:13) Debug half: Task "Csc" (TaskId:41) Done executing task "Csc". (TaskId:41) After some more tests I've noticed that if the two halves use the same DefineConstants then there isn't any problem and everything works, but if they are different (as in Release/Debug) then it doesn't work. :-( visual-studio-2010 msbuild link|improve this question edited Feb 3 at 14:29 asked Feb 3 at 10:59xanatos14.5k11336 50% accept rate.
– Samselvaprabu Feb 3 at 12:10 @Samselvaprabu Then it works, but in truth it doesn't do anything. To be clear: Build Debug, Build Release (+ Debug): no error, but: Build Debug, add some lines of code (Console. WriteLine(" Build Release, the Debug version isn't rebuilt, but no error.
– xanatos Feb 3 at 12:18 whether your Visual studio has /p:Platform=x86 or it is anycpu? – Samselvaprabu Feb 3 at 12:22 @Samselvaprabu I'm using the stock Console Application, so it has the config for Debug and Release of x86 but not for anycpu. – xanatos Feb 3 at 12:25.
You can't build inside Visual Studio because of MSBuild's incremental build mechanism that skips targets marked as already run. The real question here is how to break this incremental build. This question is very related.
If you build with /verbosity=diag you will notice MSBuild reports a bunch of these: Target "AssignTargetPaths" skipped. Previously built successfully. Microsoft aware of this behavior and consider this by design.
A possible workaround, which I strongly advise against it, is invoking the second build using the Exec task. The Exec task is merely a command line shell which will eat everything you will feed it with, but in your case it can break the incremental build chain.
The Target "AssignTargetPaths" skipped. Previously built successfully. Is present in both halves of the diagnostic build.
I've even tried putting true in the three ProjectGroup (the generic one and the ones for Debug and Release) but it hasn't changed anything. – xanatos Feb 5 at 7:18 That was only an example. If you look closely you'll find a bunch of Previously built successfully and skipped, due to false condition.
Internally, VS decides when not to rebuild but that process can be hacked. This may give you a clue – KMoraz Feb 5 at 8:03.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.