public static string SplitCamelCase( this string str )
{
return Regex.Replace( Regex.Replace( str, @"(\P{Ll})(\P{Ll}\p{Ll})", "$1 $2" ), @"(\p{Ll})(\P{Ll})", "$1 $2" );
}

enum myEnum { one, two, three, four, five, };
foreach (int i in Enum.GetValues(typeof(myEnum )))
{
myEnum myItem = (myEnum )Enum.ToObject(typeof(myEnum ), i);
System.Diagnostics.Debug.WriteLine(myItem.ToString());
}


I needed to determine whether several assemblies were built as “Debug” or “Release” code this afternoon. They didn’t have any debug symbols with them, so that was no help. A bit of searching led me to the code below.

private void testfile(string file)
{
	if(isAssemblyDebugBuild(file))
	{
		MessageBox.Show(String.Format("{0} seems to be a debug build",file));
	}
	else
	{
		MessageBox.Show(String.Format("{0} seems to be a release build",file));
	}
}

private bool isAssemblyDebugBuild(string filename)
{
	return isAssemblyDebugBuild(System.Reflection.Assembly.LoadFile(filename));
}

private bool isAssemblyDebugBuild(System.Reflection.Assembly assemb)
{
	bool retVal = false;
	foreach(object att in assemb.GetCustomAttributes(false))
	{
		if(att.GetType() == System.Type.GetType("System.Diagnostics.DebuggableAttribute"))
		{
			retVal = ((System.Diagnostics.DebuggableAttribute)att).IsJITTrackingEnabled;
		}
	}
	return retVal;
}

The overloaded “isAssemblyDebugBuild” method will accept either a string containing the fiull filename, or a System.Reflection.Assembly object. It will return its best guess as to whether the the assembly is a debug build, as a boolean.

To call the methods as they are (to get a MessageBox), just use something like

testfile(@"C:\myUnknownAssembly.dll");

or access the underlying methods directly :

bool isDebug = isAssemblyDebugBuild(@"C:\myUnkownAssembly.dll");

I hope someone can use this to save themselves some time.

1. Set the “KeyPreview” property of the form to “True”
2. Create a KeyUp event handler, eg

   private void Form1_KeyUp(object sender, System.Windows.Forms.KeyEventArgs e)
   {
     if(e.KeyCode == Keys.F12)
     {
       // Do something here
     }
   }

3. Wire the event handler up to the event

That is all.

using System;
using Microsoft.SharePoint.Portal;
using Microsoft.SharePoint.Portal.Topology;

namespace SPConnStrings
{
  ///
  /// Summary description for Class1.
  ///
  class Class1
  {
    ///
    /// The main entry point for the application.
    ///
    [STAThread]
    static void Main(string[] args)
    {
      //
      // TODO: Add code to start application here
      //
      TopologyManager topology = new TopologyManager();
      PortalSite portal = topology.PortalSites[new Uri("http://cleanportal")];
      Console.WriteLine("Site db :: " + portal.SiteDatabase.SqlConnectionString.ToString());
      Console.WriteLine("Profiles db :: " + portal.UserProfileDatabase.SqlConnectionString.ToString());
      Console.WriteLine("Services db :: " + portal.ServiceDatabase.SqlConnectionString.ToString());
      Console.ReadLine();
    }
  }
}

The first requirement for this method is that your web parts must be strong named. I would recommend creating a new keyfile specifically for web part assembl
ies that you want to fully trust. Use the following command to do so.

sn.exe -k c:\keyfiles\FullTrustWebParts.snk

Apply this key file in the AssemblyInfo.cs file for your web part project

[assembly: AssemblyKeyFile(@"c:\keyfiles\FullTrustWebParts.snk")]

Build and deploy your project as normal.

Now for the fun part – configuring Sharepoint to accept the signed web parts as fully truted.

In the folder C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\CONFIG copy your wss_mediumtrust.config file to wss_trustsigned.config and then open the new file for editing.

Find the section that starts with the following

<codegroup class="FirstMatchCodeGroup"
   version="1"
   PermissionSetName="Nothing">
   <imembershipcondition class="AllMembershipCondition"
      version="1"
   /&gt

and add the following immediately after this code

<codegroup class="UnionCodeGroup"
   version="1"
   PermissionSetName="FullTrust">
      <imembershipcondition class="StrongNameMembershipCondition"
         version="1"
         PublicKeyBlob="...see note below..."
      />
</codegroup>

The test “…see code below…” needs to be replaced with the public key blob from your assembly. To find this string, use the following command

secutil.exe -hex -s <path to assembly>

Important : remove the leading 0x from this string

Save and close the new file.

Next, open up the Web.Config file from the root of your Sharepoint site. In my case, this resides at c:\inetpub\wwwroot\intranet\web.config

In this file, find the “securityPolicy” section. Copy one of the “trustLevel” nodes, and change the “name” attribute to “wss_trustsigned”, and also the policyFile attribute to reflect the path to your new policy file (ie. C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\CONFIG\wss_trustsigned.config)

Once you have added the policy setting, you will need to find the “trust” node within the “system.web” section. Change the value of the “level” attribute to “wss_trustsigned”. This is the value you set in the previous step.

Now save the file, and restart IIS. Your web parts should be fine now.

*NOTE* this has not been tested step by step from these instructions. I will chek it all this week, given the chance, and make any changes that might be necessary. I’m afraid that this is due to having to try to remember what a colleague did 12+ months ago. Ho-hum.

Many times, my scripts would fail periodically, but not in predictable places. After looking at the logs I generate, I noticed that there were a lot of “out of memory” errors caused by WMI operations. I needed a quick fix, so I came up with this (horrible and hacky) workaround.

Before each section of code, restart the “winmgmt” service. That’s it. The scripts now work flawlessly – or at least, they fail in predictable places now.

**EDIT**

I have just been pointed towards this page which details how to increase the amount of memory available to WMI from its default of 128MB.

As far as I am aware, there is no mechanism within the .NET framework to deal with this kind of thing, so I had to resort to the following syntax:

echo y| cacls path /E /T /P username:F

Unfortunately, the command “echo” is a pseudo command contained within the command shell.

To get around this, I had to use the following for the process.

Process runner = new Process();
runner.StartInfo.FileName = "cmd.exe";
runner.StartInfo.Arguments = "/C echo y| cacls path /E /T /P username:F";
runner.Start();

There is probably a more elegant way to do this, but that’s what I came up with in the time allowed.