Does anyone know why every time I save changes to a file within Visual Studio 2017 it changes my file icon (see screenshot below)?
I'm not sure if this is the result of an extension I've installed or was rolled out within an update to Visual Studio.
I would really like to disable this, any help is appreciated.
UPDATE 1
This doesn't seem to be related to Git integration as the icons still change with source control features disabled (see screenshot below).
This seems to be a known issue for .NET Core solutions within Visual Studio 2017.
The developer community has already reported this issue, see Solution Shows Missing File Icon, which is currently "Under Investigation".
Updated August 30, 2017
The fix for this known issue is now currently marked as "Fixed - Pending Release".
Updated September 15, 2017
This issue has been fixed and is included within version 15.4 which is included in Visual Studio 2017 Preview. Downloaded and confirmed this is not longer an issue with the preview edition.
If you made sure VS didn't throw any error, warning or info exception in its Error List regarding the modified file, it most likely is related to the Git integration this Visual Studio edition came with. It works like a file version controller software, showing visual icons like this one to show if the files were commited and if they were, if they are new or not and altered or not.
To disable source code control, go to Tools, Options, Source Code Control and select None. If nothing changes instantly, I recommend restarting VS and checking again.
Related
I recently updated from Visual Studio 2017 Community Edition to Visual Studio 2019 Community Edition.
Now, if I build my solution with errors, they will show up in the build output, but not all of them will appear in the error list. It would appear only errors of open files will show up in the error list. This is incredibly annoying.
I am not alone in this issue. It has been reported many times on Microsoft's forums, but no one has a definitive solution.
I have tried a variety of solutions people suggested in those threads:
I have ensured the filters are legitimate: Entire Solution, Errors enabled, Build + Intellisense.
I have tried deleting the .vs folder and restarting Visual Studio.
I just updated to the very latest Visual Studio 2019 version. Supposedly there are many different versions of this error, happening in versions of Visual Studio all the way back to 2017. Some supposedly have been fixed...?
I have disabled parallel project loading.
I have experienced this before in other versions of Visual Studio with Razor pages. To my knowledge, that's to be expected in Razor though.
The only other factor that I severely doubt impacts anything is that it's a Visual Studio project generated by Unity editor. From what I've read, ASP.NET, Razor, Xamarin, and other frameworks have each had their own version of issue reported. Perhaps Unity is afflicted by it too, but I don't see how or why. I doubt Unity's auto-generated Visual Studio projects are that different from your standard library projects.
I have now installed Visual Studio 2019 on two separate machines, and it appears that "Full Solution Analysis" is disabled by default.
Simply check the checkbox in options and everything seems to work as it did previously:
For those using Visual Studio 2019 v16.9.1 make sure your Error List window looks something like this:
The important part for me was selecting Build + IntelliSense (previously it was set to Build Only which explains why the error list would only refresh on build).
In my case the solution was to switch off 'Tools->Options->Projects and Solutions->General->Show output window when build starts'. Even though the 'Output' window showed "0 succeeded, 1 failed" it would not switch back to the 'Error List' window even that the checkbox above 'Always show Error List if build finished with errors' should have moved it to 'Error List'. Clearly a bug in Visual Studio 2019 which was not present in Visual Studio 2017 (I just finished updating).
In my case, it was the fact that I was building under a Release profile. Once I chose Debug from the dropdown next to the Start Debugging button, it started showing my errors in the Error List after a few seconds.
In my case it was since the dependency dll was built for x86, but in the misbehaving project its reference was with processorArchitecture=MSIL
I have noticed a weird issue with Visual Studio 2019 v16.0.1 the IntelliSense about "Using directive is unnecessary" normally grey is missing and type reference suggestion for missing using is not working.
I also tried with Visual Studio 2019 Preview but no luck.
I have tried the following:
deleted .vs folder and restarted.
Reinstalled Visual Studio
Reset settings via import and export setting under tools
Any other suggestions will be appreciated.
Close Visual Studio
Delete .vs folder (it is a hidden folder inside the folder which contains the solution *.sln)
Start Visual Studio
Solved my problem
Update From the comments
Deleting Browse.VC.db file within .vs folder worked for me. I did this to avoid deleting .suo which has information I want to preserve
NOTE 1: I am using Visual Studio 2019, but it may work on other versions
NOTE 2: This did not solve the OP problem, but it is a good candidate to solve your
Go to Tools -> Options -> Text Editor -> All Languages -> General. Make sure “Auto List Members” is checked. Also, make sure “Parameter Information” is checked.
If you are facing this issue with Unity projects then,
Check in your Unity settings whether it has Visual Studio configured as the external editor.
Click on Regenarate project files in the Unity settings.
Go to Assets => Open C# project.
This will restart Visual Studio with your project.
In my case, Resharper is the culprit. Disabling it immediately solved the issue.
I think these issues are discussed here and are resolved by an update and some worksrounds are bring discussed:
https://developercommunity.visualstudio.com/content/problem/505489/cannot-navigate-to-the-symbol-under-the-caret-3.html
For anyone who are searching for another suggestion, I just go throught this issue, as OP said, I've deleted .vs folder, I've update vs to last version, I've uninstalled and reinstalled vs to the last version, I've reset settings, delete all obj folders, I've installed Microsoft.Net.Compilers but nothing worked, at the end I just remembered that sometimes the projects required WindowsBase library, until now I don't know why, but after adding that dll Intellisense started to function again.
I use resharper (vs 2017) but had not installed it on 2019. After installing Resharper on 2019 the intellisense started working again. (yes, it was working in 2019, then stopped)
I don't have an explanation on why this would fix it. Just did for me.
First time I use VS 2019, I need to manually install Code Analysis. Make sure it is installed at your project properties.
And today, for the new class, the suggestion or namespaces not showing for VS 2019 Intellisense, and Go to Definition not working too.
I must do close solution, and re-open and VS 2019 doing scanning while opening project, and then worked again.
I think this is bug for VS 2019. Try to close solution and re-open it.
I have tried almost all the solution mentioned above but it doesn't helped me. Trying to restart my PC solved my problem.
I tried lots of things but nothing worked for me until I found this post. He mentions a few things I have already tried that didn't work, but his final solution worked for me...
At the root of our solution there is a packages folder. I deleted the
entire contents of this folder. Upon reopening Visual Studio,
Intellisense and Go To Definition were restored to full working order.
close visual stdio
For mac in your folder: do command + shift+ .
you will see hidden files -> delete .vs folder
open solution again
After working for a few months, Intellisense suddenly stopped. This cost me a lot of lost time! I've been worked with Visual Studio for about 10 years, and this problem happens occasionally in every version.
Here's what I tried for this iteration of the problem:
Closing Visual Studio and re-opening does sometimes make the problem disappear for a short time, but it certainly doesn't solve it
Likewise restarting my laptop
Installing the latest Visual Studio 2019 update didn't help (I'm on 16.8.3 now if anyone's interested)
Deleting the hidden .vs folder doesn't seem to solve anything (doing so also means you lose your current window layout, as well as any bookmarks you've set)
Unticking the Track Changes option in this menu: Tools-> Options-> Text Editor-> General.
I've updated my NuGet reference to the Microsoft.Net.Compilers library to the latest stable version, as suggested here, but sadly this made no difference
I thought I've finally solved the problem by following the advice from Homer. I deleted the packages folder at the base level of my project (somewhat nervously, as I wasn't sure if it was needed), and thought it had solved the problem, but no such luck.
However, one thing to watch out for - after doing this, Visual Studio recognised my classes but no longer recognised built-in ones (all the referenced namespaces at the top of my controllers were underlined in red). I then deleted the .vs folder (again), which seemed to solve the problem.
When I recompiled my solution, it gave a few CS0433 compilation errors with duplicate namespaces for the MinLength and MaxLength directives in some identity user name and password validation code. I got round this by removing the Microsoft.EntityFramework Nuget library (I had to also remove Microsoft.AspNet.Identity.EntityFramework too, since this depended on it), then adding them both back in, making sure to include at least version 6.2 of the former (otherwise I got another runtime error to do with the FirstOrDefaultAsync method called somewhere!).
My current situation: all existing Intellisense is working, but it's not recognising new classes I add unless I exit Visual Studio and go back in again. May have to live with this ... unless anyone can help me?
I've got that problem today with only one project. I got no Intellisense warnings (i.e. naming styles, "Variable not referenced", etc..) for files in that project. Not in VS 2017 Pro nor in VS 2019 Community.
Check, if your Project->Build->"Warning level" is set to 0...
If you have Visual Studio 2017 installed side-by-side with Visual Studio 2019, close VS2019, open the project in VS2017, wait until it is fully loaded, then close VS2017, and reopen VS2019 - fixed!
There must be a bug in the VS2019 intellisense stuff, but VS2017 seems to fix it with no need to keep deleting the .vs directory.
I am trying to disable output of a vshost.exe file to my release folder.
There is a similar question here and here. This Microsoft doc instruction for 2015, and followed the 2017 rc link and found this
They all mention the Enable the Visual Studio hosting process checkbox on the properties Debug tab. But this option does not appear in my screen.
I have tried this on the properties pages for Console Application and windows Application project output types.
Is this feature supported in VS Community 2017 or is there another way to achieve he same result?
This feature seems to be removed in VS 2017. According to this thread and also this one. Unfortunately, I haven't found anything from official sources.
So my guess is that maybe you had these files there generated by previous versions (VS2015?). Try deleting all files from bin and obj directories and do a build to see if these files are generated again.
Hope this helps!
I have a relatively large WinForms application that has been developed under Visual Studio 2013. I recently upgraded to Visual Studio 2015 on another computer and have been trying to get the project working under it.
My first issue/concern is that when I open the project for the first time in Visual Studio 2015 it does not ask me to "upgrade" the solution to Visual Studio 2015, it happily just opens the solution. I am used to having Visual Studio ask to "upgrade" the solution and create a new .sln file that is recognized as a, for example, Visual Studio 2013 solution instead of the old VS10 solution.
The actual issue I am facing is ~10 errors that seem to deal with cryptography. From what I can guess this has to do with the solution itself and what microsoft does with it in the background seeing as the most cryptography I use in the project is generating Guid.
An image of the errors
The one other issue I have is that, as I am not used to, I cannot double click on the errors them self to be lead to where Visual Studio thinks they are occurring. Thus I am not sure what is generating them or where to go from here.
Any suggestions?
This is a Windows 7 installation on an older model Lenovo Thinkpad. I do not have admin privileges on this computer either.
EDIT: So far I have tried to add <enforceFIPSPolicy enabled="false"/> to the file Visual Studio 15 settings at C\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Devenv.exe.config, though whenever I try to edit it (even after a fresh restart) the file is "always" opened by another program. So it seems I cannot edit the file to turn off FIPS for Visual Studio 15.
I am still open to suggestions or clues.
EDIT2: I have managed to get <enforceFIPSPolicy enabled="false"/> into the IDE settings with the help of IT (Using this article). Though this seems to do absolutely nothing, it seems that it is being ignored.
Another issue/clue here is that even if I create a brand new C# project in Visual Studio, when I try to compile I receive the same errors. So I have to assume that Visual Studio is using the SHA256 class somewhere "in the background". If I did have control over its usage I would try to implement #Kevin 's answer below.
I have found another possible solution on the web though I am not sure of its validity
VS 2012 now builds C# projects in a separate process that runs
msbuild. The entry you added to devenv.exe.config (that worked for VS
2010) won't be seen by this process. You should add the same entry,
namely
to the config file for msbuild; typically that's found at
c:\Windows\Microsoft.Net\Framework\v4.0.30319\msbuild.exe.config"
I will try to get this done when I have time for the .NET 4.5+ msbuild.exe.config files and report back.
The solution I went with is outline here.
<enforceFIPSPolicy enabled="false"/> was added to a few files, namely
C:\Program Files (x86)\MSBuild\12.0\Bin\msbuild.exe.config
C:\Windows\Microsoft.Net\Framework\v4.0.30319\msbuild.exe.config
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Devenv.exe.config
Though I think the one that actually made it work was the first file.
You can't double click on the error and have it go to where the error is being thrown because it is being thrown inside the SHA256 class. If the FIPS compliance bit is set, any non-FIPS compliant .NET cryptography classes throw this error.
You have two choices to fix this...
First, you can just turn off the FIPS compliance bit on the machine where you are trying to run the app (not recommended).
Otherwise, you can update the code to use the FIPS compliant version of SHA256 (SHA256CryptoServiceProvider). This will require .NET Framework 3.5 or greater.
In short: I need to open an application originally built in Visual Studio 2008 (version 9) in Visual Studio 2013 without upgrading the project since the overall project architecture must remain the same for when I check it back into source control.
Details: I need to open a Visual Studio solution (.sln) inside Visual Studio 2013. The solution in question was originally developed in Visual Studio 2008, so when I try to open said solution in Visual Studio 2013, I am shown a prompt with the projects within the solution checkmarked, with the message:
These projects are either or supported or need project behavior impacting modifications to open in this version of Visual Studio. Projects no displayed either require no changes or will automatically be modified such that behavior is not impacted. Visual Studio will automatically make functional changes to the following projects in order to open them. You will not be able to open these projects in the version of Visual Studio in which they were originally created.*
My attempt at a fix was to just upgrade the solution and hope for the best. This is successful, but after building and attempting to run the main project, I see the following build error:
The type 'Microsoft.Web.Services3.WebServicesClientProtocol' is defined in an assembly that is not referenced. You must add a reference to assembly 'Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. *
I then tried both commenting out the references to this assembly and adding in the missing reference. Okay, so then I rebuilt the solution and attempted to run. Same error, but for a different assembly. Repeat fix, same error for different assembly. This pattern continues and continues, and at this point I realize this is unacceptable anyway, because when I make a change to this solution, I need to check it back into source control. When others open it, they may be opening it in VS2008, and therefore this “upgraded” version is inconsistent with the version the business uses. I need to open the solution originally build in VS2008 in VS 2013 (can't work around this, needs to be VS2013). If it helps, I'm using 64 bit Visual Studio 2013 Ultimate.
Any help or guidance will be greatly appreciated!
As several of the commenters have already helpfully pointed out, this is not possible. Round-tripping (i.e., opening and manipulating project files created by an older version of Visual Studio in a newer version of Visual Studio) was not supported until Visual Studio 11. The only way to open a Visual Studio 2008 project/solution in a later version of Visual Studio will be to convert it.
As far as interoperability with previous versions is concerned, you have two options:
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then edit the code files. Once you're satisfied with your edits, commit only the modified source files, not the project infrastructure files. Your fellow developers, stuck on VS 2008, won't notice any difference.
Update the project locally (using the migration wizard provided), make any changes to the project file necessary to get it to build, and then rename the project file (e.g., by appending a -vs2013 suffix to it). Commit this to your code repository. You will now have two project files in your root directory, one for each version of Visual Studio that your team works with. From here on, you just open the project file corresponding to the version of VS that you have installed.
I used approach #1 for a good part of last year, where I spent most of my time developing a C++ application in VS 2010 on a desktop machine, but also wanted to work on it on my notebook running VS 2013. Of course, in my case, it took a trivial amount of time for the automatic conversion to upgrade my project file after pulling from source control. I didn't have to do any tweaking thereafter to get the project to build. It sounds like your case is different, so option #2 might be a better choice.