Changed, updated, form is not used even though uses and project settings seem fine, old form files removed from disk.
Is this a bug in the IDE? I may just delete the form and copy it into another unit with a new name.
If it's using an old form it has to be getting it from somewhere--it doesn't appear out of thin air. Two scenarios come to mind:
1) It's somewhere where you don't realize. Search your system for files by that name.
2) Unless you do a build Delphi compiles based on timestamps. If the clock was wrong when it was compiled before the .dcu can have a more recent time and thus it gets skipped in compiling. I've hit this more than once with timezones.
A good way to find it is to first move the project to a different new folder and try to compile it. This should produce and error that will help you to find the culprit. If this does not work then it is settings like paths etc in your libraries that are at fault.
Also make sure that you deleted all ".dcu" files in the project before re-compiling.
No, it is not a bug in the IDE.
You are referencing that form in some setting in your project or environment, which you didn't find yet and which takes precedence to options you already tweaked.
Where do you need to go to resolve your problem? Well, that's difficult to say without looking at your development environment and your project settings.
I've had this happen before. It is always something referenced that I wasn't aware of.
You can do a grep for something from the form and see where it shows up.
Thanks for the input. The first one I tried, moving the files, mm2010, showed it was my code that was at fault.
Although the form/unit is not included in the project file (dpr), it is still referenced by some other unit. So the compiler links the res into the application. Look for the unit name you want to remove in other units' uses clauses.
Related
I have finally come across something that no one else seemed to have come across (at least from what I can tell). I trying to build an F# type provider using TypeProviders.SDK.
As soon as I build the solution I get the error: "FS0810, Property 'CultureName' cannot be set, \LemonadeProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs" on line 2090 and again at 3162 in the design time project of the solution.
I do not think this is useful but the Test project also fails as it can not find the LemonadeProvider.Runtime.dll. I am assuming this will get created when the Runtime project will build successfully.
PS: As of right now I am just tring to build the provided template, I have not changed the code or added anything to it. Hence I have not attached any code, but please feel free to ask for it.
The corresponding issue is https://github.com/fsprojects/FSharp.TypeProviders.SDK/issues/353
Known workarounds
Change minimum target to net461. Replace all instances of net45 with net461, except for in netfx.props, where you can just delete the lines referencing net45* frameworks (I suspect the removal of those lines isn't strictly speaking necessary).
I did this workaround but am now facing these kinds of errors: (like 2000 of them)
C:\Users\user\source\repos\HelloWorldProvider\paket-files\fsprojects\FSharp.TypeProviders.SDK\src\ProvidedTypes.fs(34,7): error FS0074: The type referenced through 'System.Attribute' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard'. [C:\Users\user\source\repos\HelloWorldProvider\src\HelloWorldProvider.DesignTime\HelloWorldProvider.DesignTime.fsproj]
I found out that the issue lied with the ProvidedTypes.fs and ProvidedTypes.fsi files created by the SDK.
The issue was solved for me when I replaced the files with the ones found in 'SDK-dsyme-patch-7' which provided compatibility for different .Net environments which was missing from the original SDK. There might be other differences but this is the one I found and it fixed the problem for me.
The files can be found under '/src/' in the dsyme patch.
The code I am referring to is as follows and has been added twice to the ProvidedTypes.fs:
#if NETSTANDARD
asmName.CultureName <- System.Globalization.CultureInfo.InvariantCulture.Name
#else
asmName.CultureInfo <- System.Globalization.CultureInfo.InvariantCulture
#endif
asmName
I am not aware if there is a new SDK that has solved the problem. But at the time when the question was asked, this is what worked for me.
At some point project identity was modified and i reflected that in code by renaming the solution, project, assembly and default namespace, with all corresponding folders - all instances of a name that i could find. I also used Notepad2 to fix the contents of solution and project files.
Note: Namespace in code was changed using VStudio's Rename feature.
Since then every time Resource.Designer.cs file gets re-generated, it pulls the old namespace in (?!), breaking the reference to automatic Resource class, which defines resource IDs:
Obviously, i try to fix this:
And in some cases it will immediately get re-generated again - you guessed it - with the old name, but sometimes(!) it will accept my edit, save it and let the project be actually compiled and run:
I've tried Clean and Rebuild commands multiple times for both project and solution, restarted VStudio, rebooted Windows.. No dice, it keeps happening.
App's TargetPlatform is 7.1, MinimumVersion is 4.3, all 5 supported architectures are enabled. VStudio - 15.5.4, .NET - 4.7.03056, Xamarin - 4.8.0.757, Xamarin.Android SDK - 8.1.3.0.
Just found this in the Similar Questions list:
Ambiguous reference intellisense error from Resource.Designer.cs. Looked promising, so i did the following:
Closed solution in VisualStudio.
Removed entirely \bin and \obj subfolders in File Explorer.
Edited Resource.Designer.cs, so it has correct (new) namespace: J7987ca.
Added 'AndroidUseManagedDesignTimeResourceGenerator' to J7987ca.csproj, as advised.
Opened the solution, and here's the result - old namespace is back:
I guess, i can start with a clean slate and re-create entire solution from scratch with a new name, but for the Love of God, why do i have to do that? And where does it pull the old name from?!
My last image shows <RootNamespace>J7980ca</RootNamespace> - the old name. I did not pay much attention to re-check that tab after re-opening solution, because such an awful glitch would never occure to me: i never had problems saving values in those VS "dialogs" previously.
It turns out that changing Default Namespace in Project Properties does not take effect!
I verified it twice.
Mind you, Assembly Name was saved, so i'm at a loss of wits to explain, how all this is happening.
As soon as i edited .csproj in Notepad2 re-opening the solution happily put proper namespace into Resources.Designer.cs and allowed compilation.
I'm a little late to this, but I ran into this issue recently and was able to fix it by updating both <RootNamespace> and <AssemblyName> tags in the Android csproj file.
Then cleaning the sln and closing Visual Studio and deleting bin, obj, and the old Resource.Designer.cs file (from the directory using the File Explorer and not by removing it from the csproj).
You also need to change it in the assembly line, not just the namespace.
For example
[assembly: global::Android.Runtime.ResourceDesignerAttribute("com.companyname.TestBottomSheetDialog.Resource", IsApplication=true)]
namespace com.companyname.TestBottomSheetDialog
I am editing a visual studio MVC Solution. I have edited all the files, assemblies and Project Name etc. But in the end, it is build successfully but when I am going to run this solution it shows an error like shows in the picture.
Actually, TestSolution was the name of my solution which I've changed with RealEstateErp.Now when I am going to search "Using TestSolution " , I don't find anything. Now, what should I do to overcome this problem? Any kind of help will be appreciated.
when they make drastic changes like the namespaces and dll names, the first thing people forget is to delete the old dlls.
I would start with that, make sure you delete everything in bin, obj and all temp files which reside in Windows\Microsoft.Net and then Framework and Framework 64.
Next, check your global.asax file, specifically the front end part. You get to it by right-clicking the global.asax file and selecting the "View markup" option, that one always has a reference to the old namespace and always gets missed.
Finally, make sure you delete all the using statements referring to the old namespace. You don't need those and they will cause a compilation error like the one you are seeing, because that particular namespace does not exist anymore.
Actually, It was on the Web. Config under View Folder.
I've Updated it with the latest solution name and now it works fine for me.
Could you do Ctrl+Shift+F and search your whole solution about Using TestSolution?
You probably will find the word left somewhere.
First of all, I've never worked on iOS, so this may or may not be a stupid question, I don't know :)
I have an iOS App, and I need to run it.
In the 'Project Navigator' I have a folder/package called 'Reuse and Platform Libraries'. Inside, I have another four folders but 3 of them seem like missing.
I am not sure if this is the case. I've tried googling their name but without results so I assume they are not some open source libraries.
Can someone clear this up for me? Do I need to install some XCode packages?
Thanks!
I suggest you search the folder of the project for those files, sometimes when copying a project the paths get screwed up because they were set as absolute paths and not relative paths.
If you can't find the files, it's most likely that the library is a private one used by the previous developers, and usually kept out of the project folder so they probably forgot to send it along. I'd suggest simply asking them to send the files over :).
There is also a slight chance they are not needed to run the file, in which case, just deleting them from the sidebar should make the project run.
I'm at a complete loss as to what I did to cause this:
For the second time since I started using XCode about a month ago (my first time seriously using it after taking one class several years ago) I try to run my project and the next thing I know I have errors because I have duplicate references. I looked at the project and it appeared that most of the files in my project had duplicated themselves, however I discovered that they are not duplicate files just duplicate references. This happened to me today when I tried to build on an actual iphone for the first time but it also happened to me a few weeks ago while using the simulator. Neither time do I recall doing anything unusual. I have built and tested the project probably 100+ times and normally all goes ok. I was able to fix it the first time but I think I have made it worse this time and am probably going to add the files back into a new project. My co-worker also mentioned this happening to him (he has about as much experience with xcode as I do). He told me he ended up with files nested in folders (groups?) nested in other folders about 20 deep.
My question is this: Does anyone know what I may have done to cause this. I would really like to avoid this problem in the future since it is proving to be quite a headache. Any advice would be greatly appreciated.
E.T.A. xcode version 4.6.2 (possibly an earlier version the first time it happened)
Try this instead:
Highlight all the duplicate files
Right click on one of the files and press "Delete"
When prompted for which delete option, click "Remove Reference"
Also you asked for "any advice".
If you aren't already using git source control in your Xcode projects, start now.
You can spot many mistakes like this earlier and fix them more easily using git.
When you add files as a copy, the Xcode project navigator shows added files with an A and modified files with an M.
If the file is inside a closed group folder, the folder shows an A.
If you add a reference without a copy the project navigator won't show an A but MyApp.xcodeproj will show M.
In Xcode you can discard a change before committing it.
In the case below, you would discard changes to all added or modified files.
Typically you review and commit changes frequently.
Using a gui tool such as SourceTree, you have a good chance of spotting an accidental change before you commit. For example, you can see changes to the project file.
If you accidentally commit an unintended change, you can go back later and reverse a commit.
By committing frequently, you have more control over which changes you undo and which ones you keep.
References:
http://www.raywenderlich.com/13771/how-to-use-git-source-control-with-xcode-in-ios-6
http://git-scm.com/doc (scroll down to see videos)
http://www.sourcetreeapp.com
http://gitimmersion.com
I had the same 20 deep nesting of my main folder of images. If its not a bug its very strange behaviour. I just backed it all up !! Then I opened the folder in finder, found the point at which it was starting to nest and deleted it.
I did a rebuild, but I don't think Xcode even noticed. It made no difference to the size of my app so Xcode was not putting unnecessary files in the binary.
This happened to me when I imported a file. Suddenly I had two nested directories containing what looked like copies of all my files. The compiler complained about duplicate classes.
I found a solution, but it's a ball-ache and a time sink.
1: Click on your project in the navigator to open up the project settings in the main view.
2: Open the 'Compile Sources' accordion entry.
(This allows you to see which files are being used in the compilation process.)
3: Find any duplicates in here and delete them.
(At this stage your project should compile again.)
4: In your navigator view, slow-double-click one of the files that's duplicated there. This should allow you to rename it. Change the name (not the extension) slightly.
5: You should notice that the copy becomes red. Select it and hit delete.
(This avoids the delete operation removing the file from the 'Compile Sources')
6: Rename the original file back to its original name again.
7: Repeat from 4 until done, or until bored.
8: Explain to your boss why a simple copy change took half a day.
This process can be optimised up by first renaming all duplicated files, then deleting the duplicates all at once. However this means that you can't test for successful compilation between steps, which allows you to narrow the culprit down to a single file. And takes even more time.
If compilation fails, ensure all the files you need are still in the 'Compile Sources' section, as this process can cause them to be lost from there. The compiler will normally give some reasonable errors about missing classes and variables, but a missing AppDelegate will produce a more confusing error.