Debugging on a device emulator

by Bjørn Storkholm 19. December 2009 12:27

One thing I always hated about developing for mobile devices is waiting for deployment. Hit <F5> in Visual Studio... and wait for all the assemblies being copied to the device.
A workaround for this can be, to setup the device emulator’s storage card to point to the bin folder. Doing this you have instant access to the updated binaries, whenever you build. In the emulator click File -> Configure. In Shared Folder add the path to your target library.
Setup device emulator to point at storage card

With this, you can execute your program instantly upon a new build without waiting for deployment. But if you want to debug your code you can try to attach to process, and get an error saying Unable to attach to the process. Attach is not enabled for this process with this debug type.

 Error trying to attach to process

You’ll need to use Visual Studio’s remote tools Windows CE Remote Registry Editor to enable remote debugging. Add the following d-word to registry and set the value to 1:
HKLM -> Software -> Microsoft -> .NetCompactFramework -> Managed Debugger -> AttachEnabled

  Add AttachEnabled to registry
This enables debugging on the device, but be aware it slows down the device quite a bit, so it should only be done on development devices.
Doing it this way, you build and attach, no wait for deployment. It showed to be quite a time saver for me.

Note: In general it cannot be recommended to execute programs from the storage card, it can show to be quite unstable. But for debugging purposes it’s great.

Strange TFS requirements

by Bjørn Storkholm 27. April 2009 18:37

What the f....Sometimes I receive some strange error messages from TFS. This error occurs once in a while, I wonder why TFS requires Messenger to be runnning? I'll connect to TFS anyway, after clicking OK.

Tags:

TFS | Weird stuff

Tracking code changes with TFS

by Bjørn Storkholm 21. April 2009 12:19

Working at Microsoft we had a checkin policy, that you can't checkin without associating the changeset with a work item. Never really occured to me, why we had to do this, but it seemed like a good practice.

 On the last two projects I worked on, that involved Team Foundation Server as version control, the customer has been using other software for bug tracking. Because of that, we haven't used workitems, and it seems like there's no point in associating changesets to workitems.

That was a wrong assumption. After I completed the first task on the project I'm currently working on I discovered, that it is a requirement that we create a document, describing every change that's been done to the code. The document is meant for code review, so it's a fairly good idea. But - when I had to track down every change done in the repository for 14 days of work, and 20 other developers made checkins, it showed to be a bit of a task to track down my changes (and boring as well).

On the next task, we decided to create a workitem. Not that it'll be used by anybody else. But we decided to create it, and agreed to associate every checkin with the workitem, so that it'll be a piece of cake to list the changesets regarding this task.

Now this seems like a pretty good solution to me. This way we can always track down every change done, regarding this task. But is it without problems? I don't think so. First of all, it requires some discipline from the developers to do the association. I've seen too many developers who doesn't even bother to write a comment, when they checkin. Another problem on the current project is, that there hasn't been awareness of the details in the code review document, until everybody completed a task which typically lasted 2-4 weeks. So what can you do, when it's too late ?

The best solution I found so far, to track down your own changes is to install the "Team Foundation Server Power Tools" which can be found here: TFS powertools .

You'll get lots of small extra stuff in you're team explorer. One thing is, that you'll get a node in the treeview displaying your team members. On the team members node you can get a list of every changeset that's been done by a specific developer, hence help you do the code review.

Big brother? Maybe, but very helpfull.

Update 20090424: Erik Ejlskov told me about a tool for doing extended searches in the repository called "Team Foundation Sidekicks". Pretty cool 3rd party tool, can be downloaded here: Team Foundation Sidekicks

Tags:

dotNet | Microsoft | TFS

Powered by McDonalds

About Bjørn

Bjørn StorkholmBjørn Storkholm has been working in the IT industry since the mid 90es, with a primary focus on Microsoft technologies. Started developing on the dotNet platform in 2001, when it was in it's early beta stages.

About the blog

This is a place where I can discover my own findings, after they have slipped my memory. But maybe others can find some usefull stuff here as well.

The blog is powered by BlogEngine