We Keep Coding

visual studio generates executable from C# but where are the obj files?

I have Visual Studio Express 2010 installed, and have used it for a C# project.
Now I am writing a .gitignore file so I can exclude from git the object files that I expect to be generated.
I come from a C++ world mainly.
Trouble is, despite the fact that the target is being generated correctly I cant see any object files (with .obj or .o extension)anywhere in the directory tree of the solution.
Could this be caused by the configuration where they are being sent elsewhere?

To answer your direct question: C# doesn't have a compile step that produces .obj files like C and C++ do.
However, a .gitignore that's appropriate for C# projects is a well-solved problem. Visual Studio will ask you if you want to add the .gitignore to your new git repository when you create it. If you already have a repository, you can just use the community's .gitignore for Visual Studio which is excellent (and what Visual Studio would install for you.)

There aren't any .obj files generated during compilation, but there is an obj directory under the project root that's used to store temporary files. This is the directory that should be in your .gitignore file.

How can tests reference external resources in a parent source directory in a TFS 2012 build?

I'm setting up a TFS 2012 build agent and have run into a small problem with unit tests that reference external files. (Yes, yes, this is bad...no arguments there! I still have to get a build running) The tests are using the MSTest (VisualStudio.TestTools.UnitTesting) framework.
Currently, there is a Resources folder under the solution root, and all the tests (which are unfortunately at varying depths in subdirectories) load files with some level of relative paths (..\\..\\..\\Resources\\resource.txt).
TFS, as you know, copies all output to a bin folder that is at the same level as src, which has the required Resources folder. There is no way to copy this folder high up enough in the directory structure so the tests pass for the build agent.
I am hoping that either of these questions can give me a stop-gap solution to this problem:
Is there any environment variable (or something similar) that I could use to detect that the unit test is being run through a TFS build agent and change the path to the resource file in code accordingly?
Is there a simple way to tell TFS to output files into the bin folder with the same hierarchy as they would have normally been if built in Visual Studio? (The reason I say simple is because I've found some rather long build modifications that could probably handle this)

Option1: Yes, you can copy a folder and it's contents to the \bin\Debug folder:
Add a folder to your test project
Add your files in that folder and in Visual Studio set each file property "Copy to Output Directory" : "Copy Always"
Option 2: You can also put your file into a resource file
Option 3: or declare the file it in your test using the attribute:
[TestMethod]
[DeploymentItem("mytestdata.xml")]

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)

C# why empty src folders are copied to the debug and release directory after build?

We are using Visual Studio 2008 professional. We have created an entity data model in our src\systeminfo folder. Since then our release and debug folder have a empty src\systeminfo folder. we don't need them. how to stop VS to create that empty folder structure? thanks
EDIT:
current directory tree:
project\Properties
project\References
project\src
project\src\common
.
.
project\src\systeminfo
project\src\util
project\App.config
project\Settings.cs

You'd have to dig through the msbuild .target files to find out what build rule creates this folder. You might get a hint from looking at the build log if you switch it to diagnostic. Tools + Options, Project and Solutions, Build and Run.
A more pragmatic approach would be to just delete the folders in a post build event. Like:
if exist "$(TargetDir)src\systeminfo" rmdir "$(TargetDir)src\systeminfo"
if exist "$(TargetDir)src" rmdir "$(TargetDir)src"
Even more pragmatic is to not worry about it...

There is an option to 'Copy to Output Directory' on the properties window.
Set it to 'Do not copy' for these folders

Wrongly created output folders with Visual Studio 2008

I have a solution with many projects. There is actually a Core project and a few plugins. I changed OutputPath for all plugins so all binaries end up in the Core bin\debug folder. (this is necessary as the Core do not have a reference on plugins, hence it does not "include" plugins binaries when it is compiled.)
So basically my folder structure is as follow:
Solution
MySolution.sln
Plugin1\
Plugin2\
Core\bin\debug
Each plugin OutputPath is "..\Core\bin\debug". When I open the solution Visual Studio creates a folder "Core\bin\debug" in Solution's folder parent as if the relative path starts from .sln file. However when I build the solution the binaries are output to the correct path ("Solution\Core\bin\debug").
Core\bin\debug
It looks like a Visual Studio bug to me, but maybe I overlooked some option somewhere. Any ideas how to resolve this problem ?
PS: I know this not a critical issue as everything build and works fine, however I dislike the idea of meaningless folder hanging around

Rather than changing the output location of the plug-ins, what you could do is create a post-build script (Properties \ Build Events tab) for them that will copy the them to the Core folder. That would prevent the confusion with output folders.
This command line should do the trick for you:
copy "$(TargetPath)" "$(SolutionDir)Core\$(OutDir)"
If you need to copy .pdb and .config files as well, you can add more lines:
copy "$(TargetPath).pdb" "$(SolutionDir)Core\$(OutDir)"
copy "$(TargetPath).config" "$(SolutionDir)Core\$(OutDir)"
If you really want to do it with a single line, this should also work, though it's not as clean:
copy "$(TargetPath)*" "$(SolutionDir)Core\$(OutDir)"
If you're not using the same output path in both the main project and the add-ons, you'll need to replace $(OutDir) with a hard-coded value. If you have them set to target the typical "\bin\Debug" folder (or have just left the defaults in place), then you can get away with using the $(OutDir) value.

Instead of using "..\Core\bin\debug", use "$(SolutionDir)\Core\bin\debug".