thinking-out-loud

One other way to make files available at runtime

Todd mentions ways to make files available to tests or at runtime in VS. If you happen to be using MS Test, you have one more option that I don't believe was mentioned, the DeploymentItemAttribute. From the MSDN page:

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 :)

Making .NET project files available at run-time

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.

Advanced WCF Development

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 organized book I found that presents all the key concepts and somewhat covers extensibility through behaviors is Pro WCF by Chris Peiris and Dennis Mulder.  I've also reviewed Programming WCF Services by Juval Lowy, which has a somewhat shotgun approach development with WCF, great for coding, but doesn't really cover WCF extensibility. 

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.