The located assembly's manifest definition does not match the assembly reference

713

I am trying to run some unit tests in a C# Windows Forms application (Visual Studio 2005), and I get the following error:

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.200, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)**

at x.Foo.FooGO()

at x.Foo.Foo2(String groupName_) in Foo.cs:line 123

at x.Foo.UnitTests.FooTests.TestFoo() in FooTests.cs:line 98**

System.IO.FileLoadException: Could not load file or assembly 'Utility, Version=1.2.0.203, Culture=neutral, PublicKeyToken=764d581291d764f7' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I look in my references, and I only have a reference to Utility version 1.2.0.203 (the other one is old).

Any suggestions on how I figure out what is trying to reference this old version of this DLL file?

Besides, I don't think I even have this old assembly on my hard drive. Is there any tool to search for this old versioned assembly?

c#
reference
compiler-errors
dependencies
version
asked on Stack Overflow Oct 18, 2008 by leora • edited Apr 1, 2017 by Peter Mortensen

50 Answers

449

The .NET Assembly loader is unable to find 1.2.0.203, but did find a 1.2.0.200. This assembly does not match what was requested and therefore you get this error. In simple words, it can't find the assembly that was referenced. Make sure it can find the right assembly by putting it in the GAC or in the application path. Also see http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.

answered on Stack Overflow Oct 18, 2008 by Lars Truijens • edited Sep 9, 2013 by Luke Girvin
90

You can do a couple of things to troubleshoot this issue. First, use Windows file search to search your hard drive for your assembly (.dll). Once you have a list of results, do View->Choose Details... and then check "File Version". This will display the version number in the list of results, so you can see where the old version might be coming from.

Also, like Lars said, check your GAC to see what version is listed there. This Microsoft article states that assemblies found in the GAC are not copied locally during a build, so you might need to remove the old version before doing a rebuild all. (See my answer to this question for notes on creating a batch file to do this for you)

If you still can't figure out where the old version is coming from, you can use the fuslogvw.exe application that ships with Visual Studio to get more information about the binding failures. Microsoft has information about this tool here. Note that you'll have to enable logging by setting the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog registry key to 1.

answered on Stack Overflow Oct 20, 2008 by Seth Petry-Johnson • edited May 23, 2017 by Community
58

I just ran into this problem myself, and I found that the issue was something different than what the others have run into.

I had two DLLs that my main project was referencing: CompanyClasses.dll and CompanyControls.dll. I was getting a run-time error saying:

Could not load file or assembly 'CompanyClasses, Version=1.4.1.0, Culture=neutral, PublicKeyToken=045746ba8544160c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

Trouble was, I didn't have any CompanyClasses.dll files on my system with a version number of 1.4.1. None in the GAC, none in the app folders...none anywhere. I searched my entire hard drive. All the CompanyClasses.dll files I had were 1.4.2.

The real problem, I found, was that CompanyControls.dll referenced version 1.4.1 of CompanyClasses.dll. I just recompiled CompanyControls.dll (after having it reference CompanyClasses.dll 1.4.2) and this error went away for me.

answered on Stack Overflow Nov 17, 2009 by Nathan Bedford
51

The following redirects any assembly version to version 3.1.0.0. We have a script that will always update this reference in the App.config so we never have to deal with this issue again.

Through reflection you can get the assembly publicKeyToken and generate this block from the .dll file itself.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Note that without an XML namespace attribute (xmlns) this will not work.

answered on Stack Overflow Nov 2, 2012 by Yaniv.H • edited Dec 3, 2017 by Peter Mortensen
42

If you are using Visual Studio, try "clean solution" and then rebuild your project.

answered on Stack Overflow Jul 13, 2010 by Tad
33

The other answers wouldn't work for me. If you don't care about the version and you just want your app to run then right click on the reference and set 'specific version' to false...This worked for me. enter image description here

answered on Stack Overflow Jun 28, 2013 by RayLoveless • edited Feb 27, 2019 by RayLoveless
21

I just ran across this issue and the problem was I had an old copy of the .dll in my application debug directory. You might want to also check there (instead of the GAC) to see if you see it.

answered on Stack Overflow Sep 3, 2009 by Neal Tibrewala
20

I added a NuGet package, only to realize a black-box portion of my application was referencing an older version of the library.

I removed the package and referenced the older version's static DLL file, but the web.config file was never updated from:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

to what it should have reverted to when I uninstalled the package:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
answered on Stack Overflow Mar 5, 2014 by frattaro • edited Apr 1, 2017 by Peter Mortensen
16

