I have VS 2005, 2008 on my dev box.
New project from other developers who only have 2005 installed. When I build it I get error.
Error 1 Indirect reference is being made to assembly
System.Web.Extensions version 3.5.0.0, which contains
'AjaxControlToolkit.CalendarExtender'. This Project references a prior
version of System.Web.Extensions version 1.0.61025.0. To use
'AjaxControlToolkit.CalendarExtender', you must replace the reference
to System.Web.Extensions with version 3.5.0.0 or higher.
When I change the version of Web.Extentions to 3.5 I get another failure
Could not load file or assembly 'AjaxControlToolkit,
Version=1.0.20229.23876, Culture=neutral,
PublicKeyToken=28f01b0e84b6d53e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Should I change the Public key for:
add assembly="System.Web.Extensions, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
to the newer one, or is this the wrong thing to do. the Server does NOT have 3.5 runtime.
TIA
If your server doesn't have the 3.5 runtime and you aren't able to install it, I suppose you must stick with the 1.0.61025.0 version of System.Web.Extensions.
I would guess that the problem you are encountering is because the AjaxControlToolkit dll that you are using was built with the 3.5 runtime. Thus, your project is referring both to the 1.0.6... version directly and to the 3.5 version through the AjaxControlToolkit reference, and getting confused. You might try downloading the toolkit source and building it from scratch, referencing the 1.0.61025.0 version of System.Web.Extensions. Then make sure to reference this toolkit instead of the default one.
http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=11121
Also, you might try making sure that all the references to the System.Web.Extensions DLL version number are consistent, both in your project's references and in the web.config file. Note that if you have a reference selected, you can toggle the "SpecificVersion" property to True in the Properties panel; presumably this makes .NET more picky as to which DLL version it chooses.
Related
In a Xamarin.Forms project I am getting an error on Windows 8.1 and UWP:
Could not load file or assembly 'FSharp.Core, Version=3.259.3.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
The actual version of F# used throughout the solution is 3.7.4.0:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile7</TargetFrameworkProfile>
<TargetProfile>netcore</TargetProfile>
<TargetFSharpCoreVersion>3.7.4.0</TargetFSharpCoreVersion>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
There is an F# PCL project and C# platform-specific projects. The error occurs only when using F# libraries from Nuget in the PCL. These packages tend to use:
<TargetFSharpCoreVersion>3.259.3.1</TargetFSharpCoreVersion>
I have tried the following, but they do not change the error:
Putting an app.config file with a binding redirect to 3.7.4.0 in the F# project and/or the build directory
Installing the FSharp.Core Nuget package into all projects
Very grateful for any help.
Edit: in the original question there was an incompatibility between the profile (111) and the intended TargetFSharpCoreVersion (3.7.4.0) which was causing additional issues.
I'm upgrading a project from the v2.0 framework to the v4.5.1 framework and I'm getting the following error...
Indirect reference is being made to assembly System.Web.Extensions version 4.0.0.0, which contains 'AjaxControlToolkit.MaskedEditExtender'. This Project references a prior version of System.Web.Extensions version 1.0.61025.0. To use 'AjaxControlToolkit.MaskedEditExtender', you must replace the reference to System.Web.Extensions with version 4.0.0.0 or higher.
My question is what do I need to change in my web.config so that my project will compile?
Keith,
In order to resolve this issue you need to change the target framework from 2.0 to 4.0 or later (In your case 4.5.1) in the solution's properties.
Once you have done this rebuild your solution web.config settings should work again.
A few extensions that I'm using are broken under VS2012 because at some point they were updated to work with VS2013, by changing the version of referenced libraries. At runtime an error like this can be produced:
Could not load file or assembly 'Microsoft.VisualStudio.Shell.12.0, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I see various extensions referencing multiple versions of the same library:
<Reference Include="Microsoft.VisualStudio.Shell.Interop" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.8.0, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
<Reference Include="Microsoft.VisualStudio.Shell.Interop.9.0, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
Others release an extension per VS version.
Another option, according to this article, is to dynamically load the correct version.
I'd like to help fix these extensions, but what's the proper way to tackle this issue?
So the Visual Studio reference assemblies break down into a few different categories, which you should handle differently depending upon the category:
Interop assemblies: these are the ones like the Interop.* assemblies you listed in your question. Each interop assembly isn't a newer version of the "same" thing, but rather an assembly that contains all the COM interfaces that were added in that version of Visual Studio. Referencing old versions is fine, just don't reference a newer one than the lowest version of Visual Studio you want to target
Editor assemblies, Roslyn: Anything related to the core text editor (assemblies are Microsoft.VisualStudio.Text.Data, Microsoft.VisualStudio.Text.UI, Microsoft.VisualStudio.Text.UI.Wpf, and Microsoft.VisualStudio.Editor) and Roslyn Visual Studio includes assembly redirects that redirect whatever version you're referencing to the version of VS you're actually running in. Once again, target the lowest version that you intend to support.
Microsoft.VisualStudio.Shell.[version]: this one confuses people a lot. How this particular assembly works is for each version of Visual Studio that ships, a new assembly name (with the version in the assembly) is made. Then, in future versions of the Visual Studio, we ship a newer version of the assembly that you target. So again, make sure you're targeting Microsoft.VisualStudio.Shell.[version] with the lowest version you intend to support.
The tricky problem here is the VSSDK project upgrader likes to upgrade your projects to newer versions. Get used to editing MSBuild files by hand to ensure it doesn't do this, or downgrade what it already did. For the final VSIX you ship to users it's often best to either build with an older version of VS to ensure it's not picking up newer stuff by accident. If you want to only use a newer version, then you'll have to find the VS binaries from the older version you wish to use and check those into your source control system to ensure the older versions are still being picked up. Test your VSIX if you go this route as it's easy to make a mistake and reference something newer by accident.
I wrote an article discussing the various assembly versioning policies used by Visual Studio assemblies.
http://tunnelvisionlabs.github.io/vsbase/docs-master/html/edbfd3ce-43f4-4f3f-a90c-bc22bda19fae.htm
In addition, the VSSDK.* NuGet packages use dependency declarations to help you identify the version(s) of Visual Studio each extension can be used with.
The particular version of Microsoft.VisualStudio.Shell you referenced is a Versioned Assembly (per the previous article) and included in the VSSDK.Shell.12 package, with the following description:
This package provides the Visual Studio "Shell" reference assembly used by Visual Studio 2013 and newer.
To easily target both Visual Studio 2012 and Visual Studio 2013, use NuGet to manage your VS SDK dependencies, and ensure the following conditions hold:
Make sure your assembly does not have a dependency on the VSSDK.IDE.12 NuGet package. This dependency means one or more assemblies referenced by your project only work with Visual Studio 2013 and newer.
Make sure your assembly does not have a dependency on VSSDK.IDE.10Only, VSSDK.IDE.11Only, or VSSDK.IDE.12Only. These indicate that your package references one or more assemblies that only work with a particular version of Visual Studio.
Ideally you would only want to install VSSDK NuGet packages which include both the vs2012 and vs2013 tags.
I am building a Cpp/Clr dll with .NET Framework 2.0. Builds fine. However, when I create an Example program to use the dll, also with 2.0, I get this error:
The primary reference "C:\...\MemBuffDll.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
I have very carefully rebuild the entire solution (not too hard, only two projects in it) and made sure I used only cut and paste of code from one file to another in the re-creation. I as VERY careful to make sure I specified the 2.0 Framework.
When I exclude the Example Solution, everything builds fine. When I reload it, I get the above message. So, I searched in the contents of every file in the entire solution and found the reference in both the .dll and in a file ending with .metagen. The metagen lines of interest are:
ImageRuntimeVersion: v4.0.30319
Assembly MemBuffDll, Version=0.0.*, Culture=Invariant Language (Invariant Country):
hash=SHA1, flags=PublicKey
Assembly mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Assembly mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Assembly System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Why are the two lines with 4.0.0.0 in there? This is supposed to be a 2.0 build.
Really puzzled,
-greenhorn greg
The answer to the question is:
"The C++ IDE does not support multi-targeting"
Because I didn't understand this answer when I'd seen it in other posts, I'm going to try and clarify for the benefit of other poor souls who stumble upon this "feature".
What this means is that my VS 2010 cannot (correctly) target .net 2.0 when I'm doing a C++ project. I had specified .net framework 2.0 for both of my projects in my solution and the settings were accepted. However, the C++ portion (actually C++/CLI) actually built with two references, both the v2.0 that I had specified and v4.0 that is the native(?) for my VS 2010. Note that it did not throw an error or warning and only the .dll and the .metagen files contained this reference.
When the other project in my solution tried to reference the project, I got the error mentioned in my OP. It would not build.
The solution to the problem is twofold:
Install VS 2008 and recreate the problem project under that. Will probably need refactoring. Note that the Express edition worked just fine for this.
Change your targets to .net 4.0. This is what I did because refactoring the dll would be a PITA and the target platform (Windows Embedded 8 Standard) supports .net 4.0
Hope this helps somebody else like me that runs into this.
Setup:
I have an app that is a copy of another app, that worked with EF 4.1. In the new app, I have added a nuget package reference to EF 4.3.1 in a domain project.
All works on my local machine, but on the server throws the following error:
Could not load file or assembly 'EntityFramework, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Clearly, something is still referencing the old entity framework 4.1, but the only dll it finds is the EF 4.3.1 dll.
There are no references to EntityFramework in the web.config.
Question:
How do I find what is still referencing the old dll?
I have removed all EF references from all projects in the solution and added the EF 4.3.1 package to each project, but still no joy.
Notes:
I could try a binding redirect using the dependentAssembly (see accepted answer in this SO question)
However, I can't find what names and tokens to use.
Still, it would be better to get to the route of the problem, rather than just redirecting a binding.
Have you recompiled the application after changing the reference, or just uploaded the new EntityFramework.dll file? It's possible the application's library is still referencing the old version in your production environment. Do a re-compile and re-publish.
EDIT (see comments) : Open all your .csproj files in notepad and look for the Reference tags, double check that the old version doesn't exist in all the projects.