March 2011

You are browsing the site archives for March 2011.

0

Those of you familiar with Linux systems should know the very helpful “which” command which can tell you where exactly an executable that is in your PATH is located. The good news is, that a very similar command exists in PowerShell

> get-command tf

If the TFS exectuable is in your path, this gives you output of the form.

CommandType     Name                     Definition
-----------     ----                     ----------
Application     TF.exe                   C:\Program Files\Microsoft Visual Studio 9.0\Com...

But that’s not very helpful, is it? I mean, a quite important part of the path is cut off for crying out loud. So how do you get the FULL path?

> get-command tf | format-list

Name            : TF.exe
CommandType     : Application
Definition      : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe
Extension       : .exe
Path            : C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe
...

And there you go. It’s a bit more complicated than necessary, but at least it’s possible.

Categories

0

Today I’ve had an extremely interesting realization: the number, order and exact point in the page lifecycle at which HtmlMeta controls are added to the HTML head can have significant implications for your page. Especially if you have some sort of “transient” meta tags that are only added to the page when it is initially loaded, but not after a postback. When you call the

myHeadControl.Controls.Add(myHtmlMetaControl)

method, every control that doesn’t have a manually set ID will be assigned an automatic ID by its naming container (ctl00, ctl01, …). This doesn’t seem too bad until you realize that this means that the ID of your very important custom control can change from “…ctl08…” during initial page load to “…ctl04…” in a postback. And THAT is a problem. Because the way that the view state is restored to the control tree is directly through those control IDs. Actual results can vary from mismatched control values to view state exceptions and lots of other hard-to-trace problems.

Continue reading Prevent automatically generated IDs for controls

Categories , Tags , ,

0

Yesterday, I made my first multithreaded tests with XNA 4.0.

I started with my own WorkerThreadManager, a BlockingQueue and some WaitHandles to setup a Worker-Queue and Workers. The testproject was a an XNA-App just drawing circles and move them around (with collision detection on the walls). The first test was rather disappointing. I could run about 4x more circles in single-threaded mode than with multi-threaded approach.

After some profiling, I found that the BlockingQueuewas the bottleneck. I then found the class BlockingCollection from .Net 4.0. Using that one improved the speed quite a bit but still about 3x slower than the single-threaded one.

After some more research, I stumbled accross the brand-new System.Threading.Tasks Namespace with some quite interesting classes.
I could replace my whole ThreadManager with this little piece of code:

List<Agent> agentList = SomeHowGetSomeAgents();
Task[] tasks = new Task[agentList.Count];
for (int index = 0; index < agentList.Count; index++)
{
    Agent agent = agentList[index];
    Task t = Task.Factory.StartNew(() => DoSomeWork(agent));
    tasks[index] = t;
}
Task.WaitAll(tasks);

Nice, eh. That further improved the speed but again, it’s still about 2x slower than the single-threaded one…

So I found one more class called Parallel.
With this class, the code now looks like:

List<Agent> agentList = SomeHowGetSomeAgents();
Parallel.ForEach(agentList, DoSomeWork);

That one finally runs faster than the single-threaded approach. Three times faster!

I might need to redo all those tests when the DoSomeWork is much more sophisticated. But for now, Parallel seems the way to go for simple Worker-Threads.

More on this Topic:

Categories , Tags , ,

0

Recently I’ve noticed that a lot of my co-developers where I work don’t use a lot of tools beyond the usual VisualStudio / Notepad combo. I find that rather weird since personally I have spent a lot of time learning how to use certain tools because it makes life just that much easier. As I am pretty sure I have mentioned before, developers are supposed to be lazy. According to Larry Wall (the inventor of Perl) this is even one of the three most important virtues of a programmer – the other two being impatience and hubris. In this case I happen to agree with Larry, because the urge to avoid any kind of repetitive, mind-numbing task or do something with two clicks instead of three is what programming is all about.

Continue reading Productivity Tools

Categories Tags , , ,

0

I always forget how to Rollback a Changeset, so here’s the command to do it:

First, make sure you got the Team Foundation Server Power Tools installed.

Then execute the following command:

tfpt rollback /changeset:<changesetnumber> "<workspace>"

so for example:

tfpt rollback /changeset:48745 "C:\Workspaces\XXXComplete"

Categories