In my case, this error occurred while running an ASP.NET application. The solution was to:

  1. Delete the obj and bin folders in the project folder

Clean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.

answered on Stack Overflow Oct 9, 2016 by Levi Fuller
16

I am going to blow everyone's mind right now . . .

Delete all the <assemblyBinding> references from your .config file, and then run this command from the NuGet Package Manager console:

Get-Project -All | Add-BindingRedirect
answered on Stack Overflow Jan 24, 2019 by codeMonkey • edited Jan 28, 2019 by codeMonkey
14

In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.

answered on Stack Overflow Sep 15, 2010 by Glade Mellor
8

For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.

The annoying part is that the error message gave no indication to what reference was causing the problems.

answered on Stack Overflow Nov 23, 2009 by Sire
5

This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.

You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.

answered on Stack Overflow Jul 16, 2010 by Guy Starbuck
5

Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.

End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.

Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.

answered on Stack Overflow Aug 8, 2010 by Bijimon • edited Sep 16, 2013 by Contango
4

I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.

Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.

answered on Stack Overflow Mar 13, 2012 by Mike Murphy
4

My issue was copying source code to a new machine without pulling over any of the referenced assemblies.

Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.

answered on Stack Overflow Apr 27, 2012 by AEON Blue Software
4

My app.config contains a

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.

answered on Stack Overflow Oct 1, 2012 by Thomas • edited Dec 3, 2017 by Peter Mortensen
4

I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.

To fix it I did a Update-Package and cleaned the solution for a full rebuild.

That worked for me and is kind of a lazy way, but time is money:-P

answered on Stack Overflow Jun 28, 2013 by Ben Pretorius • edited Nov 26, 2017 by Peter Mortensen
4

I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.

Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.

answered on Stack Overflow Jul 16, 2015 by cederlof • edited Dec 3, 2017 by Peter Mortensen
3

I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.

The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.

answered on Stack Overflow Jun 1, 2012 by Ladislav Mrnka
3

To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.

answered on Stack Overflow Mar 4, 2013 by uli78
3

Just deleting contents of your project's bin folder and rebuild the solution solved my problem.

answered on Stack Overflow Aug 10, 2017 by dhiraj1mumbai
2

clean and rebuild the solution might not replace all the dll's from the output directory.

what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"

and then try build your silution again.

incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.

hope this will work for you.

answered on Stack Overflow Dec 3, 2017 by Ganesh Londhe
1

Manually deleting the old assembly from folder location and then adding the reference to new assemblies might help.

answered on Stack Overflow Jun 6, 2014 by rjain
1

In my case the problem was between the chair and the keyboard :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Two or more different assemblies wanted to use a different version of the DotNetOpenAuth library, and that would not be a problem. Furthermore, on my local computer a web.config was automatically updated by NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Then I realized that I had forgot to copy/deploy the new web.config to the production server. So if you have manual way of deploying web.config, check it is updated. If you have completely different web.config for production server, you have to merge these dependentAssembly section in sync after using NuGet.

answered on Stack Overflow Dec 7, 2014 by Tomas Kubes • edited Dec 3, 2017 by Peter Mortensen
1

I got the same error... In my case it got resolved as follows:

  • At first when the application was installed then the people here had used Microsoft Enterprise Library 4.1 in the application.
  • In previous week my machine was formatted & after that today when I built that application then it gave me an error that Enterprise Library assembly is missing.
  • Then I installed Microsoft Enterprise Library 5.0 which I got on Google as first search entry.
  • Then when I built the application then it gave me the above error i.e. The located assembly's manifest definition does not match the assembly reference.
  • After much of a search work & analysis, I found that application was referring 4.1.0.0 & the DLL in the bin folder was of the version 5.0.0.0
  • What i did was then I installed the Microsoft Enterprise Library 4.1.
  • Removed the previous reference(5.0) & added the 4.0 reference.
  • Built the application & voila...it worked.
answered on Stack Overflow Apr 29, 2015 by user4846550 • edited Apr 29, 2015 by Arnon Zilca
1

Here's my method of fixing this issue.

  1. From the exception message, get the name of the "problem" library and the "expected" version number.

enter image description here

  1. Find all copies of that .dll in your solution, right-click on them, and check which version of the .dll it is.

enter image description here

Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).

  1. Search for the version number which was shown in the Exception message in all of the .csproj files in your solution. Replace this version number with the actual number from the dll.

