We have built an application that uses packages and components. When we debug the application, the "Event Log" in the IDE often shows the our BPLs are being loaded without debug information ("No Debug Info"). This doesn't make sense because all our packages and EXEs are built with debug.
_(each project) | Options | Compiling_
[ x ] Assertions
[ x ] Debug information
[ x ] Local symbols
Symbol reference info = "Reference info"
[ ] Use debug .dcus
[ x ] Use imported data references
_(each project) | Options | Linking_
[ x ] Debug information
Map file = Detailed
We have 4 projects, all built with runtime pacakges:
Core.bpl
Components.bpl
Plugin.bpl (uses both #1 & #2)
MainApp.exe (uses #1)
Problems Observed
1) Many times when we debug, the Components.bpl is loaded with debug info, but all values in the "Local Variables" window are blank. If you hover your mouse over a variable in the code, there is no popup, and Evaluate window also shows nothing (the "Result" pane is always blank).
2) Sometimes the Event Log shows "No Debug Info" for various BPLs. For instance, if we activate the Plugin.bpl project and set it's Run | Parameter's Host Application to be the MainApp.exe, and then press F9, all modules seems to load with "Has Debug Info" except for the Plugin.bpl module. When it loads, the Event Log shows "No Debug Info". However, if we close the app and immediately press F9, it will run it again without recompiling anything and this time Plugin.bpl is loaded with debug ("Has Debug Info").
Questions
1) What would cause the "Local Variables" window to not display the values?
2) Why are BPLs sometimes loaded without debug info when the BPL was complied with debug and all the debug files (dcu, map, etc.) are available?
I would describe my issue with it.
I dynamically load package using LoadPackage function.
I can see in SysInternals.com Process Monitor that packagename.DCP got open and read succesfuly after LoadPackage processed - no file I/O failed, no attempt to find it in wrong places, nothing suspicious. So perhaps there is some construct in DCP that makes IDE debugger go nuts. I long for times when Turbo Debugger was available for Delphi.
BTW, same is for packagename.RSM if developer creates such.
Then (while paused at breakpoint or Step Trace) i open View / Debug Windows / Modules and see last module is mine - and it has empty "symbol information" cell. I right-click it, choose "Re-load symbols" action - and here it is, from now on i can debug.
PS. Dunno if that would help me to debug initialization sections though - hopefully "break on load" menu item would work even with dynamical LoadPackage calls...
PPS. It does work indeed, even across IDE restarts. So now i am alerted at BPL loading with CPU View, i strike CTRL+ALT+M, scroll to bottom to find my BPL, r-click to Reload Symbols, press Enter, then close Modules and CPU Views and strike F9 (Run). After initialization sections completes i am again alerted by CPU View - just few JMPs before exit out of LoadPackage - so i close CPU View and stike F9 yet again. Quite tedious, yet still better than IDE restart.
We have encountered a similar issue in our project. Unfortunately we have dozens of bpl so we cannot merge them in one.
This issue appeared after we migrated to XE2 and changed the folder structure of our compile target.
While it is difficult to say if newer versions of Delphi introduced the issue or not, we could fix the issue by adding the folder where the bpls are compiled in the path environment variable. Using the path override function of the IDE. This type of configuration was not necessary in Delphi 2010...
This non-official tool fixes many issues with Delphi. It fixed the module loading without debug info for me. All the credits to magicandre1981.
You have to build your separate packages with debug info, and you will eventually want to build them without debug also - so you will have both in 2 spots. Then you want to build your app project with debug info. Check your paths to ensure that you are including the debug-enabled package source in your debug project builds. It sounds like you may be including packages that were built without debug because you are including from the wrong source. You have to make sure you don't have both paths included, leaving Delphi to select what to include if it finds the same package in two places.
For our particular situation we were able to fix the issue by combining the Core.pbl and Components.bpl into a single BPL. Now all modules are loaded with debug info and the occasional issue where the Locals Window wouldn't display values for the variables is resolved.
This problem might be releated to QC#109291:
When Delphi IDE start introduce .dproj file and build configuration with option sets, it improve the project release management a lot.
However, it also has a side effect that is hard to replay and catch and I thought it was bugs in IDE. The problem should have always confuse the users where some project is not able to debug in IDE debugger. Even we check all the related settings the compiler and linking options in project, the debugger won't activate on the project. Some project works and some project doesn't. We even regard is to be memory problem or cpu problem.
I notice the problem is due to the .dproj file setting doesn't store correct information. If the related .dproj file has something like this:
<PropertyGroup Condition="'$(Config)'=='Release' or '$(Cfg_1)'!=''">
<Cfg_1>true</Cfg_1>
<CfgParent>Base</CfgParent>
<Base>true</Base>
</PropertyGroup>
<PropertyGroup Condition="'$(Config)'=='Debug' or '$(Cfg_2)'!=''">
<Cfg_2>true</Cfg_2>
<CfgParent>Base</CfgParent>
<Base>true</Base>
</PropertyGroup>
<Import Project="Release.optset" Condition="'$(Cfg_2)'!='' And Exists('Release.optset')"/>
<PropertyGroup Condition="'$(Cfg_1)'!=''">
<CfgDependentOn>Release.optset</CfgDependentOn>
</PropertyGroup>
<Import Project="Debug.optset" Condition="'$(Cfg_1)'!='' And Exists('Debug.optset')"/>
<PropertyGroup Condition="'$(Cfg_2)'!=''">
<CfgDependentOn>Debug.optset</CfgDependentOn>
</PropertyGroup>
The Release.optset bind to Cfg_2 and Debug.optset bind to Cfg_1 but Release configuration is using Cfg_1 and Debug configuration is using Cfg_2.
When build the project, the debug info will not generate for in debug configuration but generate on release configuration.
A workaround solution is open .dproj with any text editor but not Delphi IDE, and update to:
<Import Project="Release.optset" Condition="'$(Cfg_1)'!='' And Exists('Release.optset')"/>
<PropertyGroup Condition="'$(Cfg_1)'!=''">
<CfgDependentOn>Release.optset</CfgDependentOn>
</PropertyGroup>
<Import Project="Debug.optset" Condition="'$(Cfg_2)'!='' And Exists('Debug.optset')"/>
<PropertyGroup Condition="'$(Cfg_2)'!=''">
<CfgDependentOn>Debug.optset</CfgDependentOn>
</PropertyGroup>
I found in the .dprj file one line in the Cfg_2 détails with value Debugger_LoadAllSymbols which was set to false. I did set it to true. Problem solved. Maybe not similar to your case, but may help.
<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''">
...
<Debugger_LoadAllSymbols>true</Debugger_LoadAllSymbols>
...
</PropertyGroup>
Related
On building my code i cannot see the debug points in the pages.Only the page which is open while building shows the debug points.Also, The breakpoint is not getting hit and CPU window is opening by default where debug is set. I searched for the same and found this following statement on Embarcadero page (http://docwiki.embarcadero.com/RADStudio/Tokyo/en/CPU_Windows_Index):
The CPU window also opens automatically whenever program execution stops at a location for which source code is unavailable. For example, the debugger cannot open the source file if you link a DLL (Windows) built with debug information but do not include its source file in your project, or if you place the source file in a directory not specified in your project.
I also tried following things:
When I create a new project, put a breakpoint, it hits (no CPU
window opens up in this case).
When I modify the original code (like just put ShowMessage('Hello World');) where debug point is not
hitting, message dialog appears but debug is not hitting.
I
uninstalled and installed XE7 again, but problem persists.
Tried
cleaning the project, but did not work.
Please help me in fixing this problem. Thanks in advance!
As i also had a lot of problems with getting my debugger to work, so i made myself a list of what has to be checked. So here are some things you could try:
use the "debug" buildconfiguration of your project, which should be configured like this
searchpath matches your actual sources
"local symbols" is true
"with debug dcus" is true
"debug-information" is debug-information
"optimization" is false
one time i also had to check "remote debugging symbols"
try to close the ide and reopen it with just one project
if you use devextension, go to devextensions options
under compilation -> check "release compiler unit cache of other projects before compiling"
under extended ide settings -> check "disable package cache"
in delphi options under "debugger options", "integrated debugging" has to be true
(but sometimes it helps to uncheck this, close the ide, reopen and check again)
I hope, this also helps you
In one of my projects, I can't get breakpoints to work as expected.
The problem is that the CPU window opens when the breakpoint is reached. The Event Log correctly indicates the source line number with the breakpoint and the name of the file with the breakpoint indicated in the Event log matches the name and path of the source file open in the editor (the one where I placed the breakpoint).
However, when I try to inspect variables or view watches, I am told that the variable is undeclared. After the first breakpoint is reached, I can't set any additional breakpoints (the breakpoint is displayed as invalid -- a red dot with an X), even if it is the next line after the breakpoint (with a green arrow displayed). The Event Log indicates that the module has debug info.
I have tried the following:
deleting the DPROJ file and letting Delphi recreate it
"Cleaning the project"
verifying that the debugging settings for the project are consistent with those for other projects that do debug correctly
deleted all the dcus for the project and verified that Building the project put them in the expected location (which is the same folder as the EXE).
I tried the solutions here: Delphi2010-IDE keeps stoping on CPU debug window
I have verified that Debug Information and Local Symbols are enabled.
I tried the suggestions here: Delphi: why breakpoints from time to time are not usable (green highlighted line on IDE)?
Please offer suggestions regarding how to get the standard debugging functionality.
Try add source files to the debugger source path in project options under debugger.
Try disable runtime packages and add sources from runtime packages to project.
I am trying to resolve this compile error, occuring only in Debug config, and only in the case described below:
[dcc32 Fatal Error] MyIndyTCPChannel.pas(22): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil
I am working on a very large Delphi codebase, with 2.5 million lines of in-house code, and 3 million lines of component code, which includes several large commercial Delphi component suites (Developer Express, TeeChart, and others), and a large number of open source delphi components as well, plus a fairly large in-house developed set of components, numbering 252 packages, of which about 140 are designtime+runtime or designtime, and the others are runtime packages (which are also loaded, into the IDE at runtime, by DLL-dependencies in their associated designtime package).
Our main library path has been optimized down to be small as can be, and it contains the paths that Delphi ships with as standard, plus three more we added, the primary one is a single "OurCompanyLibraryDCU" folder, which contains underneath it folders for the two platforms and two configurations that we use:
c:\dev\OurCompanyLibraryDCU\Win32\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
c:\dev\OurCompanyLibraryDCU\Win64\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
Each of the above folders contains the set of BPL, DCP, and DCU files in a single folder, for that platform/config combination.
A macro like the following, in the project options is used, so we can change platform, and config, and have the directories resolve correctly:
$(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config)
OURCOMPANYLIBRARYDCU is an environment variable and $(X) is the syntax to expand an environment variable, in the context of the Delphi IDE.
I am trying to get the most important and largest VCL Application project (call it BigApp.dproj) to build so that the project search directory only contains our APPLICATION source folders and does not need the project search path to contain all our third party component LIBRARY source code. To do that, we need to link against the debug DCUs, or release DCUs.
So far we have everything working except for the case where you have both Debug and Release DCUs available. The release DCUs are in the library path, and the debug DCUs are in the Debug DCU path, in the IDE settings. Confronted with the choice between these two libraries, Delphi's linker appears to fail, whenever both sets of DCUs exist, with errors in this form, when I click Build, and the Build Configuration is set to Release, I get F2051 errors. The ordinary cause of an F2051 error is that multiple incompatible binary DCUs exist and are both accessible, and the linker is failing to make it all work. However, when you want both Debug and Release DCUs both in the library path, I thought that this sort of thing would not occur, due to the Linker selecting the debug or release DCUs for you.
If I have not build the Debug DCUs, the above problem does not occur. I suspect that my Debug DCUs are subtly "invalid" or that the Debug-DCU-selection algorithm inside Delphi is not working, but have no idea why, or how to fix this.
Multi-part-Question:
A. Is having a single folder for each platform/config combination, containing the DCU, BPL, and DCP in a single folder, and then added to the IDE Library Path known to cause problems? Do I need three sub-folders, making a total of 12 folders for every platform+config+filetype, or can I keep them together by platform+config?
B. In a package compilation situation, is it okay to have the IDE Library path contain the OurCompanyLibraryDCU folder, and also have that folder configured as the DCP Output Directory, Package Output Directory, and Unit Output Directory? My concern is that by having input folder and output folders the same, there is a case where the compiler could be failing to rebuild a Unit from .pas source, and simply linking the prior compile's DCU.
C. If I'm going about this wrong, how instead, shall I prevent the over 2.5 million lines of component LIBRARY code from being compiled from source each time I build my BigApp, instead only link them via DCU, and still have the debug and release dcus work properly?
D. I can get past the original error if I go to the Win32\Debug folder and delete IdGlobal.dcu. This suggests to me that my package compilation (for debug config) is producing an INVALID IdGlobal.dcu. Is that even possible? Can delphi silently output garbled DCUs?
Notes: I'm not using, and can not use Runtime Packages, to deal with the application size problems.
Update: The first thing I should have done here is verify that ZERO additional DCU files are ANYWHERE on my harddrive, ANYWHERE. That's the standard F2051 error advice. I'll update this question after I've taken care of that. It appears possible that Delphi will itself COPY a DCU from one place to another, or that a bogus DCU that is NOT in the CURRENT search path might have been in some other project's search path. A kind of bucket-brigade of bad-DCU-copies can occur. I'll update the question once I'm sure what kind of bad-DCU-generations-or-copies are occuring.
Update 2: I have now guaranteed that no additional copies of IdGlobal.dcu exist before building, and the problem still reproduces. So the question then turns on the compiler options used when building the IdGlobal.dcu, versions the compiler options used when building BigApp.dproj in Debug build.
Update 3: Although all my package compiles appear to complete without error, it seems they were not using a correct library search path, during the time when the DCC32.exe or MSBUILD.exe is being launched to build the packages. This library path inconsistency issue appears to be the core issue, thanks to Sir Rufo for pointing that out.
Perhaps I can shed some light on the order of search paths presented to the compiler, which should make clear why the problem happens in the first place and can be cured (at least in your situation) by adding the Debug DCU path at that specific location. All these observations were made with XE7.
There are several places in the IDE where you can specify search paths:
Library path (Delphi-Options - Library)
Translated Library path (Delphi-Options - Library-Translated)
Debug DCU path (Delphi-Options - Library)
Translated Debug DCU path (Delphi-Options - Library-Translated)
Search path (via Project Options)
When the Library language is set to English, those pathes are given to the compiler in the order 5,1 or 3,5,1 depending of the setting of Use debug .dcus. This is already a bit weird as the debug dcu path takes precedence over the project search path.
So f.i. to make the compiler find our own dcu files of a newer Indy version, we have to place the corresponding paths in front of the paths under 1 and 3.
Now things get complicated when the Library language is set to something different than English. In this case the translated paths come into play resulting in the order 2,5,1 or 4,3,2,5,1 depending of the setting of Use debug .dcus.
To make the above example with a newer Indy version work, you have to tweak the translated paths, too.
The culprit lies in CodeGear.Delphi.Targets, which places the paths in this order. I was able to modify this file so that the natural order of paths is used: 5,2,1 or 5,4,3,2,1. If anyone can confirm that I am allowed to show these changes here I will do. Perhaps I can provide a patch only.
Update: Here are the changes of CodeGear.Delphi.Targets from XE7 as shown by Mercurial
## -122,20 +122,19 ##
<DcpFilename Condition="'$(DcpFilename)'!='' And !HasTrailingSlash('$(DcpFilename)')">$(DcpFilename)\</DcpFilename>
<DcpFilename Condition="'$(DcpFilename)'!=''">$(DcpFilename)$(MSBuildProjectName).dcp</DcpFilename>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(DelphiLibraryPath)</UnitSearchPath>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' == ''">$(DelphiLibraryPath)</UnitSearchPath>
-
+ <UnitSearchPath>$(DelphiLibraryPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_TranslatedLibraryPath)' != ''">$(DCC_TranslatedLibraryPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DelphiDebugDCUPath)'!=''">$(DelphiDebugDCUPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DCC_TranslatedDebugLibraryPath)' != ''">$(DCC_TranslatedDebugLibraryPath);$(UnitSearchPath)</UnitSearchPath>
-
+ <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(UnitSearchPath)</UnitSearchPath>
+
<___ResourcePath Condition="'$(DCC_ResourcePath)' != ''">$(DCC_ResourcePath);$(DelphiLibraryPath)</___ResourcePath>
<___ResourcePath Condition="'$(DCC_ResourcePath)' == ''">$(DelphiLibraryPath)</___ResourcePath>
+ <___ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(___ResourcePath)</___ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(___ResourcePath)</__ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' == ''">$(___ResourcePath)</__ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' != ''">$(BRCC_OutputDir);$(__ResourcePath)</ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' == ''">$(__ResourcePath)</ResourcePath>
- <ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(ResourcePath)</ResourcePath>
<NameSpace Condition="'DelphiNamespaceSearchPath'!=''">$(NameSpace);$(DelphiNamespaceSearchPath)</NameSpace>
Now I understand a source for this problem. Please upvote Sir Rufo as he put me in mind of the solution.
It is this: I was invoking DCC32.exe to compile packages (using .dpk, but no .dproj file, and not invoking msbuild to compile these packages). When I built these, I was not inserting the Debug DCU path to the head of the library path passed in via -I parameters to DCC32.exe.
Once the DCC32.exe package compilation Library Search path has the Debug DCU folders FIRST, it works.
If anyone is interested in such a package system, I am planning to open source this package build system, as part of a relaunch of the WANT project originally built by Juancarlo Anez, which I will probably call by a new name. I'll update this answer once a working demo of a component build system is available.
A brief outline of a working system to meet the requirements I asked in my question:
You will need a file (could be xml, ini, json file) that defines a list of packages to build.
You will need to invoke MSBUILD or DCC32.exe on each of these. You could write your own code, or you could use mine, which I will open source when I can.
You will need to include the Debug DCU DPROJ into the library path as the first items, ONLY when invoking the Debug item builds.
You will want to use the $(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config) macro in your project search paths and library paths.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Release as a path within the Library path.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Debug as a path within the Debug DCU path.
The debugger steps into the source code on errors (like with F7), but I want to restore the normal working mode where the Delphi basic DCUs (the library) are only compiled into my code, and the sources are not used in debugging.
For example, on an error in my program, the debugger is stepping into Controls.pas, into TControl.Click. The normal case (right after installation) is for Delphi to step over these methods.
Should I recompile Controls.pas without debug information? If so, how?
I extending this theme with additional information to better understanding:
We use Delphi6 Prof. what have problem with Mouse (System Error Code 5).
So we want to recompile to Controls.pas to replace the Mouse Position getter code.
Then:
I created a folder for it: "c:\D\Common\Delphi_Patches\Delphi_6\"
I put the original Controls.pas into it.
I modified the Controls.pas, replaced the position getter code.
I set the Delphi's Library path, set the first folder to "c:\D\Common\Delphi_Patches\Delphi_6\"
With these steps I can compiled the source with mouse-safe code.
Ok, but then the Delphi everytime steps into Controls.pas on F7, and on any exceptions - this is very "angermaker" thing.
No matter that I removed the "Controls.pas" from the Library path - then the debugger is finding the original "Controls.pas" for it, and opens it... :-(
We don't use "Use Debug DCU-s" in any codes.
I tried to remove "Debug Information" from compiler options, but it is no matter, the Delphi is opens the original Controls.pas...
So I search the way to Delphi don't step into "Controls.pas", but use my dcu...
I hope this provide better context to understand the problem.
I think that you need to Shift+Ctrl+F11 (tools/options) then in Compiler, uncheck "Use debug DCU"...Then if an exception occurs it wont break into the RTL or VCL sources.
Since you are compiling your own version of a Delphi unit, you can disable debug info in that unit. Add {$D-} to the source code of the unit(s) in question.
As I see the solution is:
create a project the uses only the new Controls.pas.
unset the "Debug information" option in compiler options.
build dcu
put the dcu into a library folder
hide the new Controls.pas from this library folders.
Wite this trick the I cannot "step into" controls.pas.
Regards: dd
I had this same problem with Delphi XE8.
You can untick the "Project >> Option >> Compiling >> Use debug .dcus" and it will continue tracing into System unit and so on.
I found that the best way to stop this is to open your Application.dproj file - which is in XML. In it, you can change the settings as follows:
<PropertyGroup Condition="'$(Cfg_1_Win32)'!=''">
<DCC_AssertionsAtRuntime>false</DCC_AssertionsAtRuntime> <--- note false
<DCC_DebugDCUs>false</DCC_DebugDCUs>
<VerInfo_Locale>1033</VerInfo_Locale>
<VerInfo_IncludeVerInfo>true</VerInfo_IncludeVerInfo>
<DCC_RemoteDebug>false</DCC_RemoteDebug>
</PropertyGroup>
I am tried deploying .cod,.alx.jar files on blackberry simulator 8100;the application is not getting deployed on phone.I am using Blackberry plugin for Eclipse.
How can I solve this issue?
Please help
Update
Hi,
Thanks for your reply.
I am trying to run the application the way you suggested.
Do I need to setup new run configuration every time I run any project?
What should be default value for build configuration ? [Debug,Private,or Release]
Copying the .cod files into the simulator's directory (where all the other .cod files are) and restarting the simulator will work.
Probably though you want to automatically deploy from Eclipse. If this isn't working for you, there are a couple of things to check:
Check that the project has been activated for BlackBerry - from the right-click menu for the project, make sure that Activate For BlackBerry is checked.
If that's already checked (as it is by default when you create a new BB project), then sometimes explicitly building the project will do the trick: From the Project menu, choose Build Active BlackBerry Simulation
EDIT: In response to some comments below I thought of something else. The configuration you choose may have something to do with your problems (BlackBerry -> Build Configurations). The configuration in the JDE Plug-in doesn't affect the code generated, but it does affect which projects are activated for BlackBerry. If you switch configurations, your project may become un-activated.
Since it doesn't affect the code, I usually just pick one configuration and stick with it throughout debugging and release.
You might be missing 'jar' in your PATH. If so, the eclipse BB plugin silently fails and your application won't be pushed to your simulator plugin directory. To see this failure within eclipse, choose 'Project > Build Active BlackBerry Simulation'.
If you don't have jar in your path, then you will see:
I/O Error: Cannot run program "jar": CreateProcess error=2, The system cannot find the file specified rapc executed for the project
So, if your JDK is here:
C:\Sun\SDK\jdk\bin
Then append it to your system environment's PATH variable, then re-run 'Build Active BlackBerry Simulation' and you should see:
rapc executed for the project [YOUR PROJECT]
Here are a couple of ideas:
1) If you have any build errors then the application won't deploy to the Simulator. The Eclipse compiler (that underlines compile errors in red) is different to the "rapc" one that creates the binary for the Simulator. I have heard of situations where the Eclipse build seems to work, but the rapc compile fails - check the Console for the detailed rapc output (this might not look like a normal Eclipse build error).
2) In the Eclipse menu, open BlackBerry -> Configure BlackBerry Workspace.
Under BlackBerry JDE choose Code Signing and make sure the three RIM checkboxes are selected. I had compile errors when these weren't selected.
Under BlackBerry JDE choose Installed Components. Choose to use the Component Package 4.7.0 as I have heard of problems with the 4.5.0 Simulator.
You should delete all these extra answers you posted, or you might get downvotes - they should be comments instead of answers.
Check if your simulator is set up to clean the file system / configuration before launching the simulator. Simulators can be set up like this. If you deactivate it, the application should not disappear.
For future readers, there is another possibility for this issue. Check your workbench project directory (folder) for a ProjectName.err file. This may provide a clue as to why your build is silently failing and thus not deploying. In my case, it was an "Error!907", a new icon I added to my project was too big. There was absolutely no other indications in Eclipse 3.4.1 that there was a problem in my build.
Just ran through the same kind of problem : project compiled fine but didn't deploy on any device or on any simulator, even though the debugger said it was attached !
The problem came from a .zip file that was located in the ./src directory of the project, deleting or moving it somewhere else resolved this case.
I wish I hadn't spend 2+ hours on such a stupid problem :/
I know this is old, but you have to do the "generate ALX" option from right clicking the project menu as well or it won't deploy, at least it doesn't for me.
I ran into the same problem again and none of answers posted here worked for me.
I played around and finally made it work. The problem was that the output file name contained a hyphen ('-'). Changing this name in the Build section of BlackBerry app descriptor did the trick.
I mean, how stupid a developer must be to slip that kind of bug. No error reported and why reject the names with hyphens in the first place? Give me back my two hours RIM "developers"!
I had the same problem. The reason was using 'ü' character in the title.
I have been facing this problem today, but with a MIDlet project. It turned out to be that I forgot to specify the "Name of main MIDlet class" in the BlackBerry Application Descriptor (BlackBerry_App_Descriptor.xml). Once I specified it the application appeared on the simulator correctly.