5

First I will start with what I am trying to accomplish, then I will provide contextual details:

When I select Start Debugging, I want the output directory to change depending on which device is connected over Windows Mobile Device Center. Clarification: Installing from our setup program works fine, but debugging from Visual Studio is what is giving me problems.

I am using Visual Studio 2008. The project is a Smart Device project written in C# for for Compact Framework 3.5 and targets Windows Mobile 5.0 Pocket PC Device R2(according to the project settings). I have found that when I target this device type, it works correctly on all versions of Windows Mobile that we support along with Windows CE 6. Any proposed solution will have to work on both Windows Mobile and Windows CE.

When I go into the project Properties, and go to the Devices tab, it shows Output file folder: and the path for output. If I click on the ... button I can change this to different defaults or even set it to Root Folder and then fully specify the exact path I want as the Subdirectory. On most devices if I just leave it at (Device Default) or select Program Files Folder from the drop down list it works fine. The problem is that when it runs on the Windows CE device that we support it needs to run from a different location.

Possible Solutions:

Multiple project Solution: Have multiple projects for different devices. The problem with this is I don't know how to do that without violating the DRY principal for some of the files that need to be included with the output and I don't want to have to switch back and forth between different Start projects.

Redefine %CSIDL_PROGRAM_FILES% solution: Change what %CSIDL_PROGRAM_FILES% means since this can be in the output path specifying where Program Files is. However I don't know if this is possible or where to start with attempting this. I thought maybe this would be defined in the device registry, but I can't find it.

Custom path variable solution: Select Root Folder and then under Subdirectory somehow reference a variable (perhaps by starting and ending with a %?) in the path that I can change to what I need (perhaps from a post-build or pre-deploy(if there is such a thing) script). I don't know if this is possible or where to start with this.

Any help will be appreciated, thanks!

EDIT:

After doing some digging, my best guess is that %CSIDL_PROGRAM_FILES% is a Windows CE environment variable. I still don't know if it is possible to create or modify these.

still_dreaming_1
  • 8,661
  • 6
  • 39
  • 56
  • 1
    CSIDL (constant special item ID list) values are constants that are used to refer to locations that change with different languages or OS builds. They cannot be added to or modified. The ones you see in Studio are getting passed across to the CoreCon APIs, pushed across to the device, and then on the device side they are translated. – ctacke Feb 27 '13 at 00:47
  • @ctacke Thanks for sharing your expertise. Are you sure there is not a way to alter the way the device translates these constants? What technology is involved at that point? I know this is a long shot and you already said it is not possible, but sometimes hearing questions from someone less knowledgeable opens up new thought processes. – still_dreaming_1 Feb 27 '13 at 01:15

3 Answers3

1

Using different solution/project configurations to use different output path and debug settings:

In VS right click the solution and "Configuration Manager" enter image description here

Inside the list below "Active solution configuration" click enter image description here

Now enter a new descriptive name and which settings may be copied for the new config. Please enable "Create new project configurations" and click OK

You now got a new solution and a new project configuration. enter image description here

Click OK to close the solution config manager.

To change the settings for all or individual project configurations you have to right click the solution and then select Properties enter image description here

Now you can have different settings for each configuration.

Deployment settings for "Release_Device1" config: enter image description here

But different deployment settings for "Release" config: enter image description here

You can also have different Debug settings in your configuration set: enter image description here

Any thing to add?

josef
  • 5,951
  • 1
  • 13
  • 24
  • This looks very promising. I currently don't have the device I needed this for. I will have one again soon and then I will try this. Thanks. – still_dreaming_1 Mar 08 '13 at 01:20
  • For some reason I don't have those options under the solution properties. The left tree only has Configuration under Configuration Properties. There is no Deployment leaf under Configuration Properties. What version of VS is this? I have VS 2008 Pro 9.0.3.0729.1 SP. – still_dreaming_1 Mar 28 '13 at 03:51
  • I tried changing this setting from the project properties hoping that it would set it per configuration, but it is keeping those settings for all configurations. – still_dreaming_1 Mar 28 '13 at 04:02
0

First I tried to use an environment variable in the project file:

    <DeploymentTool
    ForceDirty="-1"
    RemoteDirectory="$(ceRemoteDir)"
    RegisterOutput="0"
    AdditionalFiles=""
/>

But that is unfortunately only updated when you start VS and not updated later.

I would go with a custom deployment script using the free remote tools.

Using preg you should be able to recognize the different devices within a batch script:

pregutl.exe hklm\Ident

will for example give:

[HKLM\Ident]
Desc=""
Name="CK7007121144066"
OrigName="Pocket_PC"
Restriction=dword:00000002
Username="guest"

on one device and on another I get:

[HKLM\Ident]
Desc="Intermec CN3 Device"
Name="CN3A32110646073"
OrigName="IntermecCN3"
Restriction=dword:00000002
Username="guest"

It should be not that hard to filter that in a bat/cmd file and then use pput to deploy an exe to different dir depending on the pregutl query.

The bat/cmd file then can be used instead of the VS deployment as Post-Built Event.

Yes, all this is a bit complicated but will work.

josef
  • 5,951
  • 1
  • 13
  • 24
  • I tried out those tools before posting this question. I successfully deployed to the right place, however, I also want to Debug from Visual Studio. I am not familiar with using post-build events, but I would imagine that even if I got the files to deploy correctly within a post-build event, Visual Studio would also do its own deploy afterwards to the wrong place and then attach the debugger to this other copy of the program instead of the one I deployed from my custom script. This would also have the unwanted side effect of deploying every time I do a build. – still_dreaming_1 Feb 27 '13 at 23:27
  • I assume the official way is to have different configurations. A Debug_DeviceType1 config for device type 1 and a Debug_DeviceType2. Within the configurations you can specify hardcoded deploy and debug path. If the one device is connected you use configuration one and for the other device you use configuration two. Changing the configuration is just one click in the VS2008 toolbar. - BTW: VS can be set to NOT deploy. And you can use attach-to-remote in Debug after an exe has been deployed manually. But then you are not able to debug the startup of the remote process. – josef Feb 28 '13 at 05:03
  • Having to switch back and forth between different configurations is an acceptable price to pay and is not as bad as having multiple projects and changing which project is the startup project all the time. How would I configure VS to use a different debug and deploy path for different configurations? – still_dreaming_1 Mar 01 '13 at 00:08
0

If I am understanding your correctly, I see a couple of options you could take:

  1. Have your installer place these executable files in the folders you need, or

  2. Place all of the data that you need in a central location (\Program Files\Data folder).

That first option, by itself, would be difficult (impossible through the VS2008 environment) to debug under, though.

You could even use a combination of both!

Now, I'm going to go look at all those tools josef linked to. Where does he get all of those cool toys?

Community
  • 1
  • 1
  • Actually, I already have an installer that installs everything in the correct place. What is not working so well is debugging from VS. You did give me some ideas though. I could design it to run from either location even though there are advantages to running it from the other location and the installer will still put it there. However I am still searching for a better solution as I want to test in the same environment it will be running in in production. – still_dreaming_1 Feb 27 '13 at 22:30