We Keep Coding

How to do exe file no root directory?

By default, build path \debug\x86\ with:
db (folder)
log (folder)
*.exe
*.pdb
*.config
I want to move *.exe (pdb and config) to my folder bin (\debug\x86\bin)
I do the next post build script
ROBOCOPY "$(TargetDir) " "$(TargetDir)bin\ " *.exe *.config *.pdb /IS /MOVE
But when I run the application is crash (or start by Visual Studio)
The project contains other folders. So I want to put the files in different folders.
I want this structure
db (folder)
log (folder)
bin (folder)

About why VS threw that error message and you can't start the program
in VS:
For C# projects in VS, it has default Output path, like what Larry suggested above, when we try to simply start or start with debugging the program, VS will call the output xx.exe according to TargetDir. Since you use a post-build-event to move the output xx.exe from $(TargetDir) to $(TargetDir)bin, every time when VS try to start the program, it won't find program since it's actually not in $(TargetDir) path.
Note: The $(OutputPath) and $(TargetDir) refer to the same path when building by msbuild.
I want to move *.exe (pdb and config) to my folder bin
(\debug\x86\bin)
It's not recommended behavior for C# projects in VS. I assume you may have log and db folders in your current project, if the files in them are set as Content build action and CopyAlways or CopyIfNever, then no matter what output path you set, the output structure is like this:
There's no need to create a new bin folder at current path and move the *.exe, *.pdb, *.config into it. It will affect the normal debug behavior in VS, also it may cause unknown error if the xx.exe depend on the database in db folder. (After changing path, the xx.exe may try to search it in wrong path)
Not sure what VS version you use, you can check this issue. Msbuild is the build engine in VS, and vs use it to build C# projects. You can find its path in your machine and check its typical structure:
--Msbuild.exe
|
--necessary files
|
--referenced assemblies
|
--other folders
In summary, using the post-build script will call the crash cause VS won't find the xx.exe. And there is no valid way to get the structure you want, cause the original structure is expected behavior of VS for C# projects. So maybe we can just let it in normal situation it should be.
Update:
If now I want to publish the program. Of course now I build the program in release mode. The output structure is:
RootDir(name:xxx) ---xx.exe
---xx.config
---log folder
---log file
---text folder
---txt file
---db folder
---db file
For your requirement, why not just create a new bin folder and put the xx.exe, xx.config into it. Then rename the Root folder's name, change it manually to this:
ProgramName ---bin folder
---xx.exe
---xx.config
---other referenced assemblies
---log folder
---log file
---text folder
---txt file
---db folder
---db file
All you need to note is make sure you program can find the required files like this. Since you may depend on those files by code, a simple sample is using path in this format: #"..\text\test.txt", the .. means the above directory. So if you use statement like #"..\db\database file", your program can find the necessary files.
But note this way will affect the noraml debug behavior, so please leave all in normal structure when you're debugging. And use the special structure when you try to release it.

Instead of using ROBOCOPY, change the actual build location of your project.
Go to Project -> Properties -> Build and change the output path to /Debug/x86/bin.
This should then debug properly.
VS Docs on Output Path

Visual Studio 2010 Manage Output Files

I'm new about code developing with Visual Studio 2010 and I would like to ask you a simple question about something after build a project.
I have a C# project and when I build It in Release mode some file are created and some of them copied from another in to \output\bin\Release\ folder. My question is that How can I manage that which created dll or created file will be in \output\bin\Release\ folder.
I tried to take a look at build properties of project but I could not find any option about it.
Thank you.

Actually I do not need this dll in my project output folder because I
add this dlls as a reference to my project
And this is exactly why this file appear in output folder.
There are several ways to "put" file in output folder. For normal files in the project you can set property Copy to Output Directory.
If we talking about dll's, (as mentioned Hans), there is Copy Local property for each assembly in References.
By default VS set this according to our GAC, so if you are using 3rd part assembly or from another project VS will set this property to True and file will be copied to output folder.
If you don't want to put this file in output folder, just set this property to False. But remember, at run time this assembly should exist.
For more information: How to: Set the Copy Local Property of a Reference
Another explanation: you just messed up with Output path in the project properties and two project has the same output folder. :)

I suggest that you ignore the extra files that are created. One way to do this is to configure the destination of these to a different location.
I use this:
property pages->General
- Output Directory = $(SolutionDir)..\link\
- Intermediate Directory = c:\temp\vc10\$(SolutionName)\$(Configuration)\
Use the same settings for debug and release.

Alternative ways for changing paths when using MSBuild

I want to build my solution file using MSBuild but there is one issue. My MSBuild file is located at C:\WINDOWS\Microsoft.NET\Framework\v3.5\. So now only if I have my entire solution and projects files in this path am I able to compile the solution. But I cant keep having all my solution and project files in C:\WINDOWS\Microsoft.NET\Framework\v3.5\. The location of my solution files maybe at any location in my pc or in TFS, and I'll have to use MSBuild to compile it.
I saw in some forum that I'll have to change the path in regedit in the location
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5, but then it still remains static. If I want to execute a solution file which is in TFS then I'll have to again change the path in regedit.
Is there any alternative to this?

