One thing I really love about Linq is how succinctly you can write import and export code. I've had to do this many times before Linq and it always felt kludgy no matter how clean you did it (Especially building xml documents). I think the decision to bake a set based syntax into C# and VB.NET was a great idea. So here is yet another Linq code sample, aren't there already a million of them out there??

Exporting data from a SQL Server table to xml using Linq2Sql and Link2Xml:

          TestDataContext dataContext
= new TestDataContext(@"Data
Source=localhost; Initial Catalog=Test;Integrated Security=True"); XDocument export
= new XDocument( new XElement( "clients", new XComment("This
is a comment!"), from client in dataContext.Clients orderby client.State,
client.City select new XElement( "client", new XAttribute("id",
client.Id.ToString()), new XElement("name", new XText(client.Name)), new XElement("address", new XText(client.Address)), new XElement("address2", new XText(client.Address2)), new XElement("city", new XText(client.City)), new XElement("state", new XText(client.State)), new XElement("zip", new XText(client.Zip)), new XElement("comments", new XCData( string.Format("{0}
is based out of {1}.", client.Name, client.State))) ) ) ); export.Save(@"D:\Temp\Clients.xml");

Importing data from an xml document to a SQL Server table using Linq2Xml and Linq2Sql (And as Anon pointed out we can do a direct cast since the XAttribute (And XElement) class define explicit conversion operators for primitive types. On that note we also dont need to check if the XElement or XAttribute is null. The Linq2Sql entity defines fields (Or properties) as nullable types and the XElement and XAttribute classes define conversion operators for nullable primitive types. So if an attribute or element does not exist the entity value is simply set to null.):

          TestDataContext dataContext
= new TestDataContext(@"Data
Source=localhost; Initial Catalog=Test;Integrated Security=True"); XDocument document
= XDocument.Load(@"D:\Temp\Clients.xml"); var clients
= from client in document.Element("clients").Elements("client") select
new Client() { Id = (int)client.Attribute("id"),
Name = (string)client.Element("name"),
Address = (string)client.Element("address"),
Address2 = (string)client.Element("address2"),
City = (string)client.Element("city"),
State = (string)client.Element("state"),
Zip = (string)client.Element("zip")
}; foreach (var client in clients)
dataContext.Clients.InsertOnSubmit(client); dataContext.SubmitChanges();

Our build AD account needed the ability stop/start Windows services so that it can deploy them. I looked all around and found a simple solution using the subinacl utility from Microsoft (For more info see "Method 3" on this page.) The following command will give an AD user full rights to the service specified. I tried to only give it stop and start permissions but couldn't figure out the right combination of flags to make this happen (And no its not 'TO').

SUBINACL /SERVICE \\MyServer\MyServiceName /GRANT=MyDomain\MyUser=F

The latest version of the Enterprise Library can be downloaded here. I'm happy to find the bug where the XmlLogFormatter was not escaping invalid characters has been fixed!

Adding custom token handlers to the LAB TextFormatter is fairly simple. The following formatter adds an "arrow" token (" --> ") to  the formatter.

          using Microsoft.Practices.EnterpriseLibrary.Common.Configuration; using Microsoft.Practices.EnterpriseLibrary.Logging.Configuration; using Microsoft.Practices.EnterpriseLibrary.Logging.Formatters; namespace MyLibrary.Logging.EnterpriseLibrary
{ [ConfigurationElementType(typeof(CustomFormatterData))] public
class CustomTextFormatter : TextFormatter { #region Private
Fields private static readonly Dictionary<string, TokenHandler<LogEntry>>
tokenHandlers = new Dictionary<string, LogEntry>>(); #endregion
#region Constructors static CustomTextFormatter()
{ tokenHandlers["arrow"] = GenericTextFormatter<LogEntry>
.CreateSimpleTokenHandler(" --> "); } public CustomTextFormatter(NameValueCollection parameters)
: this(parameters.Get("template"))
{ } public CustomTextFormatter() : this(null,
tokenHandlers) { } public CustomTextFormatter(string template)
: this(template, tokenHandlers) { } protected CustomTextFormatter(string template, Dictionary<string, TokenHandler<LogEntry>>
extraTokenHandlers) : base(template, extraTokenHandlers)
{ } #endregion } } 

A few things to note: 1) If you want to define the formatter in configuration, you must add the CustomFormatterData attribute to the class. Don't try to add the the TextFormatterData attribute as I did (Because I did not pay close enough attention to the documentation!) and spend hours in Reflector trying to figure out why a TextFormatter object is created and not the derived type... This, by the way, has to do with the Assembler attribute on the nnnFormatterData class. This attribute references an assembler class that will instantiate the specific type (In this case the XmlLogFormatter), NOT the one specified in configuration. You could also define your own custom FormatterData and Assembler classes but the using the CustomFormatterData class is much simpler. 2) Again, if you want to define the formatter in configuration, you will need to add the constructor that accepts the NameValueCollection of configuration parameters. You can then grab the template parameter from this collection. 3) Create a static list of handlers that gets initialized once by a static constructor. There is no need to keep recreating these objects every time the formatter is created.

To define the formatter in configuration, specify the class reference like you normally would, just point to the new class. You can now use the token you defined in your class.

          <
          formatters
          > 
           <
          add 
          name
          ="EventLogFormatter" template="Timestamp{arrow}{timestamp}&#xD;&#xA;Message{arrow}{message}&#xD;&#xA; ..." type="MyLibrary.Logging.EnterpriseLibrary.CustomTextFormatter,
MyLibrary" /> </formatters>

The result is as follows:

Now obviously you'll want to do more than add a simple token. In our next installment we will show you how to add a parameterized token. See you next time.

I have been having XmlTraceListener woes... None of which are showstoppers just major time wasters! The following bug is fixed as of version 4.1! The first of which has to do the message. The message is notescaped and/or CDATA qualified. So if you have an ampersand or greater/less than sign in the message it will throw this cryptic error:

An error occurred while parsing EntityName. Line x, position y.

I ended up manually running the log entry object through the Format() method on the XmlLogFormatter class to get the raw xml and see what exactly it was complaining about. Sure enough there was an ampersand. Adding an extension method to the string class and manually escaping the LogEntry message alleviated this to some degree. Bad thing is though, the message is escaped for all listeners and you probably don't want to see HTML entities in your event log entry or email message. I think the only way around this would be to write your own xml trace listener.

          
            namespace MyApp.Runtime.Extensions
{ public static class 
          
            String { public
static string EscapeUnsafeXmlCharacters(this string value)
{ return value.Replace("<", "&lt;").Replace(">", "&gt;").Replace("&", "&amp;");
} } }
        

Issue #2 has to do with where the log file is saved. The FlatFileTraceListner actually saves the log file relative to the application root (Where the .config file is). Take a look at the RootFileNameAndEnsureTargetFolderExists() method in the FormattedTextWriterTraceListener class (The FlatFileTraceListener's base class). Before it passes the filename to it's base class constructor, it runs it through this method. The XmlTraceListener on the other hand does not follow this pattern which had me going nuts trying to figure out what I was doing wrong (Thinking that it just wasn't saving at all). I wasn't getting any errors from the XmlTraceListener (More on this below) so I started to get the feeling that perhaps it was writing to the log but just not where I expected. So I fired up Process Monitor and didn't see any log writes. Then I switched the app (It was a web application project BTW) to use the built in web server instead of IIS. Ran everything again and voilà:

So it was saving it somewhere else, but only when running under the built in web server. Looking at the code in reflector you can see that, unlike the FormattedTextWriterTraceListener, the XmlWriterTraceListener does not modify the path to be the application root before it passes it to it's base class constructor. So the directory ends up being that of the entry assembly. Bottom line is you have to supply an explicit path when you're using the XmlTraceListener in a web application.

This leads me to the third oddity; where it would save running under the builtin web server but not IIS. The base class, TextWriterTraceListener, calls the EnsureWriter() method (Shown below) before writing to the file. If it returns true it writes the entry, otherwise it doesn't. Notice that if there is a UnauthorizedAccessException it just returns false and then subsequently, in the calling Write method, silently skips writing. When I was using IIS as my web server (And the code was running as the Network Service account) I didn't see any exceptions and no log writes were showing up in Process Monitor. Which was very confusing! But when I switched over to using the built in web server (Which was obviously running as my interactive account) I saw the log writes. So when it was running under the Network Service account it obviously did not have permissions to save the log file to wherever it was trying to save it and no exception was raised... Very confusing behavior this. Reminds me of the advice in Jeffrey Richter's CLR Via C# book not to ever swallow exceptions! So keep that in mind, if you don't see any errors and log writes with the XmlTraceListner, it may be permissions and/or path related.

Well, hopefully this wasn't too long winded and hopefully it clears up some oddities with the XmlTraceListener.

          public class 
          TextWriterTraceListener :
TraceListener { public override void Write(string message)
{ if (this.EnsureWriter())
{ if (base.NeedIndent)
{ this.WriteIndent(); } this.writer.Write(message);
} } internal bool EnsureWriter() { bool flag
= true; if (this.writer
== null) { flag = false; if (this.fileName
== null) { return flag;
} Encoding encodingWithFallback = GetEncodingWithFallback(new UTF8Encoding(false)); string fullPath
= Path.GetFullPath(this.fileName); string directoryName
= Path.GetDirectoryName(fullPath); string fileName
= Path.GetFileName(fullPath); for (int i
= 0; i < 2; i++) { try { this.writer
= new StreamWriter(fullPath, true,
encodingWithFallback, 0x1000); flag = true; break;
} catch (IOException) { fileName = Guid.NewGuid().ToString()
+ fileName; fullPath = Path.Combine(directoryName, fileName); } catch (UnauthorizedAccessException)
{ break; } catch (Exception)
{ break; } } if (!flag)
{ this.fileName = null;
} } return flag; } //
Other members removed for brevity... }

If you have a host name set in your hosts file pointing to your loop back address and you are trying to connect to your local SQL Server instance with this host name using Windows Auth (SSPI) you may receive one of the following errors depending on how you have things configured:

"Login failed for user ''. The user is not associated with a trusted SQL Server connection."

Or

Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

There could be a number of things causing this error (here, here, here and here) but it in the specific scenario noted above it's probably that an alias is not set for the SQL Server. I'm not sure exactly why or how this works or why the above scenario would have an issue but creating an alias seems to resolve it. In fact if you specify "localhost" or the loopback address as the server name it works fine (Without the alias). Also when connecting to a remote SQL Server with a host name defined in the hosts file it works fine as well. hmmmm.... I really couldn't find any info on this specific scenario and creating the alias seems to resolve it so I finally gave up. If you have any more info on why this would happen please leave a comment. You can set the alias as follows:

1. 1) Open the SQL Server Configuration Manager under Start|Programs| Microsoft SQL Server 20xx| Configuration Tools| SQL Server Configuration Manager.
2. 2) Under the SQL Native Client Configuration node select Aliases.
3. 3) Right-click and select “New Alias…”.
4. 4) Enter the following information and press OK:

1. Alias Name: sql.somedomain.com
2. Port No: 1433
3. Protocol: TCP/IP
4. Server: 127.0.0.1

The connection string would be as follows:

server=sql.somedomain.com;database=SomeDatabase;Integrated Security=SSPI

Yes, there is a lot of classic ASP still out there..... *sigh*... My boss ran into an issue with a client of ours where we were redirecting to a link with a comma in it in a classic ASP page. The classic ASP Response.Redirect escapes commas before performing the redirect therefore invalidating the link (BTW, ASP.NET does not do this). Unfortunately you cannot change this behavior so the only workaround we could find is manually setting the HTTP status and location header.

Response.Status = "302 Object moved"
Response.AddHeader "Location", "http://www.somesite.com/yada,yada,yada/default.html"
Response.End

Recently I had the need to setup multiple SSL enabled sites on my local machine for development. These sites all had the same root domain but differed by sub domain. Traditionally you need to have a certificate and an IP address per SSL binding because of a "chicken or the egg" problem resolving the host headers in an encrypted HTTP conversation. If you have multiple sites with a common root domain that require SSL you can get around this limitation by using a wildcard certificate for all those sites.

So first I setup mappings in my hosts file (<SystemRoot>\System32\drivers\etc\hosts) as follows:

# SomeSite Dev Mappings
127.0.0.1          www.dev.somesite.net
127.0.0.1     services.dev.somesite.net
127.0.0.1        admin.dev.somesite.net

Next I need to create a self signed wildcard certificate. If you tried the self signed cert "feature" in IIS7 you probably quickly discovered that it is pretty much worthless since you cannot define the common name (CN), it's automatically set to the host name (Why does MS have a habit of giving you a powerful, feature rich car that can only make right turns?). One way to get around this is to generate your self signed cert with a tool and add it to the local machine store. IIS6 ships with a util called selfssl but this requires you to install the IIS6 ResKit (See more about that here). While this works, it bothers me to install tools from a previous version of IIS to accomplish this. Shouldn't the newer version of IIS do more than it's predecessor? One other alternative I found on the internets is to use the certificate creation tool that ships with the .NET 2.0 SDK. For some reason this "feels" better than using a tool from IIS6, probably just a mental thing... Plus you probably already have the SDK installed and are using it.

First create the self signed issuer certificate which will be set as a root cert authority (Fill in the red items):

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\makecert.exe" -n "CN=My Company Development Root CA,O=My Company,OU=Development,L=Wallkill,S=NY,C=US" -pe -ss Root -sr LocalMachine -sky exchange -m 120 -a sha1 -len 2048 -r

Next create a cert for your sites that is issued from this authority. You must specify the common name (CN=<IssuerName>) you entered above in the issuer name field below (-in <IssuerName>). Also I'm creating a wildcard certificate that will serve all sites with the dev.somesite.net root domain as this is a requirement to use host headers. If I add other sites in the future with a different subdomain I can choose this certificate and all is good. Specifying an asterisk as the subdomain will signify this (Fill in the red items):

"C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\makecert.exe" -n "CN=*.dev.somesite.net" -pe -ss My -sr LocalMachine -sky exchange -m 120 -in "My Company Development Root CA" -is Root -ir LocalMachine -a sha1 -eku 1.3.6.1.5.5.7.3.1

You should now see this cert show up in the IIS manager on the "Server Certificates" page:

Now again, MS gets you part of the way there in the UI but not all the way. As in IIS6 (SP1+) you cannot specify a host header for SSL bindings in the IIS7 UI because of, as mentioned above, issues with resolving the host headers in an encrypted HTTP request. But since we are using a wildcard certificate these issues are moot and IIS can do it but we have to configure it through the command line with the new appcmd util. The following command must be executed on each site that requires SSL. This command will create the SSL binding and set the host header. Make sure you specify the correct site name and host header for each site (In red):

C:\Windows\System32\inetsrv\appcmd set site /site.name:MySite /+bindings.[protocol='https',bindingInformation='*:443:www.dev.somesite.net']

Next go to the site bindings and you'll now see an SSL binding with a host header defined (Before this field would be disabled for SSL). You will need to select the the wildcard certificate you created earlier in the cert drop down and save your changes.

I came a cross an excellent course on the Berkeley webcast site on the history of physics. I really like the coverage of the development of classical physics starting with Newton. Cathryn really does a good job of getting you thinking in the context of the time period, avoiding contemporary terms and thought and helping you to look at things from the perspective of these scientists. She also does a great job of tying in the religious, political, economical and philosophical influences of the time and how they affected the thinking of these individuals.

History 181B Modern Physics: From The Atom to Big Science Cathryn Carson "Establishment of the ideas and institutions of modern physics. Undoing the classical world picture: radioactivity, Einstein, quantum mechanics, philosophical disputes. The evolving structure of the discipline, links with industry and government, World War II and the atomic bomb. Postwar conceptual consolidation and the emergence of big science."

Will Smith so kindly pointed out that the target file for web application projects is not installed by the .NET 3.5 redist (Along with msbuild). To fix this you can copy over the target file from a machine with VS2008 installed to the same folder on build server. The target file can be found under <ProgramFiles>\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications.

When setting the target framework (IE: nant -buildfile:some.nant -t:net-3.5) the Nant script fails with a null reference exception and the message "Microsoft .NETFramework3.5 (net-3.5) is not installed, or not correctly configured." Looks like this is resolved in the latest nightly build found here.

If you are receiving the above error message it may be that you installed the NantContrib task binaries under the <nant>\bin\tasks\net\20 folder (As the NantContrib readme.txt specifies). Evidently the "tasks" folder is now called "extensions" in Nant 0.86. So the proper path would be <nant>\bin\extensions\net\20.