WebLog of SivaRV

Deploying/Registering device-side ActiveX controls and COM Dlls

VS2005 has project types for creating MFC based ActiveX controls and MFC/ATL based COM dlls for smart devices.  One of the errors users run into with these projects is that of deployment or registration failing with error 0x8007007e.   One can be sure to encounter this error if the following conditions are met.

• Project dll is dynamically linked to ATL or MFC libraries
• "Register output" project property is true.
• ATL or MFC libraries (dlls) are not deployed to device or deployed under project folder on device

What is the reason for the error 0x8007007e?

Registration of Dlls is done by device side agent (conmanclient2.exe) using LoadLibrary() WinCE API.  This API looks for dependent libraries in the directory where conmanclient2.exe is present and in "\Windows" directory.  Therefore, registration fails.

How to get around this error?

Copy the required dlls on which project depends and dynamically linked to "\Windows" directory on device.  Instead of manually copying, these dlls could be added as additional files to project  with target deployment location as "\Windows" so that these get deployed along with the project.  If any of the dependent dlls are COM dlls and need registration, this could be done manually using regsvrce.exe utility.  To reduce deployment delays, after deploying these dependent dlls for the first time set the "Copy to output directory" property of the file to "Do not copy".

My project is dynamically linked to ATL/MFC dlls. What  dlls I should copy to device and where can I find them?

Required  ATL/MFC dlls in case of English locale are msvcr80.dll, atl80.dll, msvcr80d.dll, mfc80ud.dll.  These could be found under "\Program Files\Microsoft Visual Studio 8\VC\ce\Dll" directory.  One has to select the dlls matching the device cpu (armv4, armv4i, mips etc) and locale.

Narrowing down the cause of deployment failure

In the recent past I have read deployment problems reported by users in smart device development forums.  It was my  observation that majority of the issues reported do not contain enough information to troubleshoot the problem.   This will result in few email exchanges back-and-forth which is frustrating to both the parties involved. It is like suggesting a solution based on the symptoms described by the user.  The same symptom could be caused by multiple reasons and to zero-in on a cause one has to perform additional tests.  Since we will not have access to user's machine, there are few things that users can try out to troubleshoot the deployment problem. 

1. Try to identify in which phase of F5 the failure has occurred

Those who read my first blog post on deployment essential might recall that F5 = Build + Connect To Device + Deploy + Debug Launch.  Most users press F5 and in some cases based on the error message it may not be possible to identify the phase in which F5 has failed.  Trying out the individual operations that make up F5 will let us narrow down the phase.

• Build failures are the result of compiler/linker errors. 
• One can check whether connection to device/emulator is successful, by choosing "Tools->Connect To Device".
• To check any error encountered during deployment phase choose "Build->Deploy Solution".
• To debug launch the application, press F5 after performing the above three steps.

2. Few things to check if connectivity to device has failed

• Activesync 4.0 is installed if connecting over AS
• Device security configuration allows development with VS.  Please read my blog post on deployment essentials part  II for more details. https://blogs.msdn.com/sivarv/archive/2005/09/20/471863.aspx
• If TCP is the transport chosen for emulator, make sure that NE2000 network adapter is enabled
• Whether specific to an emulator or a device?  Try a couple of emulator or devices if at hand.
• Whether launch of emulator has failed.  In some cases deleting emulator local saved states solves the problem.
• Some times soft resetting the device will solve the problem.

3. Few things to check if failure has occured during deployment phase

• Device has enough free space
• In case of native projects, dependent dlls are in "\windows" directory
• In case of managed projects, NetCF installastion will fail if cab installer (wceload.exe) is missing on the device
• Make sure that a previous instance of app is not running.  This will result in deployment failure with sharing violation.  Running app could be killed using remote process viewer.
• Whether specific to an emulator or a device

4. Few thigs to try if debug launch has failed

• Just launching the app instead of debug lauching.  This can be done by pressing Ctrl+F5.
• If Ctrl+F5 too fails, try to launch the app manually on device/emulator
• In case of native projects, make sure that project target platform/cpu and connected device match.
• Code signing might be required in some cases particularly with Smartphone.  Please read my blog post on deployment essentials part II for more details.
• Whether specific to an emulator or a device?

