I have been upgrading a project and since the latest version of Visual Studio 2019 was installed have found the following file being output to disk
MyProjectName.GeneratedMSBuildEditorConfig.editorconfig
I think that this is related to the roslyn compiler and was introduced in this commit: https://github.com/dotnet/roslyn/commit/de348c5a77977459a4138de0a62487e00980e28a#diff-e87b4990385fcfea8cf3f744bb8ad23e
The obvious questions have arisen as to what this file is, what it does and whether it should be in source control or excluded. I know what .editorconfig files are for but this one was unexpected. My searching has turned up nothing. Can anyone shed any light on this?
Update: This is fixed in Visual Studio 16.9 and higher.
There is a bug when using legacy/non SDK-style projects, which causes these files to be output to the wrong location. We have a fix out for this here: https://github.com/dotnet/roslyn/pull/48781
In the interim as a workaround you can set the generated file output path explicitly by adding the following to your project file
<PropertyGroup>
<GeneratedMSBuildEditorConfigFile>$(IntermediateOutputPath)\$(MSBuildProjectName).GeneratedMSBuildEditorConfig.editorconfig</GeneratedMSBuildEditorConfigFile>
</PropertyGroup>
The right pull request is this one -- it's built as a way for some MSBuild logic to pass values to certain Roslyn analyzers. This is internal implementation detail and shouldn't be checked in to source control.
I'm surprised you noticed this file though -- it should be generated into your obj\ directory, which you should already have excluded from source control and never really noticed in the first place. Did it get generated somewhere else?
Related
Been working in C++ using Git (via SourceTree) for version control.
My .cpp files will randomly become seemingly corrupted when I pull the project as shown below:
Github still has the correct version of the file and even selecting the 'Open After' option in SourceTree shows me the file unaffected:
The fact that Git and Github both have no problem showing me the file suggests to me it's a Visual Studio issue but I don't know.
One thing to also note is that SourceTree can't seem to display some of my .cpp files, and just treats them like binary files (but I'm not sure if this is related or not):
It's not a massive issue since I can just copy the code from Github, but it happens almost every time I pull so it's rather annoying. Any help solving this would be massively appreciated.
No solution but things that you could check:
what is the version of git? Old versions <2.0 on Windows had a bug like that. Upgrade to the last versions that are quite good
verify that your files are encoded in utf8
that git don't touch you files when committing ('autocrlf' at false)
We are currently evaluating the new Visual Studio 2015 and encountered a strange problem with IntelliSense. When I compiled our main solution with the new studio the build succeeds, but nevertheless 6 errors are shown.
I discovered that it's not a real error, but only an intellisense error. The code is definitely correct and everything compiled successfully. The code however is marked red and errors show up in the error list.
All 6 errors have the same origin. It's a simple constructor call. Strange enough, but there are also some occurrences of the exact same constructor without any errors.
The error message:
Code: CS1729
Message: '<the class>' does not contain a constructor that takes that many arguments.
Project: <the project name>
File: <the path to the file>
The new studio was installed on a freshly installed Windows 7 without any legacy software (no VS13).
I've already tried to clear the caches, deleted the suo file, deleted bin and obj directories, cleaned and rebuilt the solution etc. But nothing worked.
Can anyone explain that behavior to me?
I had thousands of intellisense errors and 0 build errors. After deleting .suo file and restarting VS intellisense errors are gone.
Suo file is located relatively to source in:
.vs\SolutionName\v14\.suo
According to comment: Beware that *.suo is a hidden file.
Edit: According to comments, VS2017 has the same issue, so you can use similar solution: Delete .vs\SolutionName\v15\.suo
VS2019 still has this issue. Delete .vs\SolutionName\v17\.suo
If deleting .suo still does solve your problem, then delete also all bin and obj directories in every project in the solution.
Also had this problem with a migrated project, so I referenced the Microsoft.CSharp dll. In some projects I needed to remove and add again the Reference in the project.
Ran into similar issue in Visual Studio 2017 ASP.Net Core Project. Following steps did the trick for me
Perform Clean Solution
Close VS
Delete .suo file & Delete bin/obj directories
Reopen VS
Similar problem as others, but different resolution. Posting in case I can help someone else.
Running Visual Studio 2017 15.5.2. I use Git and frequently switch branches. Several weeks ago, I started having editors show me errors (all related to types it could not find even though references were valid). Compile worked great. I confirmed the same issue in VS 2017 15.6 Preview (Jan 6, 2018). I would try to delete cache, SUO files, or bin/obj folders and no impact. At first it would appear to work. Reopen Visual Studio and everything would look good. Use "Rebuild Solution" and the IntelliSense errors would returns. I even tried uninstall/reinstall of Visual Studio.
I had the same issue on two machines, both with same version of Visual Studio.
By looking at the errors about missing types, they all appeared to come from two referenced projects. One of those references was a shared project used by just about every other project in the solution, but one of them was a small project without many references. It just so happens that the small project was also referenced by my larger shared project. In Visual Studio, I unloaded the small project and reloaded it. The errors went away! They errors did not come back on Rebuild Solution.
I then switched Git branches and the errors all came back. Fortunately I repeated the above steps of unloading/reloading the small project and the errors went away.
Every time I switch Git branches, the errors come back until I repeat that process. There are zero changes between the Git branches for the smaller project that I unload/reload. Unclear why that sequence is fixing my issue.
Also had this problem (the title, not the specific error message), as well as squiggly lines in the editor. The first squiggly line is under the first #include statement, which names a precompiled header. Intellisense fails to include the precompiled header, but doesn't list that as an error; instead it lists errors further down the file, on code that (very rightfully) relies on declarations in the precompiled header.
The reason Intellisense doesn't find the precompiled header in my environment is that the header named is not an actual file. It doesn't have to be in any other VC or gcc version I used, nor in the 2015 compiler, as long as the precompiled header settings are correctly configured. Apparently not any more for Intellisense. I'm not entirely sure it was different in 2013, maybe I just never noticed.
In the unlikely case that this would be the problem reported here, the solution is simple: create a small file with the pretend-name of the precompiled header, as specified in #include directives, and let that file include the actual name of the precompiled header.
If you wonder... why this distinction between the precompiled header name in the '#include' statement and the actual filename of the precompiled header? Precisely because it guarantees that precompiled header settings are correctly configured. Wherever a precompiled header is "#included", there is no file around that could be included. Either an actually precompiled (binary) version of the actual header is read, or the compilation fails. Obviously, a disadvantage is that it confuses people reading the code, not just Intellisense.
Visual Studio 2017
I have deleted ".suo" file from location .vs\SolutionName\v15.suo
And then restarted Visual studio. This worked for me.
Today I've had similar problem with MSVC++ 2015. I almost gave up and decided to go on without IDE hints, but suddenly I've noticed that stdafx.h of the project i had problems with doesn't contain any standard library headers. I've speculated that inclusion of all standard headers used in the project in stdafx.h might boost up compilation speed, however doing so fixed Intellisense errors as well.
In Visual Studio 2019 the problem is with changing branches with Git when there are NuGet packages installed in the project. What I did to solve this:
Clean Solution
Close Visual Studio
Delete the packages folder
Open Visual Studio
Go to Package Manager
Restore all packages
Recompile
If roslyn is missing, close and open Visual Studio, then recompile.
I had multiple stdfax.h in Additional Include Directories. Make sure the stdafx.h you intended is first in your path.
I had a similar issue with different Visual Studio versions.
Deleting the .suo or .vs folder did not help for me.
The Solution for me was, that I had the Extension StopOnFirstBuildError active. After turning off "Stop build on first error" in the build menu, and after the solution was fully built, the errors shown by Intellisense went away.
I was seeing the intellisearch errors only when publishing a website. (ASP/C# site, VS 2017). They broke the publish. Site ran fine locally.
Cleared the errors by unchecking the setting to pre-compile, and it published fine.
Publish -> Setting -> File Publish Options -> Precompile during publishing
I had this issue with a reference to another project. Removing and re-adding the project reference worked for me.
When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).
Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.
I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)
This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).
The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General
Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.
The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.
I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.
this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.
this worked for me:
clean project
debug/delete all breakpoints :)
This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'
I've changed the file name and it works now.
Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)
My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration
It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it
I've downloaded the WSF-CPP 2.1.0 source, and set the vcvars to x86_amd64 (using VS 2008/9.0) but I'm running into problems:
I had to disable the /WX compiler option in wsf_c/axis2c/build/win32/makefile to get anything to even try building, since the Axis2/C code is rife with warnings.
Now I'm running into issues where multiple Axis2/C source files are trying to include nonexistent files, such as httpd.h, http_core.h, etc. (the specific offenders are in wsf_c/axis2c/src/core/transport/http/server/apache2).
Number 1 could just be a bad idea by whoever wrote the makefile and therefore something to ignore. But Number 2 seems to indicate a bigger problem than some missing headers, mainly because I'm able to compile the Axis2/c library as downloaded from the Apache web site without issue, but the code is identical (including the #includes of nonexistent headers). Does anyone know what could cause this difference?
Here, specifically, is how I'm trying to set the 64-bit environment variables up. All I did was replace this line in build.bat and wsf_c/build.bat:
#call vcvars32.bat /nologo
with
#call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64
Did I do this wrong? Did I mess up something else?
Also, this is my first question ever asked on StackOverflow. With respect to that, I'd appreciate any critiques about format, content, tone, appropriateness, etc.
My first recommendation to any miserable individual trying to use the no-longer-supported, out-of-date WSO2 WSF/CPP/C or Axis2/C is to use a different library if at all possible. If you refuse to take this advice, continue reading.
Finally got it to build correctly through trial and error. Here's what it took:
As stated in my question I had to disable the /WX compiler option in wsf_c/axis2c/build/win32/makefile to get prevent the build from failing right away due to all the warnings in the Axis2/C code.
Also as stated in my question I had to change the line at the top of build.bat (either build.bat or wsf_c/build.bat works, since they run in the same console, and you only need to set the environment variables once per console session). I changed the line from
#call vcvars32.bat /nologo
to
#call "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat" x86_amd64
This sets up the compiler to build everything in a 64-bit configuration.
In wsf_c/build.bat I had to change the Axis2/C build command on (or near) line 11 from
nmake dist AUTOCONF=..\..\..\configure.in
to
nmake install AUTOCONF=..\..\..\configure.in
This magically fixed the missing header errors. I'd explain it if I had any idea why.
Then I had to add this line directly after that command:
move ..\deploy ..\axis2c-bin-1.6.0-win32
This was necessary to fix the rest of the build scripts, as they all reference the build directory as axis2c-bin-1.6.0-win32, even though Axis2/C actually puts everything in a folder called "deploy". If you're zealous for detail you could change every reference to that folder to have "win64" at the end, but I just wanted to get it working with the least possible effort.
But note that these are all steps above and beyond the initial install/build instructions that come in the WSO2 documentation. All of the steps indicated in WSO2's instructions are still also necessary (except anything exclusively for 32-bit, obviously).
And unfortunately this didn't solve my real problem, which was trying to load Rampart DLLs from Axis2/C. I was pursuing WSO2's implementation in hopes that they were building things in some better way, but alas, no luck. I'll post my Rampart problem in a separate, equally unlikely to be answered thread. I have yet to find a solution to that one anywhere on the web.
I've been trying to get Visual C++ working, but I'm getting this error when building every project: "This project is out of date" "Would you like to build it?" It fails to build every time.
When I rebuild, the build still fails, although in the logger I don't notice any error messages, which makes me think its not logging properly (I'm using a third party program to log).
I've followed some of the instructions here: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx and enabled logging.
I'm getting this error: project not up to date because "insert file name here".lastbuildstate is missing. Note that in actual visual studio, there is nothing logged. I was unable to find anything on this in google. It may be that I incorrectly enabled logging, but I feel that this is the error.
You should let Visual Studio tell you why it needs to rebuild. Visual Studio 2015 has built in support for this:
Tools (menu)
Options
Project and Solution
Build and Run
Change MSBuild project build output verbosity to Detailed or Diagnostics.
In my case it printed a message like this:
1>------ Up-To-Date check: Project: xyz, Configuration: xyz ------
1>Project not up to date because build input 'C:\ws\Missing.h' is missing.
... and removing that header from the project fixed the problem.
To get this information in older Visual Studio versions, you need to use DebugView and modify devenv.exe.config (see Colin Smith's answer: https://stackoverflow.com/a/21759835/1941779). Note that this solution does NOT work for Visual Studio 2015.
What are "tlog" files?
"tlog" files are created by the "Tracker.exe" process which runs while you do a build, and records some information about the build.
That information is used and updated the next time you start a build to help detect "out of date" files, and thus enable the build system to only build the bits that need to be rebuilt (rather than building everything again).
File Tracker Log file format
https://social.msdn.microsoft.com/Forums/vstudio/en-US/67705333-a425-4d6e-9881-9077f044f87a/how-do-i-prevent-msbuild-from-creating-tlog-files-during-my-c-builds?forum=msbuild
https://dickyjim.wordpress.com/tag/tlog-files/
What causes the "out of date" problem?
The problem can be caused by incorrect or stale information in the *.tlog files.
There are 3 main ways that can happen:
1) You built a project on your hard disk, and then moved the directory to another location...the "tlog" files recorded the paths of the old location, yet because you moved the files, they are no longer there, thus you get "out of date".
2) Your "Project" has references to files (usually header files), which do not exist at the location specified. This might occur if you deleted a file from your source control system, but forgot to remove it from your project, or because you refer to header files of a library which might be "installed"/present at a different location. Often, Developers assume files are located at the same "place" on everyones machine....not always the case!
3) You have done some "refactoring" of your project, and moved files around to different subdirectories, or even renamed them - so the paths/names of the files recorded in the "tlog" do not match what exists on your disk i.e. stale.
What is the way to fix it?
Doing a "Clean+Build" or "Rebuild" does not always fix it...as those operations do not delete the "tlog" files. So:
delete any "tlog" files that you can find in your solution/project directories and rebuild.
make sure your Project does not refer to non-existent files
How do I work out which files are non-existent?
If you want to know/find out exactly which files Visual Studio is thinking are out of date, then you can turn on some diagnostic information in Visual Studio....and watch the messages in DebugView...showing the full path of the files it is probing.
http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx
In devenv.exe.config you put:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
More Details
Lets say you created a Solution and a set of Projects in a particular directory e.g. S:\MYPROJECTS, and you compile and run/debug it, etc.
You then decide to move that whole directory to somewhere else on your drive, or you re-factor your Projects e.g. change their directory names, etc.
Now when you do a "Start Debugging/F5", Visual Studio does the depending checking, and thinks you have "out of date files".
Even if you do a "Clean Solution", or a "Rebuild Solution"....you still get the "out of date files" message.
See here:
http://connect.microsoft.com/VisualStudio/feedback/details/653355/suggestion-help-me-diagnose-issues-causing-this-project-is-out-of-date-message
The problem is caused by the ".tlog" files which are being consulted during the dependency checks...when you moved the solutions/projects (along with a builds intermediate files) they cause confusion to the Visual Studio builder.
The solution is to delete all the .tlog files.....they will then be re-generated the next time you do a build...and from that point on you won't get a bogus "out of date files" message....unless they truly are out of date.
I too kept getting "The project out-of-date" error, even though there were no changes. I traced it to a header file listed in Solution Explorer that was no longer being used and had been deleted from the project's directory. Removing it from the SE list fixed the extraneous error message from popping up.
I had this problem, too.
In my case the reason was the references to files (usually header files), which do not exist at the location specified.
I ran into this problem and, using the diagnostics trick that colinsmith posted about, was able to trace the problem back to the fact that my .vcxproj was referencing a file that didn't actually exist anywhere (It had been deleted a long time ago, but never removed from the project file).
Just for posterity, I was getting this problem, and then realized my computer clock had somehow jumped approximately 48 hours into the past. After I set it back to current time, the warning went away.