.NET

The Wonders Of InternalsVisibleTo

Jason Whitehorn — Sat, 10 Nov 2007 02:53:30 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/11/09/The-Wonders-Of-InternalsVisibleTo.aspx

I do not know how I missed this, but just today I found out that you can expose an assembly's internal methods/properties/classes to a "friend" assembly. Normally internals are only accessible to members of the same assembly, and are often used to hide "plumbing" methods and utilities classes.

For many reasons you often want to separate your code into multiple assemblies, perhaps one for each application layer or some other logical boundary. A problem arises when two or more assemblies need access to each others internals. Prior to .NET 2.0 you had two choices, either expose these plumbing methods as public, or lump as much of your code into one assembly as was needed to keep the plumbing internal.

In comes .NET 2.0's InternalsVisibleTo attribute. This attribute is applied on the assembly level, and allows the assembly to give internal access to specific assemblies.

For example:

Say you have two assemblies, MyExample.DomainObjects & MyExample.ServiceLayer. In the DomainObjects assembly you have the following abstract class:

namespace MyExample.DomainObjects{
     public abstract class DomainObject{
          //.... other things....
          public virtual DateTime LastModifiedDate{
               get { ... }
               internal set { ... }
          }
     }
}

In the above example you would like to have your service layer in a separate assembly from you domain objects. You would also like to have a LastModifiedDate property for each of your domain objects, but you would prefer if it was only settable by your service layer.

This is were the InternalsVisibleTo comes in handy. In the DomainObjects assembly you can added the InternalsVisbleTo attribute to give only the ServiceLayer assembly access to any and all internal items. For unsigned assemblies the attribute would look like:

[assembly: InternalsVisibleTo("MyExample.ServiceLayer")]

This is straight forward when the target assembly is unsigned, but gets a little more difficult when the target assembly is signed. For signed assemblies you will need the assembly's public key. This is not to be confused with the assembly's public key token, which is often what you see. To acquire the public key of a signed assembly you will need the "sn.exe" tool that ships with Visual Studio.

From the "Visual Studio Command Prompt":

sn -Tp c:\Users\jason\projects\MyExample\MyExample.ServiceLayer.dll

NOTE: the "sn" command takes a big "T" and a little "p" for the switch, and you will need to replace my example path with your own ;-)

Whats pops out of this handy little program is both the public key, and the public key token. The one we needs is the longer one, the public key. With this in hand we can now add the appropriate attribute to our DomainObjects assembly.

[assembly: InternalsVisibleTo("MyExample.ServiceLayer, PublicKey=0024000004809{key shortened for readability}30a09825a6999")]

NOTE: The public key is much longer than what is shown above. The above sample is intentionally incorrect for legibility. For this to work you will need to copy and paste the public key in its entirety.

With the public key added to the assembly name on the attribute our example ServiceLayer assembly can access the internals of the DomainObjects assembly.

Additionally, since the InternalsVisibleTo attribute references the friend assembly by its string name, no real dependency is created from our DomainObjects assembly to our ServiceLayer assembly. The DomainObjects assembly will continue to work with or without the ServiceLayer assembly present.

Enable MS DTC on Windows Vista

Jason Whitehorn — Thu, 01 Nov 2007 03:10:18 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/10/31/Enable-MS-DTC-On-Windows-Vista.aspx

To enable MS DTC on Windows Vista simply follow the instructions from:

http://technet2.microsoft.com/windowsserver2008/en/library/1f6d0a27-533b-4516-8656-b492f1649e9f1033.mspx?mfr=true

MS DTC appears to be required to use System.Transactions against SQL Server, and is disabled by default.

A Possible Solution To The .NET 3.5/Visual Studio 2005 Feud

Jason Whitehorn — Tue, 03 Jul 2007 21:12:30 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/07/03/A-Possible-Solution-To-The-NET-35Visual-Studio-2005-Feud.aspx

In my previous post I discussed a problem of developing ASP.NET 2.0 applications in Visual Studio 2005, while having the .NET 3.5 framework installed. In summation, the issue was because Visual Studio 2005 was linking against a library that shipped with .NET 3.5 instead of the explicitly referenced version from the web.config.

The comments of one reader of my previous post mentioned using binding redirection to resolve the issue. In short, it looks like they were correct. As best as I can tell, binding redirection does in fact fix this issue.

Binding redirection is the ability to take a pre-compiled application and tell the loader to link against a different version of a library than the application was originally built with. In our case, we would need to add the following configuration to our web.config.

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Web.Extensions" publicKeyToken="31bf3856ad364e35"/>
        <bindingRedirect oldVersion="2.0.0.0" newVersion="1.0.61025.0"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

The above configuration tells .NET to use System.Web.Extensions version 1.0.61025 instead of version 2.0.0.0. While the above does pose to be a solution to the problem, it is concerning that this would be needed at all.

