I wish I could provide a better description, but this is hard to describe succinctly.
Let me start with some background. This is a C++ solution using Visual Studio 2019 Community Edition. It has 12 projects of different types (DLLs, static libraries, and executable tests) and 4 build configurations ((Release, Debug)x(Win32, x64)). Keeping all the properties the same across projects and configurations has been a massive pain, so I decided to try using property sheets so that I could have the properties shared across projects. Given the structure of my solution, the property sheets are themselves somewhat complicated, but it's an improvement over what I had.
However about halfway through this migration I noticed some odd behavior. When I inspect the properties for one of my projects (a static library), the properties page is almost totally empty. Not only the properties I have changed with my sheets are missing, but even the default properties that you would expect.
However when I build this project, I can tell that most of the custom properties are in fact set correctly despite being missing, so it would seem like a UI bug, except some properties are not set correctly, for example the build log is not written to the correct location despite being set in the property sheet. This makes me worried that other more important properties may not be set correctly as well, but it's hard to know which properties are getting set and which are not.
I have another static library project that is set up in the same way with the same property sheets, and it behaves normally. It shows the expected properties in the project properties, and the build log is even in the correct location.
It gets even stranger. When I run the build from the command line using msbuild or devenv, the build log is written to the correct location. This suggests that building from the command line is working correctly, and that building from Visual Studio is not the same as building from the command line.
I ran msbuild -pp to see the expanded project file, and it looks correct. I diffed this project file with another static library from my solution that is working normally, and the diff is as expected, only the project names, paths, and source files are different. I did this diff on the expanded projects files too and they were the same except the expected differences.
I have closed and reopened Visual Studio countless times. I have also unloaded and reloaded the project. I have even tried deleting the .vs folder. None of these had any affect.
Here is a link to my code.
Screenshots demonstrating what I mean.
Is there any way to fix this? Have I done something wrong? I would like all of the properties from my property sheets to show up in the project properties, and I especially need all of them to apply when building the project.
Moving the <ItemGroup>s containing the source files below the <ImportGroup>s in my project file (.vcxproj) fixed the problem. I cannot explain why this works, or why this was ever a problem in the first place, but it fixed it.
I created a project, lets say named AddonLib, which is part of a big solution. For some unknown reason, the folder where the source code was put was named AddonLib_1. I've been trying to get rid of that "_1" for too long now and is driving me crazy. Things I've tried:
removed the project, from TFS and the solution. Renamed the directory. When I try to add the project again, I get the message "The project file "blabla\AddonLib_1\AddonLib.vcxproj" has been moved, renamed or is not on your computer".
Edited the xml file of the solution. Check the project file just to be sure. Removed any trace of the project with and without _1. The project AddonLib is no longer part of the solution. Try to add it back again, same error as before.
Cleared the VS cache following the instructions here. Repeated previous step. Same error.
I cannot find any reference to AddonLib_1 on my code, xml files, anything. But everytime I try to load the project, I get the same error.
Looking for the string "AddonLib_1" using findstr gives no results...
This causes the build to break. Even if there are no references (that I can find) to AddonLib_1, when building in the server I get an error "project AddonLib_1/AddonLib.vcxproj could not be found blablabla"....
Besides the solution xml file, the project xml file, the xml files of the few projects that depend on this project, where else can the information that once the project was in the directory AddonLib_1 ?
More info:
I can remove the project. Remove it from TFS, from the solution, and delete the directory. Create a new project with the desired name. Add the source and header files. Now, I need to add some info to the project xml file. If I open the xml file and edit, when I try to load back the project (Which was loaded before!) I get the same error message. If I open the xml again, undo the minor change I did, I still get the error. Again, this is in a new project, starting from zero.
I was able to solve this issue by removing the .suo file as described in this apparently unrelated answer
I am looking at using MSBUILD from a command line to run the schema compare (*.scmp)
Within the solution we have several databases and the team aren't always that great at remembering to check changes (stor procs, tables etc..) into the solution. Although Visual studio can show the comparison, I can't find a way of exporting the list of errors, for me to chase the team about. Screen shots seem to be the only way.
I thought That I would see if there were any tools in order to produce a list of differences. I came across an example on the following:
http://blogs.msdn.com/b/ssdt/archive/2014/07/15/msbuild-support-for-schema-compare-is-available.aspx
I saw this example:
C:\SampleProject > msbuild /t:SqlSchemaCompare /p:SqlScmpFilePath="d:\sc.scmp" /p:target="d:\target.dacpac" /p:TextOutput="d:\1.out" /p:Deploy="true
However I can't get it to work. When I run the equivalent against my particular set up I get:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets(843,5): SchemaCompare error : The tar
get participant is invalid or empty. at Microsoft.Data.Tools.Schema.Tasks.Sql.SqlSchemaCompareTask.Execute() [C:\TFS\Argon_Main Solution_Latest R
elease\Source\Blah\SomeData.DataDatabase.sqlproj]
Has anyone got any ideas?
Cheers
I ran across this issue the other day. Turns out the problem was i needed to use the VisualStudioVersion command line argument.
msbuild /t:SqlSchemaCompare /p:VisualStudioVersion=14.0 /p:SqlScmpFilePath="MySchemaCompare.scmp" /p:target="MyConnectionString" /p:TextOutput="..\output.out"
Your Microsoft.Data.Tools.Schema.SqlTasks.targets file should be located at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\{Your VS Version}\SSDT
I realize it's been a while since this was asked, but I'll answer anyway.
Firstly, it's unclear to me what you're trying to compare exactly. Do you want to compare two versions of the project to see the differences, or are you comparing a project to a database?
One thing I noticed is that you're specifying the target twice in the command line. Firstly, the .scmp file referenced via the SqlScmpFilePath parameter contains a source and target. Secondly, the target parameter also defines a target. The target parameter will override whatever is in the .scmp file.
Maybe this is intentional, though, if your .scmp file has the right source but you want to specify the target in the .dacpac file.
The .dacpac file can be found in the bin\Debug or bin\Release folder of your SSDT project after a build. For your command to work, you'll need to make sure "d:\target.dacpac" exists and is such a file.
The .scmp file is created by doing a Schema Compare in Visual Studio and then saving the comparison window after selecting the source and target. For your command to work, you'll need to make sure that "d:\sc.scmp" exists and is such a file.
Please let me know if this helps.
I have a Visual Studio project with about 60 C++ source files. I can do a build, and it completes without errors. But if I immediately hit F7 again, it always re-compiles about 50 of the source files. It doesn't re-compile all of the files, which is strange.
I have 'Enable minimal rebuild' (/Gm) set. Any ideas why it might be doing this?
None of the files have a Modified Date in the future.
Are any of your file dates in the future? This can occur if you changed time zones or changed the system clock time. Dates in the future will confuse the IDE and force a rebuild every time F7 or F5 is hit.
I've solved the same problem.
In my case compiler displayed warning, that /Zi option is required if /Gm is specified.
/Gm enables "minimum rebuild", which requires debug information in .pdb file. So, if you don't want to use .pdb, also disable minumum rebuild - it solved a problem in my case.
Most probably is a matter of dependencies.
Consider the following possibilities:
If you have custom build tools defined for some of the files in your solution, make sure that the output property contains the right file name(s). If the output of the build tool doesn't correspond to the one(s) specified in the output file names, the builder will rebuild that file.
If you have custom build events, check whether the output from those build events don't affect the dependencies of the files to be built.
I had problems when trying, at post-build, to copy or move some of the output files to a build folder. The post build operations that affect the timestamp of the ouput files of the build process will determine rebuild each time.
In my case of such effect (C++ via VS2005) it was on Release configuration only, and the Studio tells in the build output, that compiler option /Gm is ignored if /Zi - option is not set. After setting /Zi via
Configuration Properties -> C/C++ -> General -> Debug Information Format : Program Database (/Zi) ,
it was ok. But isn`t there something wrong, when the Release Configuration needs something about Debugging? Not yet clear to me!
Project Properties -> "C/C++" -> "Output Files" -> "Program Database File Name" option should not be empty. Set this option by selecting from drop-down box . The option will be set like this: $(IntDir)\vc90.pdb. And line ProgramDataBaseFileName="" will be removed from vcproj file.
Then only changed *.cpp files will be recompiled when you build the project or solution.
It seems that this problem can be caused by many things, but what fixed it for me was:
Closing Visual Studio
Manually deleting all bin and obj folders (Clean doesn't seem to do the trick)
Opening the solution and running Clean (I'm not sure if this is necessary, but I did it just in case...)
Building like normal
Note: This was for a C# program in Visual Studio 2010.
After a couple days of googling, I ended up with a solution to my problem.
I encountered this problem when I moved my projects to a new PC. I had checked several times the creation date of the files. These dates were up-to-date, however the modification dates were in the bast (kinda bizarre) even when I changed the files.
A simple update of the files resolved the problem.
I'm having the same problem, and it seems to be because I've turned browse information off. Properties->C/C++->Browse Info->Enable Browse Info->None. The only fix I've found is turning it back on. This is for an xbox 360 project, fwiw, my other projects don't have the problem.
A reason is if the 'date last modified' for one of the source file is set for some date in the future: it rebuilds, and then the source file is still later than the executable.
This problem with the dates can happen if the source file is located in a directory a remote machine (a network share), and/or may even happen if your machine's time isn't synchronised with the date of the machine which is running the server of your source version control system.
Check your project includes any .h header file that doesn't exist on disk. Always happens to me when I delete a header file I'm not actually including anywhere, but forget to delete it from my solution navigator in VS. Note: missing headers produce no errors during the build (when not #included anywhere).
Check your project's Program Database Filename setting. For some reason, if this is set to the name of a directory (such as "$(IntDir)\"), it can sometimes cause VS to rebuild your project every time, even if you're not generating PDB files (i.e. Debug Information Format is set to "Disabled").
This is a bug in VS2008; I have not yet reproduced it yet in VS2010, but my tests haven't been thorough, so I'm not confident saying that the behavior isn't present in VS2010.
What caused similar symptoms at me was:
I have several projects in a solution. There were .cpp files which were referenced (and therefore compiled) by >1 projects. Unfortunately Visual Studio creates .obj files with a very simple naming - it just replaces ".cpp" by ".obj". Creating wrapper .cpp-s with different named solved the problem.
I had something similar. Even though I did have pre and post build events, they weren't causing the issue. It turned out that I had a number of projects down the reference chain that had content files that were marked as "copy always" instead of "copy if newer" meaning that these projects were always considered "out of date". By changing all of these to "copy if newer", changes to my unit test project no longer forced a recompile of all of the other projects.
Disabling "minimal rebuild" (Configuration Properties > C/C++ > Code Generation) fixed it for me. The compiler even left a clue:
1>cl : Command line warning D9007 : '/Gm' requires '/Zi or /ZI'; option ignored
Although I must point out, the compiler did not ignore the option as it said.
In my case I changed system data time to previous date so it is rebuilding every time because of different time stamp of the files once changed to the current time its not rebuilding every time.
We have that here regularly:
delete all intermediate and output files by hand. The clean option in vstudio is sometimes not enough. From a fresh start do the complete build. If after a complete build vstudio still wants to recompile certain files it might be related to next bullet.
if in your vcxproj a header file is referenced which is not on disk, the project is also recompiled. You might check this by some hidden feature described on MSDN blogs or just touch (i.e. click on it to open) all header files in the project exploder and see if one does not exist on disk
Had the same problem. Solved by:
-delete output folder (obj,exe,all files)
-run cygwin
-cd project folder
-run "touch *", which reset file modify date/time
-build and enjoy problem fixed
There is similar issue with project rebuild.
Visual Studio does not recompile but re-links a project every time on F7 hit.
Fix is simple. Try to open in Editor all files included into project (from Solution Explorer double click on each file) and remove from solution those files which do not exist.
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.