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.
Related
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>
I'm appealing to the wisdom of the crowd here, trying, in this case, to avoid the code less traveled.
I created a Visual Studio project template, but now find there are a couple of things I can/should add to it, and one or two things I need to modify.
What is the "received" way, or "preferred method" of doing this: modifying the existing template directly, or opening a project using the existing template, and then saving that template-based project, after modification, as a template, perhaps overwriting the previous one (if that's even possible/allowed by the VS "ecosystem")?
I copied the extracted contents of the zipped template from C:\Users\clayshan\Documents\Visual Studio 2010\Templates\ProjectTemplates\Visual C#\folder_name\template_name.zip to another location.
Does it make the most sense to open that project, modify, and save as a template, or to simply create a new project from the existing template, and then save that "new and improved" project as a template?
RUNNING COMMENTARY
When I open the extracted template as a project, I get a warning, "Load of property 'RootNamespace' failed. The string for the root namespace must be a valid identifier." I don't know if this is to be expected in this scenario, or if I should be slightly scared.
Another funky (as in "gives me the fantods", not as in the Troglodyte song) thing is that a template won't compile, as it's got those placeholder namespace names.
I edited the existing, zipped, copied it over to the village where the VS templates live and...now when I go to start a new project, there are two identical-looking templates there: the old, and the new. The question is, which is which? It's kind of annoying having to open them to see...
The final (hopefully) weird thing about the process is that, even though I added a "Site ULR" property to the template, on creating a new project from the template, that assignment reverts to blank.
I'm getting this error for my profile build (debug build was OK).
{Directory not found for option '-L../../../Mac/Profile/lib [full path of that directory]
Library not found for -lMyLib}
When I check the path, the directory exists and the lib file libMyLib.a exists as well.
My library search path for the Profile build includes that directory $(SRCROOT)/../../../Mac/Profile/lib. I also made sure that the library was built under profile setting.
This only happens with profile build.
I'd really love to have some help although it may well be a no-brainer question.
Thank you!
EDIT: Found the solution myself
Solved the problem: In my linker path, there were two directory entries. The second one was surrounded by double quotes while the first one wasn't. Xcode4 seems to have concatenated them into a single directory entry and apparently that was garbage. After I removed the quotation marks, the linker error was gone.
Go to "Get Info" on the target. Click the "Build Settings" tab (i'm using Xcode4), and scroll down to "Search Paths", Where You delete all the values in "Library Search Paths".
There are two errors that people seem to have confused
If it is a "directory not found for option '-L/..."
That means it's a Library Error, and you might want to try:
Click on your project (targets)
Click on Build Settings
Under Library Search Paths, delete the paths
If it is a "directory not found for option '-F/..."
That means it's a Framework Error, and you might want to try:
Click on your project (targets)
Click on Build Settings
Under Framework Search Paths, delete the paths
This might happen when you move referenced files around or change the project folder name.
It was similar as above in the Library Search Paths. I found that one of my paths was missing quotes around it...
// Old path
$(PROJECT_DIR)/Google Analytics
// New path
"$(PROJECT_DIR)/Google Analytics"
I came across this error in seemingly a completely different scenario from those answers above. Hopefully some people will do what I did and find this useful even if it is a rare occurence.
I managed to get this error after having just added a new viewController to my project. As normal I added a tableview and constrained it then added and linked the delegate and datasource. I also created a property.
The weird thing that I then noticed was that as soon as I finished creating the property it was immediately linked, as if I had linked it, but before I linked it. When I clicked on the xib file and checked the links it wasn't in fact linked to the table view.
(This link appeared automatically without me needing to create it myself)
I don't know why this happened. I deleted the file and remade it with the same name but it just happened again. Giving me this error above.
The way I solved it was to create a new file, different name, and added and created the links in a different order checking at each step that this hadn't occurred. After doing this no linked created themselves and it worked.
TL DR: If you are getting this error and have recently added new view controller then check if deleting it works and if so they remake it being careful about any automatic links.
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.
I'm really really tired of other users having project errors because XCode's default class reference type is "relative to XCode folder." I know you can change it to "Relative to Enclosing Group," which is what our project is, but anytime someone creates a new classfile and forgets to change the reference type afterwards (frequently) or adds and file and forgets to change the reference type (also frequently), users who update from SVN see red file errors, even though it exists in the correct folder - just because the xcodeproj file links to it stupidly.
Is there any way to change the default? I've been looking through the preferences and can't find anything. It seems there must be ways to make XCode work better for situations other than single-user projects. I am incredibly unimpressed with its source control management, and I'm hoping maybe that's because I haven't been able to find some options. Thanks for the help.
My approach to this is to map my groups to the source file hierarchy and make sure that everything is initially set up as "Relative to Enclosing Group". In this case Xcode seems to do the right thing when you add more files or folders to the hierarchy, i.e. it maintains the "Relative to Enclosing Group" setting wherever it can.
For more info try asking on the xcode-users mailing list.
I struggled with this some time as well, yet the answer is simple:
Don't store your projects in the developer folder. Inside the developer folder everything defaults to relative to XCode Folder, while outside it's to enclosing group.
Hope it helps