NHibernate Criteria Queries

Jason Whitehorn — Sat, 30 Jun 2007 18:34:44 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/06/30/NHibernate-Criteria-Queries.aspx

NHibernate's support for criteria queries provides an extremely powerful query feature into an easy to use package. NHibernate has a rather complete manual that covers criteria queries, which you can checkout here.

The NHibernate documentation has a ton of information packed within it, and can be a little overwhelming for those who are new to NHibernate. So, as an argumentation to the documentation for criteria searching, I will provide a really basic overview of how things work.

The NHibernate session exposes a method called "CreateCriteria", which accepts a Type and returns an ICriteria. This is the starting point for any criteria query. The Type you pass the method, is the same Type that you are querying for. For example, if you have a business object call "Customer" that we want to search for using criteria, you would:

ICriteria crit = session.CreateCriteria(typeof(Customer));

Now that you have created an ICriteria object to represent your search, you need to start specifying various criteria for the object NHibernate will fetch. This is were the "Add" method comes in handy.

The Add method accepts any ICriterion object, but to help you along NHibernate provides the "Expression" object which has many static methods to help you form your criteria. Continuing with our running example, if you want to select customers who are older than 21 years of age you would:

crit.Add(Expression.Gt("Age", 21));

The above code tell NHibernate that the "Age" property of our Customer object needs to be greater than the value 21. In the above manor, you can use the Add method and the Expression object to specify exactly which objects you want to retrieve.

To actually fetch our objects from the database, you execute the "List" method on the ICriteria object.

IList results = crit.List();

There are many more capabilities of criteria queries in NHibernate that I have not even touched upon, which you can read more about in the official NHibernate documentation.

Parsing RSS From C#

Jason Whitehorn — Wed, 27 Jun 2007 03:07:55 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/06/26/Parsing-RSS-From-C.aspx

I set out to write a RSS parser in C#. I know that several existing libraries are available for .NET that parse RSS streams, but out of curiosity I wanted to give it a go anyway.
Before I get started, for those interested in RSS libraries for .NET checkout RSS.NET or RSSConnect, to just name two.

As .NET developers we have some really powerful tools available to us that are built directly into the .NET framework. Take, for example, Serialization. In .NET we can turn an object into an XML resource using the XmlSerializer class, provided that the class is Serializable. In fact, the XmlSerializer object will even attempt to populate an object from an XML resource.

Visual Studio ships with a tool called XSD which can turn an XML Schema Definition into a C# class. Knowing that RSS is expressed as an XML resource, I set out to find an XSD for RSS. After some searching I found this site, which contains an XSD for RSS that the site's author wrote. For posterity I have placed a mirror of that file on my own site, which you can find here.

Before continuing on, I need to pause and look ahead. The XSD that I found did not work out of the box, and I had to make a small modification to get it to work. I removed a reference to the RSS schema namespace from the XSD. The modified XSD can be downloaded from here

Now, armed with an XSD, we can have the XSD program make some classes for us. From a command prompt (preferable the "Visual Studio Command Prompt" command prompt) type:

xsd RSS20.xsd /classes

Provided that RSS20.xsd is the name of the RSS XSD, and that you are currently in the same directory as RSS20.xsd, the XSD program should output a single file called RSS20.cs. The C# source file that XSD produced contains a class definition for each RSS entity, most notable the root node called "rss".

With classes that represent RSS, we can now use the XmlSerializer object to easily populate an object with RSS data. For example:

     string rssXml = "... your rss data here ...";
     XmlSerializer helper = new XmlSerializer(typeof(rss));
     rss obj = (rss)helper.Deserialize(new StringReader(rssXml));

The above code snippet, will create an rss instance called "obj" from raw RSS data. But, you don't want to have to do this everytime you want to parse RSS. Instead, it would be helpful if that logic was encapsulated by the rss object. Fortunately, the classes produced by the XSD program are all partial classes. So, in a separate .cs file, we can re-declare the rss class and expand upon its functionality.

//declare another portion of the "rss" object.
public partial class rss{
     //add more methods to "rss" here
}

Ideally it would be nice to have both a method to turn an RSS stream into an rss object, and a method to output RSS from an rss object. For example:

public partial class rss{

        public static rss Parse(string rssXml) {
            //turn an RSS string, into an rss object.
        }

        public override string ToString() {
            //turn the rss object into a RSS string.
        }
}

The above two methods can both be implemented using the XmlSerializer object, as it provides methods to serialize and deserialize and object. I ended up with the following implementation.

public partial class rss{

        public static rss Parse(string rssXml) {
            return (rss)Serializer.Deserialize(new StringReader(rssXml));
        }

