It occurs to me that in the same way you can use LINQ and DLinQ to get
strong typing and operations over a objects and tables, you could use the
same method to operate over files and directories.

So within VS or at the Command Line I could start type:
\temp\dir\file.txt
And get intellisense as I go with filenames and directory names relative to
the current context.

More importantly, if EXEs supported metadata for arguments (similar to Monad
CmdLets), then you could get dynamic overloads for the parameter sets.
Something like:

                FileInfo fi = new FileInfo(@"c:\my.exe");
                Process p = fi.Run("arg1", 23, true);
                p = fi.Run(true);
                p = fi.Run();

In this case "my.exe" has metadata that understands all valid parameter
names and there types.  It also understands parameter sets which can be
thought of as static constructor overloads to pass to the Exe.  Now when I
type "fi.Run(" - I get a list of the valid overloads that can be used to
start the Exe.  Same kind of thing could be used for any document type, txt,
doc (etc), with methods and properties in the context of that document type.

That certainly is an interesting idea, although I don't know how you would
work dynamic parameter sets into the language.

Well, I am thinking first you need FileSystem and Shell support and some
standard way to include this meta data in any exe (console or windows app).
WinFS has this notion of properties that you can add to files in separate
streams of the file.  Monad, for example (as you know) uses reflection to do
this without separate streams.  Basically you define a static class that has
a public property for each parameter name.  All properties belong to one or
more parameter sets.  The cmdlet is then compiled into a standard .Net dll.
The MSH runtime then knows how to deal with these dlls.  It uses reflection
to get the parameters/types and their sets.  It then applies the command
line args to the parameter list to figure out which parm set to use and
validate input data.  If everything is ok, your dll ends up with all the
properties set and the user code can go off running and not have to parse
cmdline input.  With the proper shell and tool support, one could imagine
that when you click on a dll or exe in Explorer, you could see all the
parameters in a strongly typed input dialog to launch the app.  I don't see
any reason why standard exe assemblies could not use the same method.  If
special class "Namespace.Parameters" exists in the assembly, then any tool
can reflect over it to get all the parameters and parm sets and party on.
If it does not exist, then no change of current behavior.  You could still
have the option in your apps to process args[] manually or use the
Parameters class method.

Once this done, a LINQ provider could be developed that exposes this on
files and directories.  Then from within VS, it is just another LINQ
provider so it should just work.  At least that is the idea anyway.

Show quoteHide quote

It does make sense, although the executable could change across machines.

Anonymous types would work well though, pass an anon type to the LINQ
provider instead of using a method with dynamic properties like you
originally suggested.

Detecting a ComboBox selection
FTP Active Mode - Can't Get Server To Connect after PORT Command
Restricting entry in textbox
how to format financial value?
Speed issues with filling a list view