Last night, I presented at the Dallas C# SIG on behavior-driven development. During the conversation, SvnBridge came up, and I misspoke by saying that SvnBridge was a server-side thing. It is actually a client side proxy. Your SVN client points to the bridge, and the bridge points to TFS.
I had the good fortune to speak with Ayende recently when he was state-side and working with MS on SvnBridge, and though we talked about the bridge, I misunderstood this. D'oh.
I've used Process Explorer from SysInternals for a long time now. But, on my Vista x64 machine at home I had problems after select the "Replace Task Manager" option. Task Manager (or ProcExplorer) would no longer start from context menu of the Start bar.
After installing Vista x64 on my Dell Inspiron 1720 laptop (runs beautifully, BTW), I ran into the exact same problem. Tonight I decided to finally hunt it down. This post shows how to edit the registry to run Process Explorer in Vista.
However, unlike the instructions within, I just added my ProcExp path (unzipped to "C:\Program Files\SysInternals\Process Explorer\procexp64.exe") directly into the registry setting (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe, Debugger) without the SUDO utility. Apparently without UAC turned on, you don't need to elevate the privileges -- but ProcExp still doesn't know how to update the registry. Surgery complete and patient up and walking around.
And so I asked the altdotnet group. And so Glenn Block mentioned ObjectBuilder had been ported for the Mobile Client Software Factory. So, I downloaded the The MCSF. And I tried to install it. And it didn't. Requires Windows Mobile 5.0 SDK. So I downloaded it. Requires validation. Genuine Microsoft Software. Click click click. MSCF... "The installation requires the Guidance Automation Extensions, June 2006 CTP or later, which is not present." So I download GAX. oOH, Feb 2008 Update for VS 2008. Installed. Just as it is completing - it dies because there are open VS instances. Argh. So I kill the open instances. Re-download since I ran instead of saved the first time, run again. Done. Ahhhh. now for the MCSF... click click click... "The installation requires the Guidance Automation Extensions, June 2006 CTP or later, which is not present."
Aaaaaaaaannnnnnnd the short attention span kicks in.
Ah... back to a roll-your-own IoC strategy. (argh)
As I promised in my previous post on Advanced WCF, I'm going to be posting more about WCF extensibility. Before I get into the real content though, I wanted to drop a note that I picked up the book WCF Unleashed because it promised to have a lot more on WCF Extensibility than other books on WCF. While it is much better at listing out the concepts and showing some disconnected examples than other books, it doesn't really explain how or why to use some things like the Instance Context Provider.
For those of you in Dallas, you can get more on this topic in person at the Dallas C# SIG meeting this Thursday 2008.02.07 as presented by Jef Newson.
This attribute can be specified on a test class. There can be multiple instances of this attribute to specify more than one item. The item path can be absolute or relative. Relative paths are relative to the RelativePathRoot setting found in the .testrunconfig file.
The following examples demonstrate different usage of the DeploymentItemAttribute:
[DeploymentItem("file1.xml")] Deploys an item named file1.xml located at the RelativeRootPath. The file is deployed to the deployment root directory.
[DeploymentItem("file2.xml", "DataFiles")] Deploys an item named file2.xml located at the RelativeRootPath. The file is deployed to the DataFiles subdirectory of the deployment root directory.
[DeploymentItem("C:\\MyDataFiles\\")] Deploys all items and directories found within the MyDataFiles directory. This does not create the MyDataFiles directory underneath the deployment directory. All files and directories within MyDataFiles will be deployed to the deployment root directory. To copy the entire MyDataFiles directory structure, you must specify MyDataFiles as an output directory.
Of course, the truth of the matter is that I would rather use MBUnit :)
One of my clients asked me this morning how to get files into the build output directory so they are available for tests or as resources during run-time. There are a few answers to this question.
1. You could add a post-build even in your project file to copy the specific file(s) to the output directory. There is even a variable to help specify the OutDir. This is the bruit-force method and I don't recommend it.
2. An easier way is to right-click on the specific file and select Properties from the context menu. Then, in the Copy to Output Directory option, select Copy if newer. This is the built in method that provides what my client thought he wanted.
3. Finally, in ASP.NET it's possible to embed files into an assembly and reference them during run-time. This is what the client really wanted because it's more secure and easier to ensure all resources are available as an assembly is copied around to various execution environments. In short, you have to mark the file as an embedded resource, add a WebResource attribute to your code, and then use a special function to open the file. Here's a post explaining the use of the WebResourceAttribute in .NET and another post giving a little better code example of WebResourceAttribute.
I've recently had the opportunity to join a client's team building an ESB solution using the Windows Communication Foundation (WCF) with requirements for security, logging, load distribution across a managed group of hosts, and more. As you can see from my list of books here on my site, I spent some free time over the holidays reading up on WCF. It seems that everything published about WCF so far just covers how to write and host services.
The best references I've found on extending WCF are Mark Gabarra's blog and this great, detailed MSDN article on WCF extensions by Aaron Skonnard, which gives full examples of extending WCF in a variety of ways, including behaviors. I'm currently prototyping a WCF service with extensions at a variety of points and will post more as I make progress.
David Haydenblogged about LinqPad a good while back (Sept). I've been under a rock, so I haven't seen it until now. I downloaded, I used it, and I love it. Very cool. It's free, and well worth the download if you're interested in learning linq, extension methods, etc.