Hopefully, this post will help the search engines to set the record straight about the InternalsVisibleTo attribute for creating friend assemblies. A number of notable .Net voices (Oliver, Juval, James World) used this attribute in pre-RTM code, when the public key token was used, but Microsoft changed it in the release.

In one post in particular, a commenter, Neil, was trying to say that PublicKeyToken isn't available for InternalsVisibleTo - only PublicKey is. C# MVP Oliver Sturm counters by explaining that it seems pointless to use the whole public key, since it is so much longer to copy than the public key token. While this is true, he apparently was unaware of the change when he wrote this. It was changed in .Net 2.0 RTM. MSDN, after remaining inaccurate after release for some 9 months, now shows the correct syntax.

Update: David Kean also points this change out, and notes that it was changed in RC1, which if I recall correctly was released right after the PDC and right before the November RTM. David also has a nifty utility which generates the otherwise onerous attribute for you. Nice.

This method sounds cool - like it would enumerate ODBC sources on a machine.

However, it's not overridden from its base class, DbProviderFactory, which is implemented like so:

public virtual DbDataSourceEnumerator CreateDataSourceEnumerator()
{
    return null;
}

UPDATE:

IEnumerable<Foo> GetFooItems()
{
        yield break;
}

...is what I want.

Given a method that returns an IEnumerable, you can use the C# 2.0 "yield" statement to return the next item in the enumeration. What if you want to return an empty enumeration? The only way I've found to do this is the following:

    if (false) 
          yield return null; 

Any other ideas?

I found this while reflectoring. It appears that certain generic types are preloaded in order to prime the JIT compiler, and reduce type allocation (setting up MethodTables and EEClasses) latency.

A reasonable thing to do, and probably testing of the framework found unsatisfactory results, so hacks were inserted, and clearly labeled. I wonder if a subsequent service pack will eliminate these?

Ok, this isn't exactly clear. Need to make a note of this so I don't forget it. The DirectorySeacher only returns 1000 results when the defaults are used. This setting actually comes from an AD server, not the .Net stuff, or even the ADSI or LDAP protocol implementation which are under the covers. So, basically, it's as good as hard-coded. ADSI helps out here, and we can take advantage of it, by just setting the DirectorySearcher.PageSize to a number besides 0. I like to set it to the DirectorySearcher.SizeLimit default which is 1000 (actually, it's 0, but this means 1000). This actually makes ADSI make as many paged requests as needed to get the entire result set, not just the first SizeLimit records. The docs aren't terribly clear on this, and I try to make repeated requests to the server until the resulting SearchResultsCollection's Count property is less than the searcher's PageSize property... which doesn't work since ADSI has done this bit for me and now I'm sitting with all the results in the collection. Here's how to get all the users (with a few properties) in the domain [in IronPython]:

import clr
from System import *
clr.AddReference("System.DirectoryServices")
from System.DirectoryServices import *
from System.Collections.Generic import *

searcher = DirectorySearcher()
searcher.PageSize = 1000

def GetDomainUsers():

  searcher.Filter = "(&(objectClass=user)(sAMAccountName=*)(!objectClass=computer))"
  searcher.PropertiesToLoad.Add("userPrincipalName")
  searcher.PropertiesToLoad.Add("userAccountControl")
  searcher.PropertiesToLoad.Add("sAMAccountName")
  l = List[SearchResult]()
  domainResults = searcher.FindAll()

  l.AddRange(domainResults)
  domainResults.Dispose() # Get rid of the unmanaged ADSI resources ASAP

return l

NTFS is a very robust and well architected file system. I like it. I've looked at others, like WinFS (not really a core FS, just a layer on NTFS... but good technology idea nonetheless), ReiserFS 4 (my favorite, at least conceptually), XFS and JFS. NTFS plays in the same league with these higher performance creations from the previous age Unix heavyweights, including transactions (Vista and Longhorn), journaling, compression, encryption and a peerless access control system (in my experience). Along with all of this is support for paths which are 2^15 (32768) characters long. This beats the 260 chars of MS-DOS legacy.

Oddly, this is hardcoded into two places - Win32 and the CRT:

<WinBase.h> ... #define MAX_PATH 260

<stdlib.h>      ... #define _MAX_PATH 260 /* max. length of full pathname */

However, help is at hand... From the MSDN docs:

Note The C Runtime supports path lengths up to 32768 characters in length, but it is up to the operating system, specifically the file system, to support these longer paths. The sum of the fields should not exceed _MAX_PATH for full backwards compatibility with Windows 98 FAT32 file systems. Windows NT 4.0, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003, and Windows Server 2003 NTFS file system supports paths up to 32768 characters in length, but only when using the Unicode APIs. When using long path names, prefix the path with the characters \\?\ and use the Unicode versions of the C Runtime functions.

But, try creating a DirectoryInfo prefixed with \\?\ ... you'll throw an exception since it contains an invalid path char (?). Too bad, since people are finally getting the hang of long file names... one more legacy to detract from the shininess of Vista.

I've opened a Connect issue... if you run into this, be sure to vote for it.

• Use the tilde character - "~" - in server controls and code, since it parses this out to mean "this application's root URL". Don't try to use this in JS or other client-side stuff, though.
• HttpRequest.ApplicationPath provides this same info, but is less declarative and more clutter
• HttpRequest.CurrentExecutionFilePath gives you the app root, any folders and the executing page. This is true even after a Server.Transfer or a Server.Execute.
• HttpRequest.FilePath is similar, but gives the original (calling) page after Server.Transfer or a Server.Execute.
• HttpRequest.Path returns the current URL path, exluding the host (and related kit). This also includes any "trailers" after the page, like .../default.aspx/blah/blah/blah
• HttpRequest.PhysicalApplicationPath is the root path on the disk of the server where the application lives - corresponding to ApplicationPath. Don't send this to the client.
• HttpRequest.PhysicalPath is the physical path of the currently executing page.

I never questioned why C++ needs .h files - I just accepted it. Definitions go into .h files, and code goes in .cpp or .c files. Strange, I know - me just accepting without questioning. Huh. I suppose it was the nice side effect of having the .h file be your API definition. But that's not really why it _has_ to have one. You need it because the C++ compiler is a clunky beast which only does a single pass through the code. Sure, there is some history for this, but there really isn't a tenable argument to be found why it should stay this way.

I found all this out by trying to resolve a circular reference among objects which I am creating to wrap the Shapefile library by Frank Warmerdam. This post helped me unravel that issue, and deduct the real reason behind .h files.

So basically, you can do this:

In ShapeObject.h:

                // a "stub" definition for the related class which contains ShapeObject
                ref class ShapeFile;

	public ref class ShapeObject
	{
	private:
		Boolean		_isDisposed;
		SHPObject*	_internalHandle;
		Int32		_index;
		ShapeType	_type;

                                // Now we don't get a compilation error here
		ShapeFile^	_parentFile;
                                .
                                .
                                .
                };

And in ShapeFile.h:

                #include "ShapeObject.h"
	public ref class ShapeObjectsCollection : public System::Collections::Generic::List
	{
	public:
		ShapeObjectsCollection() { }
	};

	public ref class ShapeFile
	{
	
	private:
		ShapeObjectsCollection ^ _shapes;
                                .
                                .
                                .

                 };

public sealed class Role

{

    private string _roleName;

      {

          foreach( Role r in this )

              if( r.RoleName == roleName ) return r;

          return null;

       }

   }

}

Now I can have my cake and eat it too. Yum.

-rory