I have a VisualStudio 2010 solution containing a lot of C++ projects (above 100).
Many of them with some lines in the PostBuild Event (file copying and more).
The problem occurs when building the solution on our build machine using a tfs build definition:
Even if a project is up to date, the post build executes, and a line with "Creating ".unsuccessfulbuild" because "AlwaysCreate" was specified" is written to the log file. This increases the build time quite a lot and makes Continous Integration build difficult.
This PostBuild is not triggered when running from VisualStudio.
To narrow down the problem (and exclude any possible problem with reference to unexistent files and so on), I created a new solution file, and added a new C++ console application project to the solution using the VisualStudio project wizard. The only thing I changed from default was this line in the PostBuild event: echo "PostBuild Output" (just to see in the log file when the PostBuild was triggered).
Then I created a new Build Definition running this solution.
And still the PostBuild is activated even if the project is up to date. The same problem happens if I build the solution file running msbuild in a command window. But building from VisualStudio works perfect.
Can anyone give me some advice on how to avoid this PostBuild when the project is 'up to date'?
(I have checked that Linker OutputPath matches the $(TargetPath) setting when building on the build machine.)
Related
I have a solution that contains both C++ and C# projects that is built in a nightly CI build on a remote machine. The build script checks out a clean copy of the source and builds both debug and release configurations of the solution using MSBuild and runs the test suite on each configuration.
About every other build, the release configuration fails to build properly. An analysis of the build log reveals that C++ Project Q, which depends on C++ Project D, tries to link before Project D is done. This error only happens for the release configuration on this particular build machine - the debug configuration builds without error. I have a separate nightly build process that runs on a separate machine where the release configuration is built with a similar script that uses MSBuild (it just does not run the test suite), and it builds the same source revision without issue. Multiple team members build the solution without issue either from update or clean checkout with one or both configurations, always from the Visual Studio 2019 IDE, on various operating systems.
Project Q is configured with Project D as a project reference and Project D is also listed as a hard-dependency for Project Q. As I mentioned, the build script is using MSBuild.
An additional item of interest from analysis of the release and debug build logs: The build of Project D is initiated differently between the two configuration builds. It is started by its own metaproject in the release configuration (as item 60, for instance), but started earlier (as item 44, for instance), by a different project in the debug configuration. Not sure why the dependency algorithm would run with such different results in the two cases since the solution and working source being built are the same.
Any ideas or suggestions would be appreciated.
Update: Inspection of differences between the release and debug build logs reveals some interesting facts. In the failure case I did a search for ") is building" in each log - should be an indication of how many projects were built, including metaproj entries. For the failure case, debug had 282 occurrences, whereas release had 175. For the success case, debug had 280 occurrences and release had a whopping 559! A similar search for "Done Building Project" yields similar results, only off by 1 or 2. That might partly explain the differences in build order between the solutions. I also need to check for conditional build entries.
Visual Studio 2019 Reference Project Not Built Before Dependent
Project Tries To Link in Release Configuration using MSBuild
It seems that project buid order was broken and Project D built later than Project Q which need the output content of Project D, so the whole build failed.
Not sure that if you use Project Dependency(Right-click on project-->Build Dependencies-->Project Dependencies), if so, only VS IDE Build Will recognize their build order while MSBuild command line will lose the relationship about them.
Besides, I wonder if your main project under Release mode references a dependency project under Release mode. If you did these, the build will definitely go wrong.
All of these above is that I think you made some changes to your project.
You could follow these steps:
1) I suggest you could try to use Project Reference and it will add these xml node in ProjectQ.csproj file to strongly specify build relationship:
<ItemGroup>
<ProjectReference Include="..\ProjectD\ProjectD.csproj">
<Project>{26c26cdd-a5e0-40c7-b0c9-4563f969424f}</Project>
<Name>ProjectD</Name>
</ProjectReference>
</ItemGroup>
Also, check if there are any conditions that distinguish between Debug or Release mode when referring to a project like this:
<ProjectReference Include="..\ProjectD\ProjectD.csproj" Condition="'$(Configuration)'=='Debug'">
If so, please remove that condition Condition="'$(Configuration)'=='Debug'" to make sure it is the same between Debug and Release mode.
2) close VS Instance, delete .vs hidden folder under solution folder.
3) check your CI Build and cloud build server and ensure that cloud parameters are consistent with other servers. And examine any of your xxx.csproj files to check if you have any other operations which causes this bahavior.
In addition, if necessary, you can share your xxx.csproj file and the build script with us to troubleshoot it.
I have a solution in C:\full path here\VS2010\blender.sln
This solution contains many projects(around 100). When I compile them, they all work fine. I can run them without any problem, and (quite) everything works (there are some bugs).
One of the projects is ALL_BUILD, but it gives the same error if I try to debug INSTALL(another project). I'm compiling with RELWithDebInfo as configuration, and if I execute the program manually it works. It is outputted in C:\full path here\VS2010\bin\RelWithDebInfo
But if I try to run the compiler, it says
"Unable to start program
C:\full path here\VS2010\RelWithDebInfo\ALL_BUILD
Specified file cannot be found"
I tried to copy the compiled program into the path required by VS, but it raised the same error.
What should I do to solve this? Right now I set up cmake to generate also a mingw project and I compile it and debug it with gdb, but this is a really a slow and impractical workflow, and I would like to use the VS debugger.
I must say that if I compile with Debug as configuration, the program doesn't even start.
I'm using VS2010 Express on Win7 64bit
(This is a big open source program, so I don't know exactly whatever it does)
Guessing from the information I have, you're not actually compiling the program, but trying to run it. That is, ALL_BUILD is set as your startup project. (It should be in a bold font, unlike the other projects in your solution) If you then try to run/debug, you will get the error you describe, because there is simply nothing to run.
The project is most likely generated via CMAKE and included in your Visual Studio solution. Set any of the projects that do generate a .exe as the startup project (by right-clicking on the project and selecting "set as startup project") and you will most likely will be able to start those from within Visual Studio.
I had the same problem :)
Verify the "Source code" folder on the "Solution Explorer", if it doesn't contain any "source code" file then :
Right click on "Source code" > Add > Existing Item > Choose the file You want to build and run.
Good luck ;)
I think that what you have to check is:
if the target EXE is correctly configured in the project settings ("command", in the debugging tab). Since all individual projects run when you start debugging it's well possible that only the debugging target for the "ALL" solution is missing, check which project is currently active (you can also select the debugger target by changing the active project).
dependencies (DLLs) are also located at the target debugee directory or can be loaded (you can use the "depends.exe" tool for checking dependencies of an executable or DLL).
I know about this question (and answers), but despite trying all the suggested options I am still stuck.
I have a solution with multiple projects, but for this particular case let's say I've got my ExampleProjectA and a corresponding unit test project ExampleProjectATest. The first one is added as a reference to the test project - not via Visual Studio's "Project References" but as a link to the DLL (something like "..\Path\$(Config)\ExampleProjectA.dll") - this is due to build server requirements in our company, but the problem also existed when we still had "Project References".
Building and then running a single unit test works fine
Changing just a single letter in a unit test and then letting the test run always results in a rebuild of ExampleProjectA, even though this shouldn't be necessary
Setting all (there were only a few) files in ExampleProjectA from "Copy always" to "Copy if newer" in their respective properties didn't help
Checking the checkbox under Tools => Options => Projects and Solutions => Build an Run (see below) also didn't change anything
To see if there was any more information available, I changed the build output settings to diagnostic. Each time a rebuild of ExampleProjectA is triggered, the first line in the output windows is
1>Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
The class name written to the window (e.g. namegeneratortest.cs) changes according to which test file I change.
Not sure why this message comes up, but the next step was to disable the debugging information as shown below under Project properties => Build => Advanced => Output => Debug Info => None:
Still the same, nothing's changed.
Another thing I tried was to check the timestamps of the files contained in my solution folder (as there was a case where a user had a file with a future timestamp - see linked post) - to no avail.
Last thing I tried was to change the build settings in the Configuration Manager to a different target platform - some settings wouldn't let me build the solution successfully, some other settings did, but the problem described persisted, so no change.
The behaviour is similar (not the same though) with both the Visual Studio Test Runner and the one provided by ReSharper.
Visual Studio Test Runner
Project 'ExampleProject' is not up to date. Input file 'C:\tfs\mysolution-dev\exampleprojecta\Views\Shared\someview.cshtml' is modified after output file 'C:\tfs\mysolution-dev\exampleprojecta\bin\exampleprojecta.pdb'.
ReSharper Test Runner
Project 'ExampleProjectATest' is not up to date. Input file 'c:\tfs\mysolution-dev\exampleprojectatest\myfolder\namegeneratortest.cs' is modified after output file 'C:\tfs\mysolution-dev\exampleprojectatest\bin\Release\exampleprojectatest.pdb'.
I'm using Visual Studio 2013 Premium Edition with ReSharper 8.2 and the latest updates, the projects in our solution file are in C#.
Update
To clarify - the first line in the output window does show that the test project has to be rebuilt - this is fine. The following lines, however, indicate that also ExampleProjectA has to be rebuilt, which shouldn't be necessary. Subsequent messages to the output window also show that other projects (referenced from ExampleProjectA have to be rebuilt.
Update 2
Despite installing Update 4, nothing has changed.
For my case the solution was to change the build action of a config file from "Copy always" to "Copy if newer". It took a while to find as I had to change the build output details to get the details about which file was causing the error, e.g.
Project 'xyz' is not up to date. Project item 'c:\my\path\web.config.dev' has 'Copy to Output Directory' attribute set to 'Copy always'.
From my experience it can also happen that different file names are shown when building multiple times, so make sure you have the right one and / or build again if the problem persists.
Also have a look at this question and its answers to find some more information.
I have worked around this problem by deleting the .pdb file in the \obj folder. It seems that visual studio is checking file modification time to decide if it should build or not the project (in your case ExampleProjectA) and the .cshtml is newer than the pdb. But when launching the build, project changes in .cshtml files are not triggering the .pdb rebuild, so the problem remains.
By deleting the .pdb in \obj folder (not in \bin as the file there is copied from \obj and would keep the old modification time) the modification time for the .pdb is newer than the .cshtml and the VS doesn't need to build the project before running the tests. Of course this only works until the next time you modify a .cshtml file, that's why I qualify it as just a workaround.
Check what version of Visual Studio 2013 you are using. Update 1 has a pretty big issue where it rebuilds everything. See: https://connect.microsoft.com/VisualStudio/feedback/details/811112/unnecessary-solution-rebuild-on-each-test-run
Upgrading to Update 3 did the trick!
I'm not sure if Resharper could affect things as well. I suggest temporarily uninstalling it.
I'm a fairly experienced C# dev, but have very little C++ knowledge. I have set my self a project to get a custom Firefox build running, and be able to control it from C# code.
I have got so far as getting and building the Firefox source, and creating a Visual Studio solution for the exe. This means I can now run via F5 in Visual studio. If I open a source file, I can set break points and have them hit.
What I'm not sure how to do, is load the entire source, as if I were working with a C# .NET solution. As I understand it, there are no project files with the Firefox source, as it is not windows specific source. I have followed an online example that suggests creating using 'project from existing code' option in VS, which resulted in VS grinding to a halt as there were so many files.
What are the steps to getting the code into an environment (preferably Visual Studio) that makes it simple(ish) to edit, debug and navigate the source code.
Note: Instructions I have been working through so far are here: https://cs.senecac.on.ca/~david.humphrey/writing/debugging-firefox.html
From you question, I beleive you are almost there. You have a working build ? That means you have :
A Solution File (*.sln)
A Project file (*.vcxproj or *.vcproj depending on yoru visual studio version)
With that in hand, what works best for me is this layout (adapted to your needs) :
Starting from a root folder of you liking, say MyProject
Create a new Empty solution there
Move the folder with your working build in a subdirectory, like MyProject\MyCustomFirefox
In Visual Studio "Add an existing project" and find your vcxproj file
In the same solution, create a C# project like you always do, in a directory at the same level as your FF build, like MyProject\MyFirefoxController
In short the solution file is pretty much alone in the root directory, and each project is in its own directory.
You will also need to adjust build options so that the output files (a DLL or an EXE) is seen by your C# project. While your are at it, make the C# project dependent on your Firefox build : it will instruct the msbuild to rebuild one if you change the other.
This will not work with the Express edition, I beleive. They are single language.
If you have a command line build path, which is creating a VS-debuggable executable, you could try adding all the source files to the project, but marking them 'exclude from build'. Then add a 'post-build step' to call the command line tools.
You may have to do a little more tweaking in the project properties to get the command line output recognized as the output to debug, but theoretically this could work.
In Visual Studio (2008) is it possible to force the Post-Build Event for a C++ project to run even if the project is up-to-date?
Specifically, I have a project which builds a COM in-process server DLL. The project has a post-build step which runs "regsvr32.exe $(TargetPath)". This runs fine on a "Rebuild", but runs on a "Build" only if changes have been made to the project's source.
If I do a "Build" without making any changes, Visual Studio simply reports that the project is up-to-date and does nothing - the Post-Build Event is not run. Is there any way that I can force the Event to run in this situation? This is necessary since although the DLL itself is up-to-date, the registration information may not be.
You can use the Custom Build Step property page to set up a batch file to run. This runs if the File specified in the Outputs setting is not found, or is out-of-date. Simply specify some non-existent file there, and the custom build step will always run. It will run even if your project is up-to-date, since the Output file is never found.
Use this DisableFastUpToDateCheck
See an example:
<PropertyGroup>
<PostBuildEvent>IF EXIST C:\Projects\Copy_Files_To_Instance.ps1 ( powershell -file C:\Projects\Copy_Files_To_Instance.ps1)</PostBuildEvent>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
The registration information is determined largely by what's in the .rgs file. If that file changes the project will get built. I am not sure how else COM registration can change without making the project dirty. Do you mind providing more details about your particular situation?
In Visual Studio 2017 (perhaps other versions as well), for C# projects (haven't checked for C++ projects per OP's actual question) there is an option for "Run the post-build event:", and one option is "Always", which will run the Post-Build even if nothing has changed, rather than simply reporting that the project is up to date: