Enumerating All SPWebs In SPFarm.Local Into Strongly Typed Collection

So when enumerating the SPWebs within a SPFarm to build a strongly typed SPWeb collection for whatever purpose your enumeration might look like this:

[csharp]

public static List WebsPreppedForIteration()
{
var collection = new List();
foreach (SPSite x in SPFarm.Local.Services.OfType().SelectMany
(svc => ((svc).WebApplications.Where
(webApp => !webApp.Properties.ContainsKey(“Microsoft.Office.Server.SharedResourceProvider”)).SelectMany
(webApp => webApp.Sites.Cast()))).Where
(x => !Equals(x.RootWeb.Title, “Central Administration”)))
{
collection.AddRange(x.RootWeb.Webs.Cast());
}
return collection;
}

[/csharp]

I saw this in a code review today. The part I am wondering about is the SPWebApplication property bag to query the key for WCAM as opposed to do a clunky string SPWeb.Title comparison. Putting the keys out to standard output hasn’t yielded anything particularly evident, and I’m getting frustrated with the under-the-hood, unnecessary foreach loop with a fancy shirt on (the second LINQ query against the Title property(,

Does anyone know the key for WCAM?

Share

Using Bit Fields in C# (Enumerations)

So, I am currently working with several enumerations with a custom Windows Service that binds to a WebPart through some .NET Remoting calls. I am also using the System.Flags class in order to treat the enumerations as instead of a set of strings or whatever as a set of bit-wise flags, which can easily be seen when using the ToString() method. Basically, it overrides the normal underlying type that is used for the enumeration (such as System.Int32) with System.Byte. This is helpful when using combinations as opposed to building elements that are mutually exculsive. You could accomplish a similiar end result with structs if you convert it to what the embedded system would expect in memory.

In essence it looks like this, you can see that the enum I am delcaring is decorated with the FlagsAttribute:

[csharp]

[Flags]
public enum spSecurityEnum
{
firstField = 1;

secondField = 2;

}

[/csharp]

But why do it this way? There a lot of reasons why I think bitfields are a decent (notice the word decent being used here) route to go. The most compelling is, while I haven’t actually benchmarked the performance considerations on it, one could assume that because the bit field will take up less memory that it should perform much better. That and I come from a C++ background where bitfields where similiar to that in C#, well, kind of.
But man, am I thinking about reworking this approach to use something like a BitArray with an orthodox enumeration. Although the performance considerations are neat, working with bitfields in C# is turning out to be a pain in the ass in a lot of cases, some of which are carried over compliants from C++ but whatever.

The first thing that I am dying with is the debugger support. Man, for bitfields is it bad to debug your code. When using the immediate window, for the above enumeration I guess I will only see a 2. I guess that is my fault though since I am looking to truncate the code to optimize memory usage, but some sort of visual property to get the former would be sweet, like some sort of visualization representation that will take an enum that has been decorated with the FlagsAttribute and parse out a better representation in the IDE.
My next gripe with bitfields is adding new ones. I really, really wish the refactoring options that are available within Visual Studio would allow you to auto-increment your bitfields if you add a new one in the middle of the enum. I HATE having to go through and rename them all when I find out I have to insert a new one. It is driving me up the wall.

There are other things that I want to complain about, like 32 distinct limits and lack of constructor support for intialization, etc. however those two above are what I would LOVE to see built into Visual Studio are some point which would sway me to continue using bitfields.

Anyways, I am probably going to stick with bitfields for the time being, and I have to check whether Orcas supports these compliants, in which case I should just shut up.

Share