5. What if you had tried all of the above and still have no clue to troubleshoot the problem?
Send a mail to smart device development forum describing the problem you are facing along with the following details

• Version of VS (could be found by choosing "Help->About")
• Whether previously had a older version of VS2005 and upgraded to RTM
• Whether using VS2003 and VS2005 side by side
• Project type and any specific project properties (un)set
• At what phase of F5 the failure has occurred and the things you tried.
• Whether the problem is specific to an emulator or  a device
• Whether the problem is specific to a project type or with all projects.  For example, the problem could be reproduced only with managed projects and not with native etc.

This will greatly help in quickly identifying the cause of a problem.

Application Deployment essentials for VS2005 device application developers - Part III

In this post I am writing about a couple of things that I found greatly useful during deployment and debugging.  In my next post I will discuss why developers needs to be aware of Windows Mobile OS limitations.

1. My device application writes to a log file. To view the log file, copying to desktop every time is a pain.  How can I view log files on desktop without needing to copy? - There is more than one way to view the log files created by a device application

• View log files directly on the device or emulator - but viewing log files on device or emulator screen is painful and not practical when the log is of modest size
• Copy the log files to desktop manually over ActiveSync and view it on desktop - but copying every time is a pain

Can we do better than the above two options? Yes, at least when using an emulator.  One of the cool features of device emulator is Folder Sharing, which allows us to mount a desktop folder as "\Storage Card" under the device file system.  Say that we want to map "d:\workspace" folder as storage card under the emulator.  This can be done by selecting "File->Configure..." menu option on the emulator window.  This opens up "Emulator Properties" window.  Edit the text box titled "Shared Folder:" to specify "d:\workspace" as folder to be shared with emulator. Now whatever the files created under "d:\workspace" directory could be viewed under "\Storage Card" device folder and vice versa.  To view log files on desktop without needing to copy, all we have to do is to configure the application to write its log files under "\Storage Card".  It is always a good practice to keep the path of the folder under which log files are created configurable.  This is one example where such a practice pays off.

It should be noted here that Folder Sharing option is not available in case of a physical device.

2. Is it possible to achieve zero deployment time, at least with the emulator? - Let us recollect the fact that, F5 time = build time + connect time + deployment time + debug launch time.  As I mentioned in my first blog post, using emulator Saved State connect time could be drastically reduced.  Using Saved State even deployment of dependent dlls could be avoided.  But every time if we edit source code and press F5, the newly built executable will get deployed.  Making an application executable deployment time to zero makes the total deployment time close to zero.  How can we reduce an application executable deployment time to zero?  The answer is Folder Sharing feature of emulator.  This trick could be achieved by performing the following two steps:

• Share the desktop folder under which an application executable is built with emulator. By default VS2005 creates projects under "C:\Documents and Settings\<User Name>\My Documents\Visual Studio 2005\Projects" folder assuming VS2005 is installed under C: drive.  Say the user name is "sivarv" and project name is "MyProject".  The debug version of the managed application executable built is stored under "C:\Documents and Settings\sivarv\My Documents\Visual Studio 2005\Projects\MyProject\MyProject\bin\Debug", which is the folder to be shared with emulator.  In case of native applications the folder path varies slightly as it also targets a specific platform.
• Set the deployment location of the application on the device to "\Storage Card".  Please read my first blog post to know how to change deployment location.

Subsequent to the above two steps, pressing F5 will not deploy application executable as it is already deployed at the target location on emulator through folder sharing!

Application Deployment essentials for VS2005 device application developers - Part II

Here is my second blog post in the series on deployment related issues. So as to keep my blog small and easy to read,  I will just concentrate on Windows Mobile Smartphone application security from the perspective of VS2005 developers.  The remaining issues will be covered in the next blog post.

1. How Deployment to Smartphone is different from PocketPC? - It differs in two important aspects i) typically Smartphone devices have less memory and less powerful cpu compared to PocketPC devices. This translates to more time required to connect and deploy compared to PocketPC.  ii) Windows Mobile Smartphone devices by default are governed by 2-tier security model which restricts what could be deployed and run whereas PocketPC devices by default support 1-tier open security model which doesnt put any restrictions.  It should be noted here that Windows Mobile 5.0 allows to enable Smartphone security model on PocketPC devices too.

