When I start up Visual Studio 2013 everything works perfectly, then after 10-20 minutes it stops allowing me to type semicolon but everything else sill works. I can copy/paste semicolons from elsewhere in the source file, but this is a real pain.
It has been doing this for a few days. I didn't manually update anything recently.
I tried clearing the Resharper cache and even disabled Resharper altogether just in case but the problem keeps on happening.
Help!!!
I finally discovered what my problem is. I am writing a reusable library and want to build .Net 4.0 and .Net 4.5 versions from the same source code. I achieved this by creating two projects in the same folder that reference the same source files but are configured to target different frameworks, and use different bin and obj folders.
This setup seems to work really well for the most part, but it appears to really confuse the Visual Studio intellisense system because when you open a source file and edit it, Intellisense doesn't know whether to make suggestions from the .Net 4.0 or 4.5 framework because the source file belongs to both projects.
I solved my semicolon problem by unloading the .Net 4.5 project whilst editing and debugging the code, then reloading it when I want to make a release build.
Related
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.
The problem
Suddenly, Visual Studio (2015 RC) started throwing error CS7069 in my face a lot. It states
Reference to type '...' claims it is defined in '<assembly>', but it could not be found.
Yet VS's functionality "Goto reference" did function and squigglies weren't consistently present, so I figured something weird was going on.
How I created the problem
It started when I was refactoring/splitting a project. I was moving .cs files from one project to a new one. Types that I moved to the new project couldn't be found anymore by the compilation process of a project that referenced both projects.
What I tried
I verified that the relevant assembly was indeed referenced, present and had the type with public modifier. I rebuilt it, checked version numbers (of target frameworks etc), removed the relevant reference and re-added it, cleaned solutions and projects, checked configuration manager settings, removed all VS's temporary files and whatnot, and I couldn't fix the bug for 4 days. 4 long days, might I add.
Googling didn't result in anything either, so I hope that the next poor fellow who made the same mistake as I did finds this page, as I finally found out what was going on:
I had two projects with identical assembly names...
Renaming the new assembly in its properties menu made all errors vanish.
Fixed bug on Visual Studio 2015.
Go to Tools menu, Options, Debugging, General: Check: "Use the legacy C# and VB expression evaluators"
Try to clean/rebuild the project. It helped me.
Also try to remove all of the *.suo and *.user files in your solution folder
http://blog.galasoft.ch/posts/2014/01/quick-tip-what-to-do-when-visual-studio-freaks-out-and-everything-is-red/
I had this problem and it turned out I had the wrong build configuration selected. The reference projects and the project I was building were not selected for that build configuration. Simple to fix, but not something I looked at for a while.
I tend to use Regionerate quite extensively for reorganizing my code files. My only problem is I can't get it registered with VS2012. I've abandoned VS2010 fully in favour of VS2012 and it's galling to have to flip back just to run a macro to reorganize code files. I've never tried writing a VS addin before so I'm not at all familiar with the object model or how to register - seems the old addins are more complicated to install than the VS2010 extensions! I've also looked through the WIX setup XML and tried replicating the registry keys to no avail.
Does anyone know how to either register Regionerate with VS2012, or is there an alternative (free and which is maintained!) extension that provides the same functionality?
Two things needed for registration:
It looks like VS2012 doesn't read from the HKLM...\11.0\AutomationOptions key at runtime, only at first run. The corresponding key at HKCU...\11.0_Config\AutomationOptions needs to be set as well.
A new .AddIn file needs to be created with a Version of 11.0
If you do that, Regionerate will appear, but will hang Studio when you try to use it. The Regionerate code has a bad version check ("not equal" instead of "less than") that will get stuck in code that doesn't work for VS2010/2012. Unchecking "Automatically collapse regions" in Regionerate settings might be enough to avoid the bad code.
I made a new version that fixes the version check and has the correct install pieces for VS2012. You can download the installer and changed source files here:
https://skydrive.live.com/redir?resid=2FEB8D1988F04D77!565
This is what you need to do to make VS2012 compatible Regionerate (0.8.0.1) by Frank Racis work with Visual Studio 2013.
Modify this file: C:\Program Files (x86)\Regionerate\Regionerate.VS2012.AddIn
Change version from 11 to 12: <Version>12.0</Version>
Add the following string value in your registry:
Location: HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\AutomationOptions\LookInFolders
Name: C:\Program Files (x86)\Regionerate\
CodeMaid is a free and actively developed alternative. It has nearly all the features of Regionerate, plus some new stuff. One thing I really like is setting it to organize and clean unsaved files every time I build.
Visual Studio sometimes decides to rebuild my entire huge project because of one small change. I turned build logging up to Diagnostic to see what was the problem, and here's what I'm seeing:
< Bunch of spam >
Outputs for C:\<snip>\PRECOMPILEDHEADERS.CPP:
C:\<snip>\PRECOMPILEDHEADERS.OBJ
All outputs are up-to-date.
Forcing rebuild of all source files due to a change in the command line
... and then it rebuilds my precompiled headers, then everything else.
This happens when I change a single .cpp or .h file inside the project. I'm not changing anything in the project settings. It also doesn't happen all the time for the same change; it's random.
Any ideas on what's going on here? Where can I get more information? I tried enabling debugging via the description in http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx but it didn't give any more information. I can't figure out where this "Forcing rebuild of all source files due to a change in the command line" is coming from. It's not in any of the factory MSBuild files.
Some other info: it's a C++/CLI dll project that links a lot of other projects, including C#, native c++, and other C++/CLI dll's. I tried removing all the C# projects from the dependencies since those tend to cause problems, but that didn't change it. I've googled that specific string, but my situation doesn't match that of any of the other people reporting it. (One was using Intel C++, another was MSBuild from the command line and changing the case. I'm hitting build solution from within Visual Studio itself).
Edit to explain common fixes I've tried:
I've tried building only the project. Does the same thing.
I'm not including any .h files that don't exist.
I've deleted the bin/object folders and rebuilt from scratch. This usually makes it go away for a couple builds, but then it comes right back.
Edit #2:
Found something suspicious earlier in the log:
3>Using "ResolveNonMSBuildProjectOutput" task from assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
3>Task "ResolveNonMSBuildProjectOutput"
3> Resolving project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj".
3> Project reference "..\..\..\..\CommonCore\VS2010\Project1\Project1.vcxproj" has not been resolved.
This is repeated for several of my projects... I'm gonna chase that down and see if maybe it's a problem with the project reference hint paths.
Ok, it's an old thread, but I encountered the same problem recently.
My solution was to disable the precompiled headers - now a simple change in one sourcefile won't lead into a "rebuild" any more.
I have had the same problem with Visual Studio 2012 recently. I'm on Windows 7 with Visual Studio 2012 Professional (2012.2) building C++ projects. It's worth noting that I recently migrated the solution from Visual Studio 2008 to Visual Studio 2012.
One of the C++ projects (an executable with a DLL project as a reference) was rebuilding every time one of its compilation units was changed, e.g. simply saving main.cpp would cause all compilation units (including the pre-compiled header) to rebuild. I spotted the the following message in the build logs:
Forcing rebuild of all source files due to a change in the command line since the last build.
I turned build log file verbosity to Diagnostic (Tools > Options > Projects and Solutions > Build and Run) and compared the log files from a clean build and a build after one compilation unit has been changed (which forced a full rebuild). I noticed that:
"Path" had changed from one build to the next (";C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\Extensions\Microsoft\VsGraphics" seems to have been tacked on the end)
there was a difference in TaskTracker.exe command lines to do with CancelEvents
there was a warning about OutputPath not being set
I pulled my hair out.
I eventually resorted to recreating the offending project from scratch rather than relying on the project that was automatically generated during the migration process from 2008 to 2012. It seems to be behaving as expected now.
I did three things, and the problem seems to have gone away. I'm trying to narrow it down a little but I figured I'd go ahead and post them:
Deleted and re-added all the references and project references
Fixed one of my projects that wasn't setting the .NET framework target to 3.5 to match the rest of my solution (I was getting away with it because the project didn't use .NET anyway)
Set "Copy Local Satellite Assemblies" to false for all references including System ones.
Beware that some or all of this stuff might be voodoo...
Source code that compiles fine on other peoples environments won't correctly work in my environment. When I do a rebuild the compile occurs but when visual studio goes to move the exe from /obj/debug/{solution} to /debug/{solution} it cannot find the exe in the /obj/debug/{solution}. To make this even more crazy even after I reinstall visual studio it doesn't work. On other people environments it works find. Please note that this is a windows mobile 6, compact framework 3.5 project, Visual C++ project.
EDIT: Visual Studio 2008 is being used.
EDIT2: After looking at the logs again come to find out it says it is compiling but it isn't really compiling. Interesting enough it doesn't throw any errors until it tries to link the code. When it goes to link the object files, they aren't there and it fails.
I got TWO Release folders: one in the solution folder and one in the project folder. The former contains the .exe file, the latter does not.
In the solution properties page, check whether the path you are expecting the exe to be is same as the one specified in Linker -> Output file.
Another obvious mistake could be, check what build configuration you are building. You might be doing a release build and expecting a debug executable file :) I have done this a few times.
Maybe VS creates the exe, and before it tries to move it to the final destination your virus scanner grabs it and removes it, or moves it to a save location.
I just wanted to chime in and ask: have you looked for the *.exe file name from the directories above? What I found in my case was it was writing to the directory right above the /release subdirectory. Not sure how I missed that detail, but I did! I suppose it never occurred to me earlier because I saw the buildlog.htm being written to the /release subdirectory, and the very existence of the directory itself. In my case it was compiling, linking, etc. I just wasn't able to see the *.exe in that /release subdirectory.
There are two subtly different paths. I was looking here, which doesn't exist:
C:\Users\james\source\repos\CppHelloWorld\Release\CppHelloWorld.exe
The actual exe is here - note the path contains the x64 platform that it was built for:
C:\Users\james\source\repos\CppHelloWorld\x64\Release\CppHelloWorld.exe
In general, the path seems to be:
$PROJECT_PATH\$PROJECT_NAME\$PLATFORM\$CONFIGURATION\$PROJECT_NAME.exe
If the exact same solution works on other machines, then it's an environment problem and no amount of looking at the project, linker, etc is going to resolve this. What is different about the environments? Are the same service packs and QFE's applied for not just Studio, but also the OS? Is there a difference in processors (64/32-bit)? Are your permissions the same? Do you have the same SDKs installed?
I'd agree with Shahi that just trying to build a "hello world" app against the same SDK and see if it will compile is valuable info.
I had exactly the same problem. Just close Visual Studio and reopen it again (basically restart it) and it should work.
In my case, my network security team released an unannounced security update that preventing me from creating any .exe files. I figured that out at midday after trying all the solutions (+ more) here.
Perhaps you do not have write permission to the output folder? If you are running on Vista/7, is your Visual Studio running as elevated?
I've found this to be random for myself in now VS2016. My work around has been to just create another project and copy the contents from the one with out the .exe to the new one. For some reason the new one normally will have the proper .exe and location needed. While this isn't a complete solution at least it's been working for me for the time being.
It happened with me today:
TL;DR; You might be using some C# code in your project who belong to a language version which is not supported by the .NET Framework version targeted by your project
Details:
I had two projects in my solution. One project was already existing. I added a new project targeting most recent .NET Framework v4.6.1 supported by Visual Studio(VS) 2017 class library project template. I used some C# language features which is present in C# v7.0. In such a case, VS can compile the project but can't create the output in bin directory.
Eventually I had to merge the new project code files into the existing old project which was targeting .NET Framework v4.5.1.
So I changed the target Framework version to the latest .NET Framework v4.6.1 for the existing projects also. Then the old project also started supporting my newly pasted C# language features.
In my case, the error appeared after I cloned my solution on a new machine.
I did not realise that the newly-cloned solution had AnyCPU set by default, when in reality my solution only supported x64. The compiler, however, did not return any error.
What pointed me in the right direction was the Output log, highlighted that of the 4 projects my solution was composed of, one of them was always skipped, i.e. only 3 were actually compiled. Scrolling up a bit the log, I noticed some message similar to MSIL mismatch between CPU versions.
Switching from AnyCPU to x64 solved the error for me.
(I then deleted the AnyCPU option from the Configuration Manager to avoid this issue in the future)
If you create a new "hello world" WM project, does it work?
If so, you can compare the solution files to check for differences that can cause this.
As far as I could tell, you need to "Save All" before building.