Arodicus
07-19-2011, 09:48 PM
These were so useful I thought I'd share. Hopefully some kindly admin might make it a sticky so folks can find it easier.
Compiler error: "Unable to locate {some library}.swc" when doing a full build.
Cause: Flex, for reasons unknown, often ignores the "compile order" options in the workspace prefs, and will often attempt to compile your projects even though your RSL library projects are not built yet.
This usually happens during an initial import-build of an exisiting project, but this also occurs during normal builds if one of your RSL libraries had a compiler error and didn't compile. Such errors are SUPPOSED to appear first in the list but often do not.
Fix: Explicitly Build your libraries first. Curiously "Clean Build" on the entire project will work once this is done, making one wonder how "Clean" it really is.
Compiler error: Bogus "Error 1046: Type was not found or was not a compile-time constant: Matrix3d"
Cause: Often triggered when switching Flex versions, especially when existing framework SWCs are either removed or conflict within the target bin directory. Appears to be related to the wrong Manifest files being loaded.
Even though the version check is supposedly only for the javascript/html file, the compiler uses that setting to create the initial manifest file for the whole deployment. Go figure.
Fix: manually set the "Check Version" to "10.0.0" (or later) under Project Properties:Compiler. If this option is greyed out you may need to momentarily turn on "Generate HTML wrapper file" in order to edit it, or (in the case of Libraries) manually edit the .actionScriptProperties file for the project so that it reads htmlPlayerVersion="10.0.0".
Note: it may also help to explicitly set the SDK version to a hardcoded value (eg "3.2" or "4.5") as well, for the same reasons. It's on the same properties panel (or file) as the version checker is.
Compiler error: Bogus "Requires Adobe LiveCycle 2.6" which won't go away.
Cause: Numerous - I'm asuming you are not really using LCDS of course, or at least have the correct version!
Note: Also see "Removing Compiler Problem Markers" (below) which seems to often occur with this error, especially in Flex 2 and 3. You might fix the problem, but the error message won't go away.
In Flashbuilder 4, under Project: Flex Server, try switching to Blaze DS instead. Blaze is the kinder, gentler version of LCDS.
In 3 or 4, under Project: Flex Server, check that your server root URL is actually correct for your project. This often happens when your server root is on a non-standard port (not 80 or 8080), and the project is looking at the right url but the wrong port. For some reason this error appears if you are on 80 or 8080, but on any other port it just throws a minor warning if the server isnt running.
Fix: Change the setting, either by manually editing .flexproperties serverRootURL="https://localhost:{port}/{myProject}" eg serverRootURL=https://localhost:8443/MyGame (https://localhost:8443/MyGame) or by correcting the "Root URL" on the properties page for the project under "Flex Server"
Java error during compile: "Removing Compiler Problem Markers"
Cause: Corrupted .markers file. Frequently occurs in Flex 2, 3 and 4 as a result of other errors causing the compiler to freak out and abort a compile without wiping its dirty little bottom. Once this happens you can't compile even if the errors are fixed.
Main symptom is that even though a problem is fixed, any compile errors remain on the screen and simply wont go away. Typically you alaso see a java alert appear that may bitch about issues removing compiler problem markers, Java.util.string being null, etc.
Another warning sign is an identical compiler error or warning that appears multiple times, especially if it adds a new copy of itself every time you attempt to compile. This is a sure sign your .markers file for the project is corrupted.
Fix: Delete the .markers file for the project. Open \{WORKSPACE}\.metadata\.plugins\org.eclipse.core.r esources\.projects\{PROJECT} folder (fill in the correct pathnames) and delete the .markers file. This resolves the issue. Also it tends to nuke your debug stops and markers... c'est la vie, at least you can compile.
If you really dont give a damn about breakpoints and other markers, simply search .metadata for ".markers" and delete all the files it finds. Quick and dirty.
Warning: "The swc ... has style defaults and is in the library-path, which means dependencies will be linked in without the styles. This can cause applications, which use the output swc, to have missing skins. The swc should be put in the external-library-path."
Cause: You have a RSL Library that references an Adobe skin file (mx is usually the culprit) and has its framework linkages marked as "merge into code" instead of "external" or "use framework default (external)".
Fix: Go to your Library's Project Properties: Flex Library build Path, and set framework linkage to "external" or "use framework default (external)". As if by magic the problem will go away and your Library will also drop in size by a megabyte or so.
I hope this list helps someone else getting these annoying compiler bugs.
Compiler error: "Unable to locate {some library}.swc" when doing a full build.
Cause: Flex, for reasons unknown, often ignores the "compile order" options in the workspace prefs, and will often attempt to compile your projects even though your RSL library projects are not built yet.
This usually happens during an initial import-build of an exisiting project, but this also occurs during normal builds if one of your RSL libraries had a compiler error and didn't compile. Such errors are SUPPOSED to appear first in the list but often do not.
Fix: Explicitly Build your libraries first. Curiously "Clean Build" on the entire project will work once this is done, making one wonder how "Clean" it really is.
Compiler error: Bogus "Error 1046: Type was not found or was not a compile-time constant: Matrix3d"
Cause: Often triggered when switching Flex versions, especially when existing framework SWCs are either removed or conflict within the target bin directory. Appears to be related to the wrong Manifest files being loaded.
Even though the version check is supposedly only for the javascript/html file, the compiler uses that setting to create the initial manifest file for the whole deployment. Go figure.
Fix: manually set the "Check Version" to "10.0.0" (or later) under Project Properties:Compiler. If this option is greyed out you may need to momentarily turn on "Generate HTML wrapper file" in order to edit it, or (in the case of Libraries) manually edit the .actionScriptProperties file for the project so that it reads htmlPlayerVersion="10.0.0".
Note: it may also help to explicitly set the SDK version to a hardcoded value (eg "3.2" or "4.5") as well, for the same reasons. It's on the same properties panel (or file) as the version checker is.
Compiler error: Bogus "Requires Adobe LiveCycle 2.6" which won't go away.
Cause: Numerous - I'm asuming you are not really using LCDS of course, or at least have the correct version!
Note: Also see "Removing Compiler Problem Markers" (below) which seems to often occur with this error, especially in Flex 2 and 3. You might fix the problem, but the error message won't go away.
In Flashbuilder 4, under Project: Flex Server, try switching to Blaze DS instead. Blaze is the kinder, gentler version of LCDS.
In 3 or 4, under Project: Flex Server, check that your server root URL is actually correct for your project. This often happens when your server root is on a non-standard port (not 80 or 8080), and the project is looking at the right url but the wrong port. For some reason this error appears if you are on 80 or 8080, but on any other port it just throws a minor warning if the server isnt running.
Fix: Change the setting, either by manually editing .flexproperties serverRootURL="https://localhost:{port}/{myProject}" eg serverRootURL=https://localhost:8443/MyGame (https://localhost:8443/MyGame) or by correcting the "Root URL" on the properties page for the project under "Flex Server"
Java error during compile: "Removing Compiler Problem Markers"
Cause: Corrupted .markers file. Frequently occurs in Flex 2, 3 and 4 as a result of other errors causing the compiler to freak out and abort a compile without wiping its dirty little bottom. Once this happens you can't compile even if the errors are fixed.
Main symptom is that even though a problem is fixed, any compile errors remain on the screen and simply wont go away. Typically you alaso see a java alert appear that may bitch about issues removing compiler problem markers, Java.util.string being null, etc.
Another warning sign is an identical compiler error or warning that appears multiple times, especially if it adds a new copy of itself every time you attempt to compile. This is a sure sign your .markers file for the project is corrupted.
Fix: Delete the .markers file for the project. Open \{WORKSPACE}\.metadata\.plugins\org.eclipse.core.r esources\.projects\{PROJECT} folder (fill in the correct pathnames) and delete the .markers file. This resolves the issue. Also it tends to nuke your debug stops and markers... c'est la vie, at least you can compile.
If you really dont give a damn about breakpoints and other markers, simply search .metadata for ".markers" and delete all the files it finds. Quick and dirty.
Warning: "The swc ... has style defaults and is in the library-path, which means dependencies will be linked in without the styles. This can cause applications, which use the output swc, to have missing skins. The swc should be put in the external-library-path."
Cause: You have a RSL Library that references an Adobe skin file (mx is usually the culprit) and has its framework linkages marked as "merge into code" instead of "external" or "use framework default (external)".
Fix: Go to your Library's Project Properties: Flex Library build Path, and set framework linkage to "external" or "use framework default (external)". As if by magic the problem will go away and your Library will also drop in size by a megabyte or so.
I hope this list helps someone else getting these annoying compiler bugs.