Why might VS2019's Go To Implementation be showing duplicate references? - visual-studio

The behaviour of the Go To Implementation function accessed from the editor context menu or by clicking Ctrl-F12 in Visual Studio has somehow changed in my installation of VS2019.
It used to be that when I used it with the cursor on a method name reference, it would jump directly to the method's implementation unless there were multiple implementations; then it would show them in the Find Symbol Results window.
But something has changed and now it always shows the Find Symbol Results window even if there is only a single implementation. Furthermore, it shows a duplicate of the single implementation or of each if there are more than one. The screenshot shows this where you can see that the same method definition is listed twice with the same Project, File, Line and Column details.
Does anyone have any idea why this might be happening? Could it be some incorrectly cached data causing this? Where might such data be cached? I have cleared my temp files, and deleted contents of folders named *cache in any C:\Users\xxxx\AppData\Local\Microsoft\VisualStudio\16.0* folders but this hasn't made a difference.

The duplication can be caused when there are more than one TargetFrameworks e.g.
<TargetFrameworks>net5.0;netstandard2.0</TargetFrameworks>

Related

Visual Studio: Open up a symbol source file prior to debugging and set breakpoint

I have a project where the referenced assemblies have symbol files available. Both pdb, and the source files themselves. (they are all my own libraries). The symbols are all listed in the Tools / Options / Debugging / Symbol marking their locations. Thats all fine.
But it's working with them, i'd like to know:
Is there a way in Visual studio to set a breakpoint in a file of the symbol before having to debug line by line to get to the code in question.
To be clear, if i step line by line i can eventually hit the source (because of using the symbol files) code i'm after. But some times getting to that location is not easy, because it's so nested within multiple symbol files. BUT once i eventually step deep enough and find the code, i can set the breakpoint, and from there on stop and start the main application and get to that location without trouble. The file code and all is even listed in the open file pane, for easy view.
Is there any way, if i know the file and line of code i want to break at, open that file in VS and set the breakpoint directly?
Hopefully i was clear in the description. Let me know if i need to reword.
tx
I bet the code you want to put a breakpoint is in a function (;)) so I would use a New breakpoint option from Visual Studio. This allows you to put a method name that VS should break on when entering the method (so basically on the first { after the function name).
After pressing CTRL+B you will be presented with the dialog
Here you specify a function name you want to put a breakpoint on.
You can just specify just the name (like. AppendText) or fully qualified name (with namespace - System.Windows.Forms.TextBoxBase.AppendText). If you want to narrow it down to a specific module user module_name!function_name syntax. If needed you can specify on which of the overloaded function you want to break on.
All this info you can get by hovering over an (i) icon on this dialog.
OK. Knew there had to be a way. And it's very simple.
As stated, if you have the symbol and source available for the Nuget packages you are working with follow these steps:
open the main project in question in Visual Studio.
In VS, click File / Open File...
Under your PACKAGES Folder, locate the package for the reference you want to set breakpoint.
In that package locate the source code folder that was packaged along with the pdb file.
There you will find the source code. Now locate the file you want the breakpoint placed in. Click that file to OPEN the file in Visual Studio.
That file is now OPEN in your VS viewer, but it is not included as a new file in your project (good thing).
Place breakpoint where you want.
Run solution. Now you don't have to step through your entire solution to get to the code you wanted to review with that breakpoint!
what a relief!

Xcode complains about a non-decodeable instance of a view

Xcode complains like so about an old project:
Could someone provide a way to somehow fix this issue?
At this point I can only say that you can open your ManMenu.xib in the text editor and go looking for your ABFadingImageView class and see where the error is. It either has a null value or a null reference that is not accepted.
You can probably skip all the menu items. The xib file is loaded with it. At the beginning and end you see the code that is interesting for you. It is not a guarantee that you can fix it, but in the text editor you can change the xml code.

Why does my project continue to look for an obsolete subfolder?

I changed the name of a subfolder in my project from "SOs_Forms" to "SOs_Pages"
Now, though, on noticing that several places in my project still referred to the old "SOs_Forms" I changed those to the updated name. But now the project won't compile, saying "Cannot resolve symbol 'Bla'" and then offering, through intellisense, to let me add the reference to the old subfolder/namespace.
So now I have both "SOs_Forms" and "SOs_Pages" referenced throughout my project; it seems that either/both are accepted at times, but other times it must be SOs_Forms, which no longer exists!
The odd thing about it being, if I acquiesce and allow the "old" subfolder namespace ("SOs_Forms") to be added so that the project will compile, and then right-click the formerly recalcitrant object name and select "Go to Declaration," it pops up "in \SOs_Pages" for both the xaml and the xaml.cs file. IOW, it knows it lives in "SOs_Pages" and yet forces me to add a reference to "SOs_Forms" so that it can be found...weird!
How can I tell the project once and for all that SOs_Forms is gone and is not coming back?
If you do a global find and replace you should resolve this issue (I have had to do it a few times).
Firstly before you do anything like this ideally you should have your code source controlled, and checked in so you can easily un-do it. If you don't have a source control system then stop everything and get one, seriously. (but if you can't at least take a copy of your code as it is and place it somewhere safe)
Now go to edit, find and replace, replace in files. Now type in the old namespace, then the new namespace. Then hit the go button.
That should solve it for you.