2. What is Windows Mobile Smartphone application security model in a nut shell? - Windows mobile application security model is based on digital signing.  This is to protect end-user's devices by not allowing the user to install applications from an unknown source. 

A Smartphone has two types of certificate stores: privileged and unprivileged.  A digital certificate present in privileged certificate store of the device is considered a privileged certificate.  Similarly, a digital certificate present in unprivileged certificate store is considered an unprivileged certificate.  It should be noted here that there is nothing special about a privileged certificate.  Based on the certificate with which an application is signed it is categorized as: privileged app, unprivileged app or unsigned app.

Security configuration of a Smartphone is determined by the following four security policies or registry settings:

1. Can unsigned applications run?
2. Prompt or No-Prompt - Whether user be prompted when an unsigned application attempts to run
3. 1 or 2-tier device - Is the device 1-tier or 2-tier.  In 1-tier any code that can run is fully trusted. In 2-tier code can run either as trusted or normal.  A trusted process can all any API without any security restrictions whereas a normal process is forbidden from calling certain APIs.  Note that PocketPC supports only 1-tier mode.
4. RAPI disabled, allowed or restricted - What rights desktop application have when making RAPI calls. Restricted means desktop application can do what an end-user could do.

The values of the above security policies define a security configuration.  There are five standard security configurations.

1. Locked - unsigned apps cannot run, no-prompt mode, 1 or 2-tier, RAPI is disabled
2. Third-party Signed - unsigned apps cannot run, no-prompt mode, 1 or 2-tier, RAPI is disabled
3. 2-tier Prompt - unsigned apps can run, prompt mode, 2-tier, RAPI is restricted
4. 1-tier Prompt - unsigned apps can run, prompt mode, 1-tier, RAPI is restricted
5. Security Off - unsigned apps can run, no-prompt mode, 1-tier, RAPI is allowed.

Let us consider an example here for better understanding.  In 2-tier prompt configuration: applications signed with privileged certificate run as trusted, applications signed with unprivileged certificate run as normal, unsigned application result in a prompt and answering "yes" to the dialog makes the application run as normal.

Note here that it is possible to set a Smartphone to a non-standard security configuration.  For example, unsigned apps cannot run, no-prompt mode, 2-tier, RAPI is allowed or restricted.

3. Why do I need to bother knowing about Smartphone application security? How does it impact application deployment and the application itself? - VS2005 depends on RAPI to bootstrap Windows Mobile devices.  Bootstraping prepares a device for connectivity (eg TCP/IP).  If the security configuration is such that RAPI calls are disabled,  VS2005 cannot bootstrap such a device and hence connectivity will fail.  For example, devices which are either Locked or Third-party Signed cannot be used for development with VS2005 as RAPI is disabled in these configurations. 

For TCP/IP connectivity and debugging, VS2005 deploys few components on the device.  These components needs to run as fully trusted and hence needs to be signed with privileged certificate.  Therefore, on a 2-tier device, the device side components needs to be signed with a privileged certificate.  But how can a developer obtain a digital certificate which is already installed on the device in privileged store? VS2005 ships with a couple of test certificates along with its SDK for development purpose.  By default all the device side components that VS2005 deploys on the device are shipped pre-signed with privileged SDK certificate.  To use a Smartphone device that is 2-tier, user has to manually install SDK certificates on the device.  SDK certificate cab (sdkcerts.cab) can be found under the folder "C:\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\SDKTools" assuming VS2005 is installed on C: drive. To install this cab on the device, copy it manually using ActiveSync and execute it on the device. 

It is worth mentioning here that by default SDK certificates are pre-built into the emulator and hence developers need not install them. Also, alert readers might have noticed that on a Security Off device SDK certificates need not be installed.

