In case anyone was interested, here's how to run a ClickOnce application as an Exe:
rundll32.exe dfshim.dll,ShOpenVerbApplication [Uri to .application file]
Why would you need this? Well, if you want to add a ClickOnce application as an External Tool in SQL 2005 Management Studio, if you need to fire it up it from a batch file (without opening a browser window), or anywhere else that requires a .exe extension, or where the shell-hooked ClickOnce shortcuts won't work.
Thursday, May 8, 2008
Thursday, May 1, 2008
How I Got Burned Today - TFS Branches
This one was a bit of a latent burn. The coals were drenched in lighter fluid a couple of months ago, but only caught fire and burned me this morning.
We started out with a Development branch in Team Foundation Server. When we were ready to put builds together for demonstration purposes, we branched it to a new "Release Candidate" branch. Being new to TFS, I didn't fully understand the implications of merging by date or label, which functions completely differently from merging by Changeset. So I merrily went on merging by label, not realizing that it only merged code as it saw changes, and added new files fine, but didn't recognize deleted files because it wasn't reading the Changesets directly, just comparing two points in time.
When I realized this mistake, I deleted the Release Candidate branch, and then branched Development anew - to "Release Candidate". Yes, with the exact same name as the branch I deleted.
As new builds were needed, I would branch by Changeset and all was well.
Until this morning.
I tried to do a merge of all Changesets up until the nightly build, and got this message (click for larger view):
This message would be hilarious if it wasn't so baffling.
After some digging and researching, I managed to discover that one of those Changesets contained a number of moves and renames, which is usually harmless enough. Except for some reason, TFS could not figure out which in which branch - the old deleted one, or the new one - it should rename and move the files.
In the end, I ended up creating another new branch, "Release Candidate 2", and deleting Release Candidate again. This time it will stay deleted.
In summary: NEVER delete a branch and recreate a new one with the same name. Always use a new name, or else your merges will suffer.
We started out with a Development branch in Team Foundation Server. When we were ready to put builds together for demonstration purposes, we branched it to a new "Release Candidate" branch. Being new to TFS, I didn't fully understand the implications of merging by date or label, which functions completely differently from merging by Changeset. So I merrily went on merging by label, not realizing that it only merged code as it saw changes, and added new files fine, but didn't recognize deleted files because it wasn't reading the Changesets directly, just comparing two points in time.
When I realized this mistake, I deleted the Release Candidate branch, and then branched Development anew - to "Release Candidate". Yes, with the exact same name as the branch I deleted.
As new builds were needed, I would branch by Changeset and all was well.
Until this morning.
I tried to do a merge of all Changesets up until the nightly build, and got this message (click for larger view):
This message would be hilarious if it wasn't so baffling.After some digging and researching, I managed to discover that one of those Changesets contained a number of moves and renames, which is usually harmless enough. Except for some reason, TFS could not figure out which in which branch - the old deleted one, or the new one - it should rename and move the files.
In the end, I ended up creating another new branch, "Release Candidate 2", and deleting Release Candidate again. This time it will stay deleted.
In summary: NEVER delete a branch and recreate a new one with the same name. Always use a new name, or else your merges will suffer.
Subscribe to:
Posts (Atom)