So, in this example, I would replace this...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... with this...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Job done !

answered on Stack Overflow Nov 15, 2016 by Mike Gledhill
1

If you ever get an error like "The located assembly's manifest definition does not match the assembly reference" and if you have updated via Project > Manage NuGet Packages and Update tab in VS, the first thing you could do is try installing another version of the package after checking versions from NuGet Gallery page and running the folowing command from Package Manager Console:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Although answer is not directly related to the package in question and it was asked way back, it is kind of generic, still relevant and hope it helps someone.

answered on Stack Overflow Jun 15, 2018 by Jaggan_j • edited Jun 15, 2018 by Jaggan_j
0

I received this error message due to referencing an assembly that had the same name as the assembly I was building.

This compiled but it overwrote the referenced assembly with the current projects assembly - thus causing the error.

To fix it I changed the name of the project, and the assembly properties available through right-clicking on the project and choosing 'Properties'.

answered on Stack Overflow Jul 12, 2011 by dan
0

I had a similar problem when attempting to update one DLL file of my web-site.

This error was occurring, when I simply copied this DLL file into bin folder over FTP.

I resolved this problem by:

  1. stopping the web-site;
  2. copying needed DLL file/DLL files;
  3. starting the web-site
answered on Stack Overflow Sep 6, 2012 by magicmanam • edited Dec 3, 2017 by Peter Mortensen
0

I faced the same problem while running my unit testcases.

The error clearly states the problem is: when we try to load assembly, the .NET assembly loader tries to load its referred assemblies based on its manifest data (referred assembly name, public key token, version).

To check manifest data:

  1. Open the Visual Studio command prompt,
  2. Type 'ildasm' and drag the required assembly to the ILDASM window and open MANIFEST view. Sometimes MANIFEST contains one assembly with two versions old version as well as new version(like Utility, Version=1.2.0.200 and Utility, Version=1.2.0.203). In reality, the referred assembly is Utility, Version=1.2.0.203(new version), but since the manifest contains even Utility, Version=1.2.0.200(old version), .NET assembly loader tries to find out this versioned DLL file, fails to find and so throws exception.

To solve this, just drag each of the project dependent assemblies to the ILDASM window separately and check which dependent assembly holds the manifest data with the old assembly version. Just rebuild this dependent assembly and refer it back to your project.

answered on Stack Overflow Mar 11, 2013 by shan • edited Dec 3, 2017 by Peter Mortensen
0

In your AssemblyVersion in AssemblyInfo.cs file, use a fixed version number instead of specifying *. The * will change the version number on each compilation. That was the issue for this exception in my case.

answered on Stack Overflow Jul 30, 2013 by DevXP
0

I ran into this issue while using an internal package repository. I had added the main package to the internal repository, but not the dependencies of the package. Make sure you add all dependencies, dependencies of dependencies, recursive etc to your internal repository as well.

answered on Stack Overflow Jan 24, 2014 by ScubaSteve
0

I had the same issue today which prevented me from performing Add-Migration after I made changes in Entity Framework.

I had two projects in my solution, let's call them "Client" and "Data" - a class library project which held my EF models and context. The Client referenced the Data project.

I had signed both projects, and then later made changes to an EF model. After I removed the signature I were able to add the migrations, and could then signed the project anew.

I hope this can be useful for someone, sparing them of prolonged frustration..

answered on Stack Overflow Aug 1, 2014 by Thomas Fauskanger
0

I had this problem after starting to use InstallShield. Even though the build order showed the installation project to be last it was building out of order.

I corrected this by making every other project dependent upon it - this forced the installation to build last and thereby removed my assembly mismatching. I hope this helps.

answered on Stack Overflow Sep 22, 2014 by Tim • edited Apr 1, 2017 by Peter Mortensen
0

This can also occur if you are using both AssemblyInfo.cs with the AssemblyVersion tags and your .csproj file has with a different value. By either matching the AssemblyInfo or removing the section all together the problem goes away.

answered on Stack Overflow Dec 4, 2015 by netniV
0

OK, one more answer. I previously created my app as 64 bit and changed the output path (Project/Properties/Build/Output/Output Path) accordingly. Recently I changed the app to 32 Bit (x86), creating a new output path. I created a shortcut to where I thought the compiled .exe was going. No matter what I changed about the source, it got the manifest not matching error. After about an hour of frustration, I happened to check the date/time of the .exe file, saw it was old obviously referencing old .dll's. I was compiling the app into the old directory and my shortcut was referencing the newer. Changed the output path to where the .exe should go, ran the shortcut and error is gone. (slaps forehead)

