分类： 嵌入式
2010-08-18 17:51:29
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:
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.
