Any idea on what this means and how I might start to resolve?
Incompatible magic value 0 in class file _GrailsPackage_groovy
I'm on a Windows 7 64x box, with JDK 1.6.0_23.
Usually to do with incompatible Java class versions (e.g. class was compiled with 1.5 and run with 1.6), although you usually get a specific number with the magic value instead of 0.
Check you have no other versions of Java around, and maybe do a grails clean and/or delete everything in your /.grails folder (will mean it'll have to download plugins etc again).
What I think happened is I had created my plugin a while ago for testing purposes, deleted it, and then recreated it recently. I'm guessing something in my .grails directory in my users folder was messed up.
We encountered a similar issue with a JSP file. If this file is a JSP, delete the class file. It will get re-compiled the next time someone touches the file, and the error should vanish.
Related
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 was assigned to make a small modification in a Delphi project.
To register that mod, my boss told me to increment the build number in Project options > Version Info.
I did that, but after compiling and building, when I look at the file properties, file version is not updated. The exe file was indeed compiled (I checked the modification date and it matches the time of build). The version number in the final EXE is unchanged, and not equal to the number I set in Version Info tab.
When I search Google about this, the only results I could find was tutorials to use this version feature and people with problems enabling it.
I tried reopening the project, deleting the generated EXE and rebuilding, removed the .RES file (the build fails because there's no RES file) and commented out the {$R *.RES} directive (no Version Info is included at all).
I'm not the original developer of this project, and the original one is not available anymore.
I think this could be related to this post, but it is from another Delphi version, and I couldn't find a dproj file in my project.
So, anyone knows whats wrong? Is it some kind of bug or am I missing something? Is there another option I should change so this option takes effect?
Use build instead of compile... it have no shortcut, you find it in Project menu (under compile)
I have a set of components in split runtime/designtime packages for Delphi XE2. I've had these for a long time and have had no problems like what I'm having now. I added a new basic control called TJDWebcam. All was fine until I decided to change the type name to TJDWebcamView. I did a find/replace in the main source unit where I have this class, and made some other changes, also in the design-time package's registration unit.
The problem is that now when I build the run-time package, I get a message saying that it requires its self (It requires a package JDComponents which is exactly the same package). I've uninstalled the package, and tried to re-build, but same error.
Here's the specific message I'm getting...
Add JDComponents.
JDComponents contains implicit unit(s) uPickFolder, JDCommon,
JD.VSample, JD.VFrames, NativeJpg.
...and every unit in the package which are OK to be there. The problem didn't start until I changed this control's type name and went to re-compile.
Now if I ignore that message and hit 'Cancel' everything seems to install fine, despite the warning that it "might cause errors".
For what reasons might it be doing this? And how to go about fixing it? I'd hate to have to post my entire component library to be debugged.
PS - My library makes use of the delphi version suffix (160 for XE2) and my own version suffix (2), so the package names actually read JDComponents.160.bpl.2 and DCLJDComponents.160.bpl.2.
UPDATE
I managed to get it installed, please see my answer below.
After doing these following steps, I managed to get it re-built successfully:
Uninstalled the package
Deleted all DCU's, package, and anything compiled
Restarted the PC
Re-build everything
So the source of the problem is still unknown, but most likely somewhere in a compiled file (DCU or the package), it was still referring to this old type name from before it got changed. When the compiler came across this, it got confused and told me I had to include this other package, which is actually the same package.
I haven't touched any of my Blackberry projects for about 2 weeks now. Today I had to make some modifications, but when I tried to compile and run my code I got an error message like the following (this has been simplified):
JavaBuilder handling CoreException
org.eclipse.core.runtime.CoreException: File not found: C:\Program Files\etc etc etc\ClassName.class
And this error pops up for every single one of the files in my project.
I'm not a Java professional by any means, but I'm pretty sure this has something to do with my build path. What do I have to do? I did a system restore a little while back don't know if that has anything to do with this.
Thanks a lot.
Problem solved. For some reason alot of the folders in my project's folder were duplicated (ie: mainpackage, mainpackage(2)), so each one of my class files had a twin. Eclipse didn't tell me this, instead it just decided to say "I can't find the files" even though they were there. Not a very useful error message.
So I deleted mainpackage(2) and now it runs fine.
Thanks again for the help.
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.