Okay, VS2005 is taking care of signing the components that it requires for connectivity and debugging. Doesnt the user application and other components it depends on need to be signed? The answer to this depends on i) whether user application is using API that needs privileged access or ii) whether security configuration doesnt allow unsigned apps to run.  In case (i) without code signing, both deployment and application launch will succeed, but privileged API calls will fail. In case (ii) without code signing, deployment succeeds but application launch will fail.  Then how can I sign my application?  VS2005 supports Athentic Code Signing feature exposed through project properties under "Athenticode Signing" category.  By default code signing is off.  One needs to turn on the code signing and specify a certificate to be used.  For development purpose we can use SDK test certificates for signing.  These certificates needs to be imported into desktop certificate store before using them.  If VS2005 is installed under C: drive, test certificates (TestCert_*.pfx) can be found under the folder "C:\Program Files\Microsoft Visual Studio  8\SmartDevices\SDK\SDKTools\TestCertificates".  Importing of test certificates too can be done through VS.  Depending on the requirement, either a privileged or unprivileged certificate could be selected.  Once the code signing is turned on, rebuilding the project automatically signs the application executable with the selected certificate.

Alert reader might have guessed that what gets installed on device are (sdkcerts.cab) public key certificates and on desktop (TestCert_*.pfx) are private key certificates.

4. Where can I find more details on Windows Mobile application security? - In my future blog posts I will try to cover some of the finer aspects of application security which VS2005 developers needs to be aware of.  Meanwhile, here are a couple of links for enthusiastic developers to explore.

The below link leads to an article that explains how application security worked in Smartphone 2003 devices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/smartphone_security.asp

The following link explains Windows Mobile 5.0 security model which is supported by PocketPC 2005 and Smartphone 2005 devices.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/wmsecurity.asp

Time for me to stop here.  Check this space for more next time.

Application Deployment essentials for VS2005 device application developers - Part I

Hi, I am a developer working in Visual Studio for Devices group.  In this my first blog post I will discuss few things related to application deployment that I have found useful myself as a developer.

One of the most frequently used operation by VS2005 (code named Whidbey) device developers is F5 or debug launching an application.  F5 is equivalent to the following sequence of operations in the order: build solution, connect to device, deploy solution and start debugging.  Deployment will fail if an error is encountered in any of the above operations.  Connect to device and deploy solution constitute the major chunk of time taken for F5. The questions often asked are: how can I trouble shoot deployment problems? How can I keep deployment time to the bare minimum?  What are the issues that affect deployment that I need to be aware of?  If you are interested in answers to these questions read on.

1. Emulator saved state to reduce connect time to emulator - Most developers might have noticed that connecting to an emulator for the first time takes more time compared to a corresponding device.  The reason for this is that emulator has to be started before connecting to it.  Emulator is a virtual machine that runs Window mobile WinCE OS.  Starting an emulator involves loading the OS image and booting it, which are time consuming operations.  Emulator saved state feature comes to our rescue here.  After starting an emulator, we can save its state by choosing "File->Save State and Exit" menu option on emulator window.  Subsequent attempts to connect to the emulator will be faster. In fact, Visual Studio 2005 ships with saved states of popularly used emulators.  These saved states are referred to as global saved states.  The saved states explicitly created by developers are referred to as local saved states.  Local saved state could be cleared by choosing "Clear Saved State" option under File menu of emulator window.  It is worth remembering a couple of points here: i) there can only one local saved state per emulator type ii) Only local saved states can be cleared.

2. Emulator saved state to reduce application deployment time - One thing I have noticed while deploying a NetCF V2 application is that it takes a lot of time to deploy.  One look at VS output window will make the reason evident.  The reason is Whidbey installs NetCF V2 on the emulator or device if it is not already present while deploying a NetCF V2 application.  Once NetCF V2 is installed, subsequent deployments of the application will not deploy NetCF V2.  This means, every time when we exit (or hard reset) emulator and press F5, deployment will take longer time.  How can we avoid this extra delay?  The answer is emulator saved state created after NetCF V2 is installed on it. But how can we obtain an emulator saved state with NetCF V2 installed?  First deploy the application by choosing "Deploy Solution" from Build menu of Whidbey IDE.  Next choose "File->Save State and Exit" on emulator window. Subsequently when you press F5 Whidbey will not install NetCF V2.

