VisualStudio 2008 exe problem

I have a VisualStudio Solution with 5 projects. I have 3/5 projects that has an .exe file on <mysolutionpath>/bin folder. Recently, I have added a new Project to my solution (a project with Main entry point) and I would its .exe file on <mysolutionpath/bin directory.

But I have exe on <mysolutionpath>/<recentproject>/bin and I don't know because happens this.

I'm a newbie of VisualStudio, could you help me?

EDIT: My VisualStudio solution has five "Windows Form Application" projects. When I compile my solution, I have this situation:

1) First.exe on /bin folder; 2) Second.exe on /bin folder; 3) Third project doesn't have a Main en开发者_JS百科try point; 4) Fourth.exe on /bin folder; 5) Fifth project doesn't have a Main entry point.

Now, I would add a new project to my solution then I do right click on my solution->Add->Windows Form Application, and new project (e.g. with name "TEST" with Main Entry point) is added to my solution. But when I ricompile the entire solution I expect to get TEST.exe on /bin folder but I have TEST.exe on /TEST/bin/TEST.exe and not on /bin/TEST.exe as happens with previously five projects. I hope that I explained well this time.

---

Assuming that your project is for an executable and not something else, such as a class library, then you will find the executable file in the output directory set within the project settings. If its not an executable project then you wont get a .exe output (for a class library expect .dll).

By default VS places executables from Debug and Release builds into separate directories, so you may want to look there as well.

---

VS is placing all projects in one output by default, if they are all binded by reference. If your next executable should be referenced by main - just do this, and it will appear in main output. If its not a choice, you could add (or change) .targets file. In my project I had such content:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
    <ClientPublishDirectory>$(SolutionDir)output\</ClientPublishDirectory>
    <PluginPublishDirectory>$(SolutionDir)output\</PluginPublishDirectory>
</PropertyGroup>
<Target Name="CopyOutputFiles">
    <CreateItem Include="$(OutputPath)\**\*.*;">
      <Output TaskParameter="Include" ItemName="OutputFiles" />
    </CreateItem>
    <Copy SourceFiles="@(OutputFiles)" DestinationFolder="$(ClientPublishDirectory)%(OutputFiles.RecursiveDir)" ContinueOnError="false" />
</Target>
<Target Name="CopyPluginsOutputFiles">
    <CreateItem Include="$(OutputPath)\**\*.*;">
    <Output TaskParameter="Include" ItemName="PluginsFiles" />
    </CreateItem>
    <Copy SourceFiles="@(PluginsFiles)" DestinationFolder="$(PluginPublishDirectory)%(PluginsFiles.RecursiveDir)" ContinueOnError="false" />
</Target>
<Target Name="Copy3rdParties">
    <CreateItem Include="$(SolutionDir)\..\libs\*.dll">
    <Output TaskParameter="Include" ItemName="OutputFiles" />
    </CreateItem>
    <Copy SourceFiles="@(OutputFiles)" DestinationFolder="$(ClientPublishDirectory)%(OutputFiles.RecursiveDir)" ContinueOnError="false" /> </Target> </Project>

---

In the project settings, under Build, there is an Output path: setting. I usually do this for multi-project-interdependent solutions:

1. Make a new solution file in a directory above all the project directories.
2. Make a bin directory in the same directory as the solution.
3. Now open the solution file and add all the projects.
4. For each project, go to the Build section in the project settings.
5. For Release mode, set the Output path: to ..\bin\Release
6. For Debug mode, set the Output path: to ..\bin\Debug
7. Now for each project, remove existing references to other DLLs in your solution and instead add a reference to the corresponding project.

This approach removes the need for **Build Event* scripts that tend to clutter up the Output window during the build. Using Project references will make Visual Studio copy the compiled DLLs to the proper folder and will also ensure that the projects are recompiled before you start debugging after any code changes. This approach usually guarantees that you will be using the right version of the binary and symbol files during debugging.