answered on Stack Overflow Jan 18, 2017 by OldDog
0

The question has already an answer, but if the problem has occurred by NuGet package in different versions in the same solution, you can try the following.

Open NuGet Package Manager, as you see my service project version is different than others.

Then update projects that contain an old version of your package.

Enter image description here

answered on Stack Overflow May 11, 2017 by erhan355 • edited Dec 3, 2017 by Peter Mortensen
0

The problem with me was that there were old dll's dployed that were deleted in a new build. To fix it, I just checked the box to remove additional files at destination when publishing. Remove additional files at destination

answered on Stack Overflow Jan 10, 2018 by Bellatorius
0

Had similar issue mentioned at this post "Any suggestions on how I figure out what is trying to reference this old version of this DLL file?"

Needed which assembly still refers old ODATA client 6.15.0 , the ildasm helped to narrow down for me (without base code access, only via deployed pkg at server).

Screen shot below for quick summary.

DeveloperPackge if don't have ildasm.exe https://www.microsoft.com/net/download/visual-studio-sdks

ildasm usage to resolve assembly mismatch issue

answered on Stack Overflow Jun 21, 2018 by Nara
0

This same error was surfacing for me in my Unit Tests project and resulting in some failing tests. I double-checked which version of the assembly I was using in assembly explorer and checked the contents of the runtime/dependentassembly tags and realized a different version of the assembly I had been using was still being referenced there. Because this was the only directive in my tests project app.config I just tried deleting the entire app.config file, rebuilding the solution, and that did the trick! No more reference errors for me :)

answered on Stack Overflow Jan 25, 2019 by Ryan
0

I was getting:

Could not load file or assembly 'XXX-new' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

It was because I changed the name of the assembly from XXX.dll to XXX-new.dll. Reverting name back to the original fixed the error.

answered on Stack Overflow Apr 18, 2019 by mimo
0

check the licenses.licx in properties of project you will find the wrong version there.... it worked for me in active report refrences

answered on Stack Overflow May 22, 2019 by Marzie Keshavarz
0

Happened to me for System.ValueTuple

Unexpected Error Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

Solved it by installing .NET Framework 4.7.2 Runtime on the machine the error occurred on. Simple and no need to add bindingRedirect, modifying GAC or downgrading NuGet packages etc.

https://dotnet.microsoft.com/download/dotnet-framework/net472

answered on Stack Overflow May 29, 2019 by Ogglas
0

No solution worked for me. I tried clean project solution, remove bin, update package, downgrade package and so on... After two hours I loaded default App.config from project with assemblies and there I changed wrong reference version from:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

to:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

After this I cleaned project, build it again and it worked. No warning no problem.

answered on Stack Overflow Aug 22, 2019 by Mi1anovic • edited Aug 25, 2019 by marc_s
0

Please read the "full details" in Visual Studio. In Full details, it told me that one of my project (which was referring to my main project has a different version of Microsoft.IdentityModel.Clients.ActiveDirectory). In my case, my unit test project was calling my project. My unit test project and my project has a different version of Microsoft.IdentityModel.Clients.ActiveDirectory. I am getting run time error when my unit test were executing.

I just updated the version of my unit test project with the same version of main project. It worked for me.

answered on Stack Overflow Aug 25, 2019 by Vikrant
0

I had similar problem but no answer worked for me.

The solution that worked for me was removing publicKeyToken part from project file(YourProject.csproj) manually.

Previously it had been:

<Reference Include="Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

After change it was:

<Reference Include="Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

Be sure that SpecificVersion is False.

answered on Stack Overflow Oct 7, 2019 by Mostafa Vatanpour • edited Oct 12, 2019 by Mostafa Vatanpour
0

Solved my issue like this with brute force.

I realised I hand multiple copies of the DLL all over the solution and two different versions.

Went into the solution in explorer, searched for the offending DLL and deleted all of them. Then added the references to the DLL back using the one version of the DLL.

answered on Stack Overflow Nov 16, 2019 by Dale Kilian
-4

Try adding whatever's missing to the global assembly cache.

answered on Stack Overflow Jul 1, 2010 by nikonica
-4

Right click the reference in VS set "Specific Version" property to True.

answered on Stack Overflow Sep 1, 2010 by Adam

User contributions licensed under CC BY-SA 3.0