3. Can an emulator saved state cause deployment failure? - The answer is yes if not properly used.  Say that an application was launched by pressing F5 or Ctrl+F5.  Now, if we save the state of emulator, the resulting local saved state will include the state of the running application as well.  Next time after editing the application source code, pressing F5 or Ctrl+F5 will result in deployment failure with the error message "The process cannot access file as it is being used by another process".  What is happening here is that whenever a new application executable is built, subsequent F5 or Ctrl+F5 will deploy the new executable by overwriting the old executable that is already present on the emulator.  Since emulator is launched from its local saved state, application is already running when it comes up.  Therefore, an attempt to overwrite the executable while it is running causes sharing violation and deployment fails.  The thumb rule is: Never save the state of an emulator while the application is running.

4. How deployment actually works in VS2005? Isn't VS2005 doing anything to keep F5 time to the bare minimum? - VS2005 tries its best to keep F5 time to bare minimum required.  For example, VS automatically rebuilds a new executable if the source code was modified, launches new emulator instance if it is not already running and makes a new connection to device (or emulator) if a connection is not already made.  Similarly, VS2005 optimizes deployment time by deploying application (and other required dependent libraries) only if required.  What do we mean by "if required" here?  VS deploy an executable or dll based on its newness. Newness of an exe or dll file is determined by comparing its Win32 version.  Every exe or dll file will have a Win32 version, which is read from the file itself. The following rules summarize how VS2005 makes a deployment decision in case of an exe or dll file:

• If the device side version is less than that of desktop, file is deployed
• If the device side version is greater than that of desktop, file is not deployed
• If the versions are the same, a checksum comparison is made
  •  If the checksums are the same, the file is not deployed
  •  If the checksums are different, the file is deployed

It should be noted here that every time rebuilding the project or solution will not result in building a new version of executable.  What changes is the checksum when we modify source code and build a new exe or dll.

5. What if I wanted to deploy a file other than an exe or dll along with my application? - Sometimes we need to deploy a jpg/gif, html or txt file along with the application executable.  Do we need to manually copy this to device (or emulator)?  Wouldn?t it be nice if VS2005 deploys these files too along with the application? The answer is VS2005 supports deployment of non exe or dll files along with the application if added to the project.  This can be done by right clicking on project folder in "Solution Explorer" window.  From the resulting menu Choose "Add->Existing Item".  This brings up the "Add exiting Item" dialog box, using which we can select more than one file to add to the project.  Next time while deploying the application, V2005 also deploys the files added to the project.  What if I modify these files that I have added to project, would the newer file be deployed?  The answer depends on the value of the property "Copy to Output Directory" associated with the file. This property could be set to one of the three values: Do not copy, Copy always, Copy if newer.  The default value of "Copy to Output Directory" property is ?Copy if newer?.  But how the newness of a non exe or dll is determined?  Since these files do not have Win32 version, the newness is based on checksum alone.  In fact, "Copy if newer" in case of non exe or dll files should be interpreted as "Copy if different".

6. When I deploy a project where exactly it gets deployed on device (or emulator)? Can I change it to something else? Looking at project properties will reveal the deployment location on device.  In case of managed projects, "Devices" tab under project properties shows deployment location under "Output file folder" text box. In case of native projects, under "Configuration Properties->Deployment" category deployment location is shown under "Remote Directory" text box.

The default location is the folder %CSIDL_PROGRAM_FILES %\< Project Name>.  Here %CSIDL_PROGRAM_FILES% is a macro standing for "\Program Files" folder.  We can edit deployment location based on our requirements. For example, say that we want the application executable to be deployed directly under "Windows" device folder, we can specify it as "%CSIDL_WINDOWS%" or "\Windows".  It is worth remembering here that the folders specified in the deployment path are automatically created by VS2005 if not already present.

Okay, I am running out of time and also my blog post is getting too big to read.  In my next few blog posts you can expect to see answers to the following questions related to deployment. So stay tuned.

1. How application deployment to Smartphone is different from PocketPC?
2. Why do I need to bother knowing about Smartphone application security? How does it impact application deployment and the application itself?
3. My device application writes to a log file. To view the log file, copying to desktop every time is a pain. How can I view log files on desktop without needing to copy?
4. Is it possible to achieve zero deployment time, at least with the emulator?
5. Do I need to care about the limits or limitations of Windows Mobile OS? How does it impact application deployment?