        public override string ToString() {
            string result;
            using (StringWriter sw = new StringWriter()) {
                Serializer.Serialize(sw, this);
                result = sw.ToString();
            }
            return result;
        }

        private static XmlSerializer Serializer {
            get {
                if (_serializer == null)
                    _serializer = new XmlSerializer(typeof(rss));
                return _serializer;
            }
        }
        private static XmlSerializer _serializer;
}

The above implementation, combined with the output from the XSD program, is a functional RSS parser. The above code can be used to process blog output, or price feeds from your favorite online retailer.

As an added bonus, I wrote two additional methods for rss from those outlined above.

        //optionally, you can add these two methods to "rss".
        public static rss CreateFrom(Uri location) {
            rss result;
            using (WebClient helper = new WebClient()) {
                string rawRss = helper.DownloadString(location);
                result = Parse(rawRss);
            }
            return result;
        }

        public static rss CreateFrom(string location) {
            return CreateFrom(new Uri(location));
        }

For those interested, a compiled version of this code can be download from here.

Visual Studio 2005 and .NET 3.5 Don't Play Well Together

Jason Whitehorn — Sun, 24 Jun 2007 04:04:02 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/06/23/Visual-Studio-2005-And-NET-35-Dont-Play-Well-Together.aspx

As many of you have, I also have experimented with the pre-releases of .NET 3.5 and Visual Studio codenamed Orcas. I, for better or worse, installed this pre-release software on my primary development machine which has Visual Studio 2005.

Despite having .NET 3.5 installed on my machine, my primary development occurred in .NET 2.0 via Visual Studio 2005. I had not experienced any problems with this setup until the other day. While attempting to build and publish an ASP.NET 2.0 website with AJAX extensions, I ran into a cryptic server error when executing the site on a staging server. The error was:

Could not load file or assembly 'System.Web.Extensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' 
or one of its dependencies. The system cannot find the file specified.

The System.Web.Extensions assembly is the ASP.NET AJAX assembly, so at first I simply thought that the staging server did not have AJAX extensions installed. After installing the AJAX extensions, the issue remained unresolved. A quick look in the machine's GAC showed that it had version 1.0.61025.0, which is the latest version. Inspection of my development machine's GAC showed both 1.0.61025.0 and 2.0.0.0 installed.

At this point I was puzzled how my machine had an unofficial version of AJAX extensions, and how my website was referencing it. Next I looked at the web.config of my site to see if I could just change the referenced version to 1.0. However, inspection of the web.config reveled:


<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"> 
</add>

As it turned out, I was already explicitly referencing the correct version. As you can imagine, at this point I was extremely puzzled. I even attempted a few cleans and rebuilds of the site, but to no avail. After some time, I realized that the 2.0.0.0 version of System.Web.Extensions was something that shipped with .NET 3.5, and despite my explicit reference to 1.0.61025.0 Visual Studio 2005 was linking against this other version. The only way to resolve this issue was to uninstall Visual Studio codenamed Orcas and .NET 3.5.

I do not know if the fault lies with Visual Studio 2005, or something with the .NET 3.5 framework. But, whichever component is at fault, I hope that this issue is resolved before the final version of .NET 3.5 ships.

Tail Recursion Revisited

Jason Whitehorn — Thu, 07 Jun 2007 03:05:11 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/06/06/Tail-Recursion-Revisited.aspx

A year ago I blogged about Tail Recursion in C# on .NET 2.0. With the public beta of .NET 3.5 now available, I decided to retry my little experiment.

For the experiment I used Beta 1 of .NET 3.5 (version 3.5.20404), which you can get from here. Using the supplied compiler, I compiled the following C# code:

public class TailTest{
	public static void Main(){
		TailTest f = new TailTest();
		f.DoTail(0);
	}
	public void DoTail(int n){
		int v = n + 1;
		System.Console.WriteLine(v);
		DoTail(v);
	}
}

Just running the produced EXE is enough to determine that even with the newest version of Microsoft's compiler, the program has not been optimized for tail recursion. Just to confirm this findings, I went ahead and decompiled the EXE to IL anyway.

.class public auto ansi beforefieldinit TailTest
    extends [mscorlib]System.Object
{
    .method public hidebysig specialname rtspecialname instance void .ctor() cil managed
    {
        .maxstack 8
        L_0000: ldarg.0 
        L_0001: call instance void [mscorlib]System.Object::.ctor()
        L_0006: ret 
    }

    .method public hidebysig instance void DoTail(int32 n) cil managed
    {
        .maxstack 2
        .locals init (
            [0] int32 num)
        L_0000: nop 
        L_0001: ldarg.1 
        L_0002: ldc.i4.1 
        L_0003: add 
        L_0004: stloc.0 
        L_0005: ldloc.0 
        L_0006: call void [mscorlib]System.Console::WriteLine(int32)
        L_000b: nop 
        L_000c: ldarg.0 
        L_000d: ldloc.0 
        L_000e: call instance void TailTest::DoTail(int32)
        L_0013: nop 
        L_0014: ret 
    }

    .method public hidebysig static void Main() cil managed
    {
        .entrypoint
        .maxstack 2
        .locals init (
            [0] class TailTest test)
        L_0000: nop 
        L_0001: newobj instance void TailTest::.ctor()
        L_0006: stloc.0 
        L_0007: ldloc.0 
        L_0008: ldc.i4.0 
        L_0009: callvirt instance void TailTest::DoTail(int32)
        L_000e: nop 
        L_000f: ret 
    }

}

