Problem: You’ve created a Windows service and it installs fine with installutil.exe, however when you create a Setup Project (in Visual Studio 2010) and set the primary output to the Windows service project, the installer runs successfully, but yours service doesn’t appear in the services list.
Solution: After googling a bit, it turns out you need to add two custom actions to your setup project, one for Install and one for Uninstall, which simply link to the primary output. Here’s what you should have:
After that, rebuild your setup, run and your service should appear.
Ideally, the 'Clean' command on a Visual Studio solution should remove all build artifacts, to ensure that the next build you do will be as if the code had just been retrieved from source control. However, if some projects in your solution generate artifacts (e.g. files) other than that which the compiler produces, these files will not be removed during a 'clean' or 'rebuild' of the solution.
However, there is a way to hook the clean process to peform some extra steps. In my case, I needed to delete all files under a folder 'Entities\Generated' under my project. This can be done by editing the .csproj file and adding something like the following:
<Output TaskParameter="Include" ItemName="TheFiles"/>
<Message Text="TheFiles: @(TheFiles)" />
This is MSBuild syntax, which I think is horrible. The **\*.* somehow means 'all files in all sub-directories'. I stay away from MSBuild as much as possible. You can also hook the BeforeClean and other events, as listed here.
For C++ projects, you are a bit more limited, however you can modify the 'Extensions to Delete on Clean' property (Project Properties->General) to have something like ";$(ProjectDir)Entities\Generated\*.*". This restriction here is that you cannot have '..' in the path (i.e. traverse upwards) or you'll get this build error:
error : Search pattern cannot contain ".." to move up directories and can be contained only internally in file/directory names, as in "a..b".
If you need to traverse upwards, you could consider using a different macro, such as $(SolutionDir), or alternatively, you could add a 'pre-build event' that does the necessary cleanup (and the same goes for C# projects).