I have a Library Projects that gets used in a variety of other Programs and I want to prevent old versions of the Library to run. Is it possible to include a code snippet that gets called every time the dll is being loaded?
Or do you have any other idea how to prevent older versions from being called in programs?
To be more precise I want to prevent future old versions from running, older versions that are being used right now can not be affected.
You can define that in the config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0" />
</dependentAssembly>
That way, whenever you have an assembly that matches that identity, the framework will use that other version you provided.
Related
I am trying to use SocketIO4Net to create socket.io client in .net. Itseems SocketIO4Net has a dependency of Newtonsoft.Json >= 4.0.8. I also am using PushSharp library which has a Newtonsoft.Json dependency of >= 4.5.10. I got NewtonSoft.Json 4.5.11 when i first installed PushSharp and I thought this version should support SocketIO4Net as well since its a higher version but i get this error whenever am trying to connect to socket.io server.
Could not load file or assembly 'Newtonsoft.Json, Version=4.0.8.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have been banging my head all day with these dependency issues, I would be very grateful if someone can point me in the right direction.
Found solution, try with:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
You can modify assembly-binding configuration and add a redirect. See Redirecting Assembly Versions on MSDN.
Basically you want to add following snippet to your app.config or web.config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<!--
Assembly versions can be redirected in application,
publisher policy, or machine configuration files.
-->
<bindingRedirect oldVersion="1.0.0.0-4.5.11.0" newVersion="4.5.11.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
EDIT
Why do you need to redirect assembly versions? Even though SocketIO4Net supports newer versions of Newtonsoft.Json, it was compiled against a single version (4.0.8 in your case). This version is stored in the DLL and it is used to load DLLs SocketIO4Net depends on.
Note that NuGet dependencies are not the same as DLL/runtime dependencies - NuGet dependency on Newtonsoft.Json >= 4.0.8 only means that you will be allowed to install SocektIO4Net into a project that has a newer version of Newtonsoft.Json, it has nothing to do with runtime settings.
That being said, recent NuGet versions should add assembly-binding-redirects automatically for you if your project has app.config or web.config file.
The above solutions are correct but there is one more point that should not be forgotten: the app.config content was the same as the above solutions.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
But it's a good idea to check if it's up to date. In my case, Newtonsoft.JSON (v.6.0.4) has come to depend on another package.
There are two option;
Update (Newtonsoft.JSON package) last versions.
Update app.config file in the version numbers.
And last advice, if you are working with more than one project, eg.
exe-dll and check both versions if there is Newtonsoft.JSON.
Put in an assembly redirect in your app/web.config;
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" PublicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="1.0.0.0-4.5.11.0" newVersion="4.5.11.0" />
</dependentAssembly>
Please note the versions numbers need to match the version you have installed.
Had this same issue.
Just resolved it.
It happened after NuGet was used to install Ext.NET which has a dependency for Newtonsoft.JSON.
There was already a Newtonsoft.JSON.dll file in /bin (and obviously a reference to it in the web.config file) folder without checking I started the NuGet Package-Install procedure while debugging(so the file probably had a lock).
On the runtime error window it will tell you on the stack trace what part of the manifest it has a problem with, mine was major version so I checked the install package version. and it was 1 major version out. Found the original NuGet file under: "[physical path]/../packages/Newtonsoft.Json.[version]/lib/[.net version]/"
Both Manifest and Library was there so copied it into /bin folder, updated the root web.config assembly information and it worked.
Code samples:
Before
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
After
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
Hope this helps
In my case, I removed the package with NuGet and installed a fresh one. Then, remove the reference from References and add again manually. Works like charm. Hope resolve for you.
I was working on an old project recently. I needed to update our Newtonsoft.Json.dll, since I had to utilize a "new" API which required a newer version, but I still had other DLLs that required the old version.
bindingRedirect you say? Nope. It kept complaining about the manifest mismatch.
Separate codeBase tags? Nope. It kept complaining about the manifest mismatch.
The problem was, apparently, that the old version of Newtonsoft.Json.dll (3.0.0.0) does NOT have a PublicKeyToken, but the "new" version (4.5.7.1) DOES have a PublicKeyToken. Therefore they couldn't share the same dependentAssembly-tag.
This is what I ended up with:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="" culture="neutral"/>
<codeBase version="3.0.0.0" href="bin\Newtonsoft_Old\Newtonsoft.Json.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
<codeBase version="4.5.0.0" href="bin\Newtonsoft.Json.dll" />
</dependentAssembly>
Got the above Error: in Visual Studio 2013
To Fix: In package mamnager Execute: Install-package newtonsoft.json
This will add a new line in packages.config
<package id="Newtonsoft.Json" version="6.0.5" targetFramework="net45" />
Remove the previous line which might point to previous version on packages.config.
Delete the old version's directory on the packagers directory.
Remove the reference of NewtonSoft.Json and readd it pointing to the latest version.
Root webconfig will have the following
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
once everything is done. Close and reopen visual studio.
This should fix it.
I had the same error when installing
PM> install-package durandal.starterkit
I used the above method to fix.
I have fixed this issue easily: I had not copied the xml configuration file from the compilation folder.
I just made sure that the xml configuration file was also included along with my program and everything worked fine!
Just had this happen with TeamCity and I imagine others will soon experience this. This probably applies to most build servers that pull NuGet packages.
All the answers that say to do redirects are correct. However, you need to still define the correct version number. My project was using Newtonsoft.Json 7.0, however, they had just released 8.0 and TeamCity was pulling down 8.0 which was causing issues only on the server and not locally. All my redirects were set to 7.0.
Make sure that the deployed application is actually getting the correct version from NuGet and not just the latest and greatest. Or update your config to point to the newest version.
Other solutions didn't work for me. Although I had different nuget package (Newtonsoft.Json.Schema version=3.0.0.0).
So my project was an ASP .NET project and the Newtonsoft.Json.Schama package was referred in a .NET Standard project. The solution was simply to add the Nuget package to the WEB (or startup) project too, and the problem disappeared.
I've searched a lot but wasn't able to find a solution yet.
We have a lot of programs for our clients with shared libs (dlls) in one directory. But if one lib gets an update we have to recompile all programs which are refering the dll. If we don't, our client get's an error when calling a function from the lib (The located assembly's manifest definition does not match the assembly reference).
We would like to reference a lib as usual and when a lib get's upgraded the programs should just use the new version instead of throwing an error.
Part of the problem is, that the reference is internally fixed with an version-number. My first idea is to remove the version number of the dll before refering. But is that even possible?
I would be grateful for any (other) ideas or suggestions how to bypass the reference problem. This may be a duplicate but I didn't yet find a post with an solution - just post's which describe the reasons.
What about assembly binding redirection - https://msdn.microsoft.com/en-us/library/433ysdt1(v=vs.110).aspx (one more msdn link) ?
You can specify in the config redirection to a new version, so it wont require recompile. But if signature of classes\methods that you are using will be changed - then it will throw an exception anyway.
ASP.Net MVC uses this approach to specify redirection to a new version of MVC:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="4.5.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I am trying to use SocketIO4Net to create socket.io client in .net. Itseems SocketIO4Net has a dependency of Newtonsoft.Json >= 4.0.8. I also am using PushSharp library which has a Newtonsoft.Json dependency of >= 4.5.10. I got NewtonSoft.Json 4.5.11 when i first installed PushSharp and I thought this version should support SocketIO4Net as well since its a higher version but i get this error whenever am trying to connect to socket.io server.
Could not load file or assembly 'Newtonsoft.Json, Version=4.0.8.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I have been banging my head all day with these dependency issues, I would be very grateful if someone can point me in the right direction.
Found solution, try with:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
You can modify assembly-binding configuration and add a redirect. See Redirecting Assembly Versions on MSDN.
Basically you want to add following snippet to your app.config or web.config file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<!--
Assembly versions can be redirected in application,
publisher policy, or machine configuration files.
-->
<bindingRedirect oldVersion="1.0.0.0-4.5.11.0" newVersion="4.5.11.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
EDIT
Why do you need to redirect assembly versions? Even though SocketIO4Net supports newer versions of Newtonsoft.Json, it was compiled against a single version (4.0.8 in your case). This version is stored in the DLL and it is used to load DLLs SocketIO4Net depends on.
Note that NuGet dependencies are not the same as DLL/runtime dependencies - NuGet dependency on Newtonsoft.Json >= 4.0.8 only means that you will be allowed to install SocektIO4Net into a project that has a newer version of Newtonsoft.Json, it has nothing to do with runtime settings.
That being said, recent NuGet versions should add assembly-binding-redirects automatically for you if your project has app.config or web.config file.
The above solutions are correct but there is one more point that should not be forgotten: the app.config content was the same as the above solutions.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
But it's a good idea to check if it's up to date. In my case, Newtonsoft.JSON (v.6.0.4) has come to depend on another package.
There are two option;
Update (Newtonsoft.JSON package) last versions.
Update app.config file in the version numbers.
And last advice, if you are working with more than one project, eg.
exe-dll and check both versions if there is Newtonsoft.JSON.
Put in an assembly redirect in your app/web.config;
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" PublicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="1.0.0.0-4.5.11.0" newVersion="4.5.11.0" />
</dependentAssembly>
Please note the versions numbers need to match the version you have installed.
Had this same issue.
Just resolved it.
It happened after NuGet was used to install Ext.NET which has a dependency for Newtonsoft.JSON.
There was already a Newtonsoft.JSON.dll file in /bin (and obviously a reference to it in the web.config file) folder without checking I started the NuGet Package-Install procedure while debugging(so the file probably had a lock).
On the runtime error window it will tell you on the stack trace what part of the manifest it has a problem with, mine was major version so I checked the install package version. and it was 1 major version out. Found the original NuGet file under: "[physical path]/../packages/Newtonsoft.Json.[version]/lib/[.net version]/"
Both Manifest and Library was there so copied it into /bin folder, updated the root web.config assembly information and it worked.
Code samples:
Before
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
After
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
Hope this helps
In my case, I removed the package with NuGet and installed a fresh one. Then, remove the reference from References and add again manually. Works like charm. Hope resolve for you.
I was working on an old project recently. I needed to update our Newtonsoft.Json.dll, since I had to utilize a "new" API which required a newer version, but I still had other DLLs that required the old version.
bindingRedirect you say? Nope. It kept complaining about the manifest mismatch.
Separate codeBase tags? Nope. It kept complaining about the manifest mismatch.
The problem was, apparently, that the old version of Newtonsoft.Json.dll (3.0.0.0) does NOT have a PublicKeyToken, but the "new" version (4.5.7.1) DOES have a PublicKeyToken. Therefore they couldn't share the same dependentAssembly-tag.
This is what I ended up with:
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="" culture="neutral"/>
<codeBase version="3.0.0.0" href="bin\Newtonsoft_Old\Newtonsoft.Json.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral"/>
<codeBase version="4.5.0.0" href="bin\Newtonsoft.Json.dll" />
</dependentAssembly>
Got the above Error: in Visual Studio 2013
To Fix: In package mamnager Execute: Install-package newtonsoft.json
This will add a new line in packages.config
<package id="Newtonsoft.Json" version="6.0.5" targetFramework="net45" />
Remove the previous line which might point to previous version on packages.config.
Delete the old version's directory on the packagers directory.
Remove the reference of NewtonSoft.Json and readd it pointing to the latest version.
Root webconfig will have the following
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
once everything is done. Close and reopen visual studio.
This should fix it.
I had the same error when installing
PM> install-package durandal.starterkit
I used the above method to fix.
I have fixed this issue easily: I had not copied the xml configuration file from the compilation folder.
I just made sure that the xml configuration file was also included along with my program and everything worked fine!
Just had this happen with TeamCity and I imagine others will soon experience this. This probably applies to most build servers that pull NuGet packages.
All the answers that say to do redirects are correct. However, you need to still define the correct version number. My project was using Newtonsoft.Json 7.0, however, they had just released 8.0 and TeamCity was pulling down 8.0 which was causing issues only on the server and not locally. All my redirects were set to 7.0.
Make sure that the deployed application is actually getting the correct version from NuGet and not just the latest and greatest. Or update your config to point to the newest version.
Other solutions didn't work for me. Although I had different nuget package (Newtonsoft.Json.Schema version=3.0.0.0).
So my project was an ASP .NET project and the Newtonsoft.Json.Schama package was referred in a .NET Standard project. The solution was simply to add the Nuget package to the WEB (or startup) project too, and the problem disappeared.
I am trying to downgrade a NServiceBus dependency so instead of using 4.0.0.0 to use 2.5.0.0
I am trying with the following ways, none of which seem to work.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NServiceBus"
publicKeyToken="9fc386479f8a226c" culture="neutral"/>
<bindingRedirect oldVersion="4.0.0.0" newVersion="2.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I also tried with codebase :
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NServiceBus"
publicKeyToken="9fc386479f8a226c"
culture="neutral"/>
<codeBase version="2.5.0.0" href="NServiceBus.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
Still, nada. I went through the msdn documentation and there is no mention of using this capability in a backwards way. Is this possible?
I'm actually using your first statement for some interop DLLs because the clients in our company have a different state regarding office updates. This is the code I use :
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="office" publicKeyToken="71E9BCE111E9429C" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-14.0.0.0" newVersion="11.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
This provides backwards compatibility from version 14 of the DLL to version 11. Could you provide a link to the DLL u are using?
I've downloaded the NServiceBus framework (version 3.3.8) and investigated the DLL with ILSpy. I would suggest you do the same with your DLL. For my DLL it shows me the same public Key token as yours. Are you sure, that you use version 4.0.0.0 and not verision 3.3.0.0. Or you missmatched the public Key tokens perhaps.
According to MSDN: https://msdn.microsoft.com/en-us/library/eftw1fys(v=vs.110).aspx
This value can specify an earlier version than oldVersion.
referring to the newVersion attribute of bindingRedirect. Also in the "Remarks" section:
You can also redirect from a newer version to an older version of the assembly.
Their example is:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="myAssembly"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0"
newVersion="2.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
I did notice it also mentions something about Explicit assembly binding redirection in an application configuration file requires a security permission, maybe that's affecting you as well?
The answers above are good answers but they are missing important part. And if you read comments, some devs no longer believe this is working. In fact, this is working and working both ways, up version or down
Important: culture
In my experiment, it started to work only when I set culture to neutral. (examples above have 'en-us')
<assemblyIdentity name="..... culture="neutral"/>
In my setup I have WinApp that references Lib1 and Lib3. Lib1 references Lib2 and Lib3. Lib2 references Lib3. And when I push the button, a call propagated all the way from WinApp to Lib3 (both, direct and through chain of libs), and text return displayed on screen. Lib3 is strong named.
Run 1 - no culture set [assembly: AssemblyCulture("")], no binding redirect set - WORKS!
Run 2 - Lower version in Lib3, set binding redirect to 'en-us' - FAIL!
Run 3 - Lower version in Lib3, set binding redirect to 'neutral' - WORKS! Works up-version and down-version.
On other runs - playing with setting [assembly: AssemblyCulture("en-us")] - all attempts failed when AssemblyCulture was not empty. In fact, when set this attribute in WinApp, it wouldn't even compile
Error CS7059: Executables cannot be satellite assemblies; culture should always be empty
So, here we go. Since I don't understand all intricacies of role of the AssemblyCulture I only claim that my experiment only proves that under specific conditions version redirect works fine.
If I didn't get you wrong I have done the same thing with stimulsoft report DDLs which I had the latest version installed but I wanted 2010.3 in my application. but not through the config file and redirecting:
I simply removed the reference from the solution explorer and added the old DLL refrence, then I set the copy Local property and recompiled so that the DLL would go with application in a same directory, every thing works fine. also done it with some other dlls as well.
I've noticed this section in my web.config files for a while and I'm now trying to reason out what exactly the purpose is:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
So, the first entry seems to say:
System.Web.Helpers is the name of a dependent assembly with a public
key token of 31bf3856ad364e35. Redirect version 1.0.0.0 through
2.0.0.0 to version 2.0.0.0.
My best guess is that it means any code executing in the context of the ASP.NET run time that depends on an assembly with the specified name which also has a version in the specified range executes as if it were compiled with the specified version with the specified public key.
Does this mean if I have a web project that depends on a class library and that class library has a reference to an older version of the assembly which has a a bindingRedirect, that the code will execute as if it were compiled against the newer version?
Does this mean if I have a web project that depends on a class library
and that class library has a reference to an older version of the
assembly which has a a bindingRedirect, that the code will execute as
if it were compiled against the newer version?
You have it right (I would just say "...the code will execute as
if it were referencing the newer version"), see http://msdn.microsoft.com/en-us/library/7wd6ex19%28v=vs.110%29.aspx
"When you build a .NET Framework application against a specific
version of a strong-named assembly, the application uses that version
of the assembly at run time. However, sometimes you might want the
application to run against a newer version of an assembly."