From my previous discussion, we can see that the resulting IL lacks the "tail.". With all the innovation in C# for the upcoming release of .NET 3.5, I was hoping that the outcome from my experiment would have been different.

Throwing More Than Just Exceptions

Jason Whitehorn — Wed, 24 Jan 2007 07:05:00 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/01/24/Throwing-More-Than-Just-Exceptions.aspx

It is a little known fact (and probably for the best) that the CLR can throw and catch more than just System.Exception and its children. In fact, the CLR can use any type as if it was an Exception.

.assembly ExceptionTestAssembly {}

.class public ExceptionTest { //custom class
   //note that ExceptionTest does NOT extend System.Exception
  .method public void .ctor(){
    .maxstack 1
    ret
  }

  .method static void main() il managed{
      .entrypoint //program entry point...
      .try {
        newobj     instance void ExceptionTest::.ctor()
        throw   //throw a random object

      } catch ExceptionTest { //catch the random object
        pop
        ldstr "Random object caught"
        call void [mscorlib]System.Console::WriteLine(string)
        leave.s    OUT

      }
      OUT: ret
  }
}

In the above code example I have defined my own class (which does not extend System.Exception), and both throw and catch it. This code sample was written in IL because every other .NET language does not allow throwing random objects.

What is the point of this, you ask? Nothing more than to provide insight into the CLR. I would not, and am glad that C# does not allow you too, actual do this. While possible, it violates the CTS contract that good .NET languages abide by.

Cookie Renaming in ASP.NET

Jason Whitehorn — Sat, 20 Jan 2007 07:48:00 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2007/01/21/Cookie-Renaming-In-ASPNET.aspx

In ASP.NET you can seamlessly rename cookies on the fly with the help the PreSendRequestHeaders and BeginRequest events of the HttpApplication class.

Both events call EventArgs delegates, with the sender object as a HttpApplication instance.

     /// 
     /// Called when a cookie is about to be sent to the browser.
     /// 

     private void CookieOut(object sender, EventArgs e) {
         HttpApplication app = (HttpApplication)sender;
         HttpCookie cookie = app.Response.Cookies["ASP.NET_SessionId"];
         if (cookie != null) {
             app.Response.Cookies.Remove("ASP.NET_SessionId");
             cookie.Name = "fooBar";
             app.Response.Cookies.Add(cookie);
         }
     }

The above method will find a cookie of a specific name, and rename it to something else. In this example, everything in ASP.NET that occurs before the HttpApplication.PreSendRequestHeaders is called will refer to the cookie as "ASP.NET_SessionId". By the time the cookie reaches the browser, it is called "fooBar".

This can be useful when you cannot otherwise control the name of a cookie. The above example is only half of the solution. The cookie will need to be renamed again when it returns from the browser.

      ///        /// Called when a cookie is coming into the application.       /// 
       private void CookieIn(object sender, EventArgs e) {           HttpApplication app = (HttpApplication)sender;           HttpCookie cookie = app.Request.Cookies["fooBar"];           if (cookie != null) {               app.Request.Cookies.Remove("fooBar");               cookie.Name = "ASP.NET_SessionId";               app.Request.Cookies.Add(cookie);           }       }

With the help of the HttpAplication.BeginRequest event, the above method will rename the otherwise named "fooBar" cookie to its original name. All events occurring after BeginRequest will refer to the cookie as "ASP.NET_SessionId", and will be unaware of what has just occurred.

The only caveat to the above solution, is that each cookie practically has two names. In the above example, user code will never be able to create a cookie named "fooBar", as it is already used by the cookie named "ASP.NET_SessionId".

Google Custom Search Engine

Jason Whitehorn — Fri, 27 Oct 2006 06:39:00 GMT

UPDATE (12/17/2007): My blog has moved. This post is now located at: http://jason.whitehorn.ws/2006/10/28/Google-Custom-Search-Engine.aspx

Today I just discovered Google's custom search engine program, and quickly setup a .NET Search Engine. I have restricted the list of sites to those that cater to .NET topics including non other than geekswithblogs, in addition to others.

Let me know what you think.