A couple of days ago someone pointed out to me this neat little plugin for outlook called Xobni, which is currently available for free, since it’s in a beta-testing-phase.
This plugin allows you to view some social-network-related-stuff about all the mails you received … pretty cool 🙂
So I tried to use this neat feature of VMWare to export a running virtual-machine via VNC to a remote desktop. Works great, especially if your virtual-machine (for whatever reason) is not connected to the network, and thus you cannot use remote-desktop or something similar.
But since I’m a german-keyboard-layout user, I wanted to take advantage of my keyboard-layout (hell, I just wanted to use ;!!). But I had to figure out, that this doesn’t seem to work. So first I blamed UltraVNC and so I switch to some ancient version of the good old AT&T VNC 🙂 but nothing changed.
But after some time I got to it … you need to tweak the *.vmx file of your virtual-machine. This is some setting, that is not available through the GUI … just add:
RemoteDisplay.vnc.keyMap = "<xx>"
where can be any language-code whose keyboard-layout it available in
C:\Documents and Settings\All Users\Application Data\VMware\vnckeymap.
Even though I consider myself to be quite up-to-date as far as Miranda-Plugins is concerned, but I recently noticed that some plugins are still out-of-date.
So I followed Tara’s post on the forum … 🙂
Somehow I kinda got used to the nice integration of TortoiseSVN into Windows Explorer, and I wouldn’t want to miss that. But since a lot of projects have been moved to codeplex and codeplex uses Team Foundation Server (TFS) instead of Subversion (SVN) for source-control there is some need to be able to access those repositories without much fuzz.
OK, so I tried the SVNBridge, which was developed by Ayende (cool job!!). This is very nice, you get a little kind of proxy, which allows you to use TortoiseSVN to access reporitories hosted on TFS 🙂
OK, here comes another part of pimp my whatever! Today’s feature is your always underestimated console prompt.
OK, after doing some pimping on your console, you might want to do more, to distinguish from the rest of us. Why not change the look of your prompt. How about:
set prompt=[%computername%] $d$s$t$_$p$_$_$+$g
which will give you:
[NPC008] 10.03.2008 17:54:40,76
Well, that’s neat 🙂 Or try something different:
which will yield in:
Some installations/setups of windows/internet explorer seem to prefer to open especially office documents within the browser-window, instead of starting word or excel and showing the document there.
So it turns out, that this is actually a setting of the windows explorer. Just go to Tools\Folder options\File Types select a file type of your choice (preferably a type, which is being opened within IE) and then remove the check from the setting
open in same window from the extended properties page.
I had a real hard time installing SQL-Server 2005 Reporting-Services on this one machine …
The MSI was executing just fine, but the step “removing backups” (don’t know the exact wording in english, since I’m using a german installation) seems to fail.
This is what the msi logfile has to offer:
Aktion 15:59:51: RSSP_CAInstall.28B19132_4741_4761_840F_AC515130EC08.
Aktion 15:59:52: RollbackCleanup. Sicherungsdateien werden entfernt
CA MSG : Running RSCustomAction
CA MSG : Launching C:\DOKUME~1\ADMINI~1\LOKALE~1\Temp\rsCustomAction.exe with command line parameter /i
CA MSG : rsCustomAction.exe failed to configure, Error code is: 1
Aktion 16:02:48: Rollback. Aktion wird rückgängig gemacht:
After much struggle I finally figrued something. First I installed
SharePointRS.msi without the custom actions, by executing:
OK. So next I just run the rsCustomAction.exe (which is located in my temp-folder):
This finally produced some logfiles and a more details error message. In my case the problem was, that the
web.config of my portal-site was write-protected!!
After removing the write-protection I was able to install
SharePointRS.msi just fine.
I do like the feature of shared folders in VMWare a lot, since this takes away the hassel of setting up networking and an FTP-Server or Samba or stuff, just because you want to copy a couple of files.
Well, you could also use the Drag’n’Drop feature of VWMare, which is also very nice, but it’s quite slow on big files, and might not always work right away. Also you’ll be left with a whole bunch of temp files, which made recenlty the 2GB mark on my temp-dir 🙂
Well, so since I’ve been using shared folders for quite some time on Windows-Guests, it was just yesterday that I wanted to use them on a Linux-Guest. On Windows you’ll find in the network neighborhood a machine called
.Host, which has a couple of shares (one for each shared folder). But how about Linux? After searching for a little while, I found them … in
/mnt/hgfs/ you’ll find the shared folders mounted!
OK, it had to happen sooner or later … some bone-head delete the trunk folder and committed this to the central repository!! Of course this happend 10 minutes before the final build of the first public test-release …
OK, so what to do now? First of all, check out a previous revision. OK, did that. So now check everything looks fine, everything builds just fine … OK!
So how to commit that to the repository? The repository know I checked out revision 125, but the latest revision is 126. So what next?
First make a backup of the repository (well, it’s kinda broken, but you never now what could happen next!!). Then dump everything up to revision 125:
svnadmin dump -r1:125 myrepo > my.dump
then create a new repository and load the dump:
svnadmin create myrepo
svnadmin load myrepo < my.dump
This way you’ll end up with a nice and clean repository, which is up-to-date with revision 125 … and the bogus revision 126 is gone!!
This really made my day!!
Well, since the existence of the cloned sheep Dolly we all knew, that cloning isn’t just a piece of cake! Well, here is another one:
Today I tried to update one of my development-servers to SP2 of SQL-Server 2005. Everything went just fine … really everything? Nope, the database-engine, the olap-engine and the reporting-services-engine just would not update. All I got was a snappy error
Error 29528. The setup has encountered an unexpected error while Setting Internal Properties. The error is: Fatal error during installation..
OK, some time later I figured: it had something to do with me cloning my vmware-machines to save some time. Well, now I came kicking back at me!! But surprisingly Microsoft holds the answer in Knowledge Base article 925976.