When I'm editing a class in Visual Studio, frequently these weird 'using' statements get automatically added to my classes. I don't add them and I have to constantly remove them. I have no idea where they are coming from or why they are getting added when I have no references to these objects. This didn't happen in previous (e.g. 2019) versions of VS.
Is there a setting or something I can change that's causing this?
Related
I upgraded to Visual Studio 2022 (17.4.4) and see that the formatting options have changed significantly.
I have tried experimenting and searching but cannot figure out how to force the required use of the this keyword when referring to instance fields, properties, methods, etc.
Setting VS options as well as editing the *.editconfig file has had no effect. The this keyword keeps getting removed during file saving, formatting, and compilation.
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
ReSharper TypeScript seems to be not working at all in my VS 2015 installation. Despite of the correctly placed TypeScript definitions ReSharper does not recognize the defined types, gives zillion red underlines, and of course intellisense does not work on the variables.
The error message is for example: Could not find symbol 'JQuery'
Some more diagnostics:
Compiling the project in VS 2015 compiles with no error. Making an intentional error in the source then build generates one correct error message
Intentionally making a spell in the type definition file paths, it underlined with red correctly. When correcting the path, underline diasppears
Opening the very same project in VS 2013 all works like a charm, ReSharper is working correctly
Originally used ReSharper 9.1.2 this issue was there. Now upgraded to the latest 9.1.3 and the issue remained.
Any ideas?
If you see this kind of behaviour - lots of red, but clean compile, especially after an upgrade - you should try to clean the caches. Go to ReSharper → Options → General → Clean caches, then restart Visual Studio.
Since the problem occurs in more than one version including latest as of writing, you also have the option to switch off TypeScript support in ReSharper. After all, if a feature is broken, why use it?
How to switch it off according to their web site:
If necessary, you can disable/enable ReSharper features in TypeScript
files by clearing the corresponding check box on the Environment |
Products & Feature page of ReSharper options.
Source: JetBrains help page for ReSharper (retrieved 29 March 2018)
After this change you may have to restart Visual Studio for the new settings to take effect.
I have found that sometimes, the Visual Studio Project file is corrupted, containing multiple references to .ts files. This can cause a different, but related error, where ReSharper thinks there are multiple declarations of a symbol.
To resolve, if you are using version control, it is simple.
Make a commit
Delete the folder containing the duplicated files
Revert changes to the repository
Add the folder back to Visual Studio
Save the project file
As I mentioned, this doesn't solve the original problem, but can help in situations where ReSharper reports duplicate symbols.
For a couple of weeks now I have been unable to merge Views within Visual Studio 2013 in response to conflicts when getting Source Code from Visual Studio Team Services. I am sure I used to be able to this (we recently moved from Visual Studio Professional 2012 so I cannot be one hundred percent certain - automerging may have been sufficient in the early days of the project).
The "Accept Merge" and move to next change/conflict buttons are all greyed out and inoperable. See screenshot snippet-
This originally only happened with Views, but now seems to affect some other classes. Changes are highlighted and indicated on the scroll bar so the diff tool otherwise appears to be functioning. This only originally affected me, but now affects a new colleague into the team.
I can still either Keep Local Version or Take Server Version but this is rarely sufficient. This leaves me manually altering the local copy to apply changes highlighted by the merge tool. (Edit - See a better workaround in "Second Update" below).
Has anyone come across this before?
Visual Studio 2013 Premium (patch RTM/Update 1/Update 2 - all with the same problem), with Resharper 8.2 (originally 8.0.2) C# and Web Essentials installed. Running on Windows 7 Professional x64.
Project is ASP.NET 4.5 using MVC 5.1.2 (now additionally updated from MVC 5 where the problem first occurred) (upgraded from MVC 4 following the upgrade instructions on the ASP.NET website) in C#, using latest versions of Razor (3.1.2) and Entity Framework (6.1.0 RTM).
Edit: Initially a repair install of Visual Studio 2013 appeared to have fixed the issue. It has now however returned exactly as it was before. Since it took an hour to do the repair I cannot repeatedly do this in order to merge views. I am currently able to round trip the solution between Visual Studio 2012 Update 4 and Visual Studio 2013 in order to do merges in Visual Studio 2012 where it is working normally.
Second Edit: I am currently manually resolving conflicts by selecting the desired code (local/server), saving the merge window and then closing it which will prompt to accept the merge result. This seems to function but is obviously sub-optimal. It may however be helpful for other users.
In the event, installing Resharper 8.1 on top of 8.02 appears to have fixed it fixed it briefly before the problem returned yet again. I had previously completed a repair install of Visual Studio Premium 2013 as well - which briefly seemed to have fixed it before it broke again. I only mention it in case the fix is cumulative.
I am unclear if it was a bug in Resharper that was somehow preventing the merge, or a persistent problem with the installation that the upgrade cleaned up (Resharper removes previous versions and then installs updates, rather than attempting to install over the top). Update - I am extremely confident that this is not related to ReSharper and that it was the configuration of Visual Studio as a result of re-installing the extension and not the extension itself that fixed the issue.
In either case, the issue (for now) seems to have disappeared and this seems to be related to the upgrade, or is an extremely strong co-incidence.
Colleagues with the same versions of Visual Studio and Resharper, working on the same project, the same version of Windows and (in one case) the same hardware were not affected, so it seems likely it is an edge case niche issue caused by corrupted data somewhere.
I have a current working theory that this is related to different patch versions of Visual Studio (for example Visual Studio 2012 Update 2, Visual Studio 2013 RTM, Visual Studio 2013 Update 1, Visual Studio 2013 Update 2. This only affects Visual Studio 2013 for us.
Simple solution I use is carry on with your manual merge process once you are done simply Close the Merge-* tab (the one you are using to merge files) this will bring up a prompt for confirming if you want to Save the changes made (this is the merge changes you made to your local file) click 'yes' Now it comes back to Resolve Conflicts tab and brings up another prompt asking if you want to Accept Merge Result, click 'yes'(this is same as the button Accept Merge)
Since you have VS2012 installed and merge is working there, you can create a link to its TF.exe in VS2013, similar to one on the picture below, and fix the issues there. Set Command to c:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\TF.exe and Arguments to resolve.
You do that in Tools->External Tools.
I have the following problem with design-time debugging in Visual Studio 2010 Pro.
In my solution I have got two libraries. One with name Alfa that contains some of my basic components. Two with name AlfaDesign that it contains designers for components from library Alfa. And of course I have a project for developing and testing Alfa components.
AlfaDesign is having reference to Alfa library. And the test project is having a reference to Alfa and AlfaDesign.
And my problem:
When I put breakpoint in component's constructor from the Alfa library and then I put this component on the form in my testing project, the debbuger is doesn't break. Visual Studio is still running.
I followed instruction from the tutorial Walkthrough: Debugging Custom Windows Forms Controls at Design Time, but without any success.
I ran into this problem today with one of my projects, and I spent the last several hours figuring it out. What I found is that the symbols and modules will not load when your project target framework is set to anything less than .NET 4 when doing an F5 debug. Switching the projects to .NET 4 does fix this weird behavior, but you may not want this for .NET 2 applications that you don't want to use the newer runtimes/BCL.
However, you can still correct this behavior. You can run manually use Debug -> Attach To Process and select devenv.exe and that will load the modules and symbols. So, you can either have a second instance of Visual Studio 2010 already open and simply attach, or you can run it on debug (Run External Program), Detach, and Re-attach to get the modules to load.
I thought this was something wrong with my environment settings, because my install of Visual Studio is very customized, so I thought there might have been some sort of setting, conflict, or file difference, but it seems to just be a weird behavior in the Visual Studio 2010 debugger. I would be curious to see if anyone from the Visual Studio 2010 team could investigate this a bit further.
If the breakpoints are properly resolved, then it must hit properly.
Please check the following.
Is the breakpoint resolved properly or not. If it's properly resolved, it will be displayed in red during debugging sessions. Otherwise the red will turn into a disabled state (with a yellow exclamation mark with a grayed circle).
Why don't you put a breakpoint where the object is being constructed and debug through it? So that you can ensure that your construction code is working well. You can step through (F11) to get inside the constructor.