Take Ownership and Full Control in Vista

Sometimes you move a bunch of files from an old machine, in a different domain, and you want to modify those files in the new environment.  Generally, the process is to take ownership of the files, then grant yourself full control.  This can be a tedious process in Windows Vista, especially in light of LUA.  So, I present here some scripting you can use from PowerShell perform this burdensome task.

First, taking ownership is still best accomplished using the "takeown" command.  You can look the command syntax up, but if you wanted to take ownership of all the files in the current directory, you can do this from your PowerShell prompt:

gci | % { takeown /f $_}

Next, you want to grant yourself full control.  This is normally done with the cacls command, but in Windows Vista this has been deprecated and you should use the icacls command.  Here's how to grant yourself full control on all the files in the current directory, replacing your current permissions:

gci | % { icacls $_.FullName /grant:r your_domain\your_username:F }

Replace your_domain and your_username above with the information appropriate to your environment.

.NET 3.5 TDD Frameworks from the ALT.NET Scene

From the ALTNET mailing list this week, I've come across to very capable frameworks for enabling true test-driven development.  Both seem to be born out of a dissatisfaction with current implementations.

First up, I'll mention MoQ; pronounced "Maw-kyoo" or just "mawk", it is written alternatively as both moq and MoQ.  The tagline from the MoQ Google code site says it is "The simplest mocking library for .NET 3.5 with deep C# 3.0 integration."  From here, we can already say that his library isn't for everyone.  Folks working on greenfield projects or converting existing projects may be able to choose .NET 3.5, but many are working in situations where lambdas and LINQ are out-of-bounds.

Those of us lucky enough to be using Func and Action in our code will find moq to be an elegant approach to unit testing interfaces.  But, other Mocking frameworks support some of the new C# syntax, so why moq? According to Daniel Cazzulino (kzu), a developer on moq and a Microsoft XML MVP,

The value we think Moq brings to the community is simplicity through a more natural programming model.

So, what does kzu mean by "natural"?  Well, traditional mocking uses a record/playback model for setting expectations in TDD, and, due to a legacy that often extends back to .NET 1.0, they have "more than one way to do it", to use an oft invoked Perl-ism and a big reason why Perl is frequently referred to as "write once, read never".  Certainly, simpler APIs are to be preferred as long as they can get the job done, and APIs tend to become simpler and more natural over time as long as they aren't required to prevent breaking changes.  So, moq was meant to be a simpler mocking framework that leverages C# 3.0 language features.  And, so it does.

If you are just getting into TDD and are a little overwhelmed by the myriad mocking frameworks out there and their unfamiliar semantics, you should definitely look into MoQ.

Now, the next item on our agenda is Total Recall.  Okay, not Total Recall, but another story by Phillip K. Dick: Autofac; in any event, we're going to take a look at the eponymous Inversion of Control container.  Autofac is an MIT licensed project that has gotten some pixel time on the ALT.NET mailing list as of late.  The community around Autofac writes on Google code that:

Autofac was designed with modern .NET features and obsessive object-orientation in mind. It will change the way you approach dependency injection in .NET.

Well, if you aren't doing DI just yet, it will certainly change the way you do it.  If you're using many of the other .NET IoC containers out there, you're probably not leveraging lambda expressions and LINQ either, so Autofac would be a change.  Like MoQ, Autofac sheds some of the legacy cruft and fully embraces .NET 3.5 as a platform.  Also note that Autofac leverages LinqBridge to remain compatible with .NET 2.0 applications.

So, will I be doing my next greenfield project using DDD with moq, Autofac, and db4o?  Well, I don't think my clients are ready for that yet.

Advanced Web Programming Techniques: Dynamic Script Tags

I was researching some techniques for doing Comet programming, and I ran across a PowerPoint presentation on Dynamic Script Tags.  If you speak GWT, you'll find they outline this technique in their FAQ.  Here's the basic idea.

First, a little background about the Javascript Same-Origin Policy, first introduced in Netscape 2.  From The Art of Software Security Assessment blog, "same-origin prevents a document or script loaded from one site of origin from manipulating properties of or communicating with a document loaded from another site of origin. In this case the term origin refers to the domain name, port, and protocol of the site hosting the document."  These restrictions extended to XmlHttpRequests (xhr), i.e. a script cannot make an xhr to a domain other than the one from whence the script originated.

The Same-Origin Policy poses a bit of a problem for two kinds of AJAX applications.  First, the developer attempting to make xhr calls to sub-domains (see my previous post on web performance optimization) will have problems.  Generally (IE & FF only?), Resources are not of the same origin if they have a different URL, essentially.  Scripts, however, from the same top-level domain can set the document.domain property to the TLD to allow them to interact.  This doesn't solve the xhr problem.  The second type of AJAX application that can be fettered by the Same-Origin Policy is the mashup.  Most mashups proxy the browser request to get the data from the others sites.  In other word, xyzmaps.com would have all of its scripts/xhr point to xyzmaps.com which would in turn make an HTTP request to e.g. maps.google.com, essentially proxying the browser request.  This presents a huge difficulty for implementing mashups, as all requests have to be proxied through the origin server.  A more thorough understanding of the Same-Origin Policy leads us to a better solution.

If you've ever used the Google maps API or the Virtual Earth api, you'll note that you include the api in your page via script tags.  Of course, this works perfectly for many sites, but doesn't it violate the Same-Origin Policy?  It does not, in fact, because the browser rightly assumes that scripts included via tags in the document are "safe" insofar as they are not alien.  So, we can get around the Same-Origin Policy by  adding script tags from other domains in our document.  This works statically in or pages, but we can also add script tags dynamically via script DOM manipulation!  Thus, a better solution than proxying requests for our mashups is found.

So, SiteA dynamically adds a script tag whose src attribute is set to a url on SiteB that will generate JavaScript, embedding the name of SiteA's callback method in the request.

There are several other rather unsatisfactory approaches outlined at Abe Fettig's Weblog.