The msbuild.exe is there on my system, too. That is perfectly fine, as it's the task of VS or build tools to handle that. Normally you would either run a build script with C:\WINDOWS\Microsoft.NET\Framework\v3.5\ in the path environment, or your build solution knows where to find it. Usually, the msbuild.exe has to be changed only when you retarget to a different framework version (say 4.0). For building on a clean machine, the prerequisites should be set up correctly. So there should be no need to include msbuild.exe in your repository. Probably this would be considered bad practice. Do you have any reason, why you want to have the msbuild.exe versioned?

Can I disable the generation of obj in the same directory for _every_ project I have?

I'm tidying my projects. And I found the way to remove the object folder with adding:
%TEMP%
In my projects. But I want somehow to make this global setting or to auto delete my obj dirs after a build. Is there a way to do that?

I personally like having a specific Output folder in my project where I put all the compiled files.
I have the following command line in the Post-build events.
copy "$(TargetPath)" "$(SolutionDir)\Output\$(TargetFileName)"
This will copy the compiled file to the Output directory inside the Solution. You would need to add this to all the projects in your solution.
If you have any dependencies that also needs to be copied you could add something like this as well.
copy "$(ProjectDir)Dependencies\Language.xml" "$(SolutionDir)\Output\Extensions\Language.xml"
[EDIT]
You can try the following to have the file copied first, and then once that is done delete the object folder.
copy "$(TargetPath)" "$(SolutionDir)\Output\$(TargetFileName)"
rd /s /q "$(ProjectDir)\obj"
[EDIT2] Updated with screenshots to illustrate. :)
This is how my object folder normally would look like after compiling the project.
This is how it looks after compiling it with the above command. As you can see the folder is re-created after the event by Visual Studio, but the folder is empty.
You might want to double check that you are running Visual Studio with elevated permissions. To do so, simply right click on the Visual Studio and choose "Run as Administrator".

Are you using source control?
This comment sounds like you don't:
While archiving, those are unneeded megabytes.
("Archiving" sounds a bit like copying the whole project folder regularly to something like backup_yyyymmdd)
If you're not using source control, you should definitively consider starting to use it.
Apart from the general advantages (like, having a change history with dates and comments...), it has an out-of-the-box solution for your problem with the obj folders:
Every good source control software out there supports ignoring certain files or folders which you can define (ignoring means: they can never be committed to the source repository, you don't even see them in the list of changed files, not even when they were changed).
For example, in Mercurial (which I use) the ignore settings are saved in a file named .hgignore in the main folder (Git has the same, it's just called .gitignore).
My default .hgignore file for all Visual Studio projects looks like this:
syntax: glob
bin
obj
*.suo
*.user
The first line belongs to Mercurial's ignore syntax, the rest are the settings what to ignore.
You can see that the bin and obj folders are ignored...and they are ignored no matter in which subfolder they are!
So I don't have to care about where the obj folders actually are, and I don't have to delete them manually every time I build my solution. They are simply non-existent in my source control history.
Plus, I have a variation of Fuji's answer about putting everything in one single output folder:
I like to do this as well, but I prefer changing the output folders in Visual Studio's project settings instead of using post-build events.
The default output folders are:
bin\Debug\
bin\Release\
I change them to:
..\build\Debug\
..\build\Release\
This compiles everything into subfolders of a build folder which is at the same level like the .sln file (which means: all projects in the solution directly compile into the same folder).
It also reduces compile time because Visual Studio won't have to copy all the dependencies after compiling (because everything already is in the same folder).
(I do it mainly because of the compile time, because I ignore the bin and obj folders anyway in Mercurial as described above, so I don't care where they actually are)

Visual Studio 2008 - Moving files at build to bin/

EDIT: This is a VS2008 app written in C#.
So I have a folder in my solution called
_lib/
It's where I keep my DLLs so that when I reference them, they get built into the bin/ folder.
Now I have a new item in my solution. It's a DLL but shouldn't be reference (it's required for a 3rd party app). So on build I want this to be copied from _lib/ to bin/ but NOT referenced in the project.
I've included the _lib/ folder in my app, and for the properties of that DLL I selected always copy. This ALMOST worked, it copies the file with the folder, so my structure looks like:
/bin/_lib/thedll.dll
Instead of
/bin/thedll.dll
Any ideas?

Try following these steps in Visual Studio:
Expand the project tree concerned
Double click the Properties element
In the opened window click the Build Events tab
In the Post-build event command line text area place this:
xcopy "$(ProjectDir)_lib\file.ext" "$(ProjectDir)bin\$(ConfigurationName)"
Open the expected output folder alongside Visual Studio
Hit CTRL+Shift+B to make sure everything is saved and build
Feel the sense of achievement well up inside you as your file appears
:)
Oh, and you can now set Copy to output directory to Do not copy.