VS2010 Compile Error

Apologies. I am sure I should know where to look to deal with this but I do not:
The error below has appeared in my solution. I am not aware of why.
The item
"obj\Release\ScruffyDuck.AirportDesignEditor.MainForm.resources" was
specified more than once in the "Resources" parameter. Duplicate
items are not supported by the "Resources" parameter. Airport Design
Editor
Perhaps someone would be kind enough to put me out of my misery and tell me where to look.
Thanks
OK I found it. I have no idea how it happened. However it might be useful for the future. MainForm has a number of files containing different parts of the class. The main part has all the designer code and so on. Somehow a .resx file got created on one of the partial class files along with an InitializeComponent() method. Removing the extra .resx file got as far as reporting the duplicate method and removing that allowed the solution to compile again. It seems that though the file names are different (the error was in MainForm.EventHandlers) the two resx files are treated as the same even though they have different names.
I am now getting some exceptions but at least I can get the code running in the debugger again.
I think you'll have to open your .csproj file, and look for that file name. It sounds like ScruffyDuck.AirportDesignEditor.MainForm.resources is appearing more than once. Just remove the duplicate node (.csproj files are just xml).
Just remove obj directory from HD manually.
Clear solution from Visual Studio (Right click on project in SolutionExplorer and select "Clear")
Rebuild solution.
Cause could be a fault of generated resource file, due some conflicts happened in your project.
Should work.
Regards.

Why does my T4 template append a number to the file name?

Why do my T4 templates sometimes append a number to the output file and sometimes not? For instance, in one case I might have a template file called Foo.tt and I'll get an output file of Foo.cs. In other cases, I'll get an output file of Foo1.cs. In every case, there is no other Foo.cs file that might be causing it to append a number. In other words, it is definitely not the result of any obvious file name conflict.
I'm a deeply anal retentive developer, so I'd sure love to know how to get rid of that useless numeric suffix.
This happens when Visual Studio gets itself confused and briefly decides that it can't use Foo.cs as the output for some reason (usually hallucinatory), so it will use Foo1.cs instead, and then insists on remembering this setting.
The fix is to open the .csproj file in a text editor and locate the Foo.tt entry. This should have a sub-element called LastGenOutput. Change this back to Foo.cs, save the project file, and reopen it in VS.
And then -- sigh -- wait for it to happen again. You can see http://social.msdn.microsoft.com/Forums/en/linqtosql/thread/0c0f77a6-d712-43d2-a990-555df7960123 for more details, though nobody seems to be able to explain what causes VS to get into this state or how to stop it doing so...
#itowlson's answer really helped me out, but I discovered a slightly simpler workaround that I thought I'd share.
If you have:
Filename.tt
└── Filename1.cs
Just rename Filename.tt to Filename2.tt:
Filename2.tt
└── Filename2.cs
And back to Filename.tt again:
Filename.tt
└── Filename.cs
Voilà.
I've discovered something in VS2019 that might explain one potential cause of the issue.
In the CSPROJ file, VS expects a TT file be included using <Content Include="Generator.tt"> tags. When adding a TT file to a project via Cut/Copy/Paste using the contextual menu items in the interface built into VS, VS may sometimes use the wrong XML tag, such as <None Update="Generator.tt">. This will be despite the fact that if you open the Property sheet for the TT file, it will show 'Content' as the build action.
Open the CSPROJ file, and if you change the <None> tag to <Content> and also the Update attribute to Include, then restart VS, the issue appears to go away.

Resources