.NET, Archive, Software Design

The Wonders Of InternalsVisibleTo

Jason / November 8, 2007

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 { ... }
read more

Archive, ASP.NET, Javascript, Visual Studio

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

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="" newVersion="1.0.61025.0"/> </dependentAssembly> </assemblyBinding> </runtime> read more

.NET, Archive, C#, Software Design

Parsing RSS From C#

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
read more

.NET, Archive, ASP.NET, Javascript, Visual Studio

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

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=, 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 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">

read more