Could not load file or assembly 'AjaxControlToolkit' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded
It's obvious, that you use pre-4.0 .NET Framework. Check minimum system requirements.
Related
What is the right way to construct a NuGet package for a mixed-mode C++/CLI library?
I have 32-bit and 64-bit builds of the dll, and an ASP.NET Core app (targeting full .NET framework only) using it that will be built for both platforms. The app's solution platform is "AnyCPU".
I have tried using the /runtimes/ folders, but then Visual Studio can't find the managed code to compile against.
Currently I have 2 packages, like "MyLibrary" and "MyLibrary64", with the dll in the /lib/ folder and conditional PackageReference in my csproj, but this doesn't feel right. Additionally, when I compile in VS, I get:
warning MSB3270: There was a mismatch between the processor architecture of the project
being built "MSIL" and the processor architecture of the reference "MyLibrary.dll", "x86".
This mismatch may cause runtime failures. Please consider changing the targeted processor
architecture of your project through the Configuration Manager so as to align the
processor architectures between your project and references, or take a dependency on
references with a processor architecture that matches the targeted processor architecture
of your project.
This questions is similar, but has no answers:
Create NuGet package for C++/CLI (mixed) assembly
Update/Clarification:
the app can run either hosted in IIS (64-bit) or as a standalone self-hosted installed application (32-bit), so both are unfortunately necessary.
As Hans already pointed out, the platform of the C++/CLI project must match the mode in which the managed code runs. Hence, an assembly set to AnyCPU that references a (mixed-mode) assembly set to x86 may always fail to load if it is loaded in a 64 bit process.
There are three ways I know of to fix this issue:
First, live with the warning and make sure that the process in which the assemblies are loaded is always a 32-bit process. I wouldn't recommend this.
Second, switch your application to x86 which guarantees that it always runs in a 32-bit process. This is the easiest and cleanest way, but it pins you to 32 bit.
Third, make a NuGet package that contains both, 32- and 64-bit builds of your mixed assembly together with an automatic loader switch. To this end, you need to make sure that the mixed assembly is not found (i.e. by renaming it in the NuGet package) and that there is a AnyCPU assembly that registers AppDomain.AssemblyResolve with an event handler that loads the 32- or 64-bit version of your mixed assembly, depending on the current process.
The third approach allows to provide a NuGet package with mixed-mode assemblies that can be referenced from AnyCPU assemblies. Note, however, that AppDomain.AssemblyResolve is a global concept and may interfere with other components in your application, which may lead to non-trivial bugs.
I get error installing documentDB nuget package.
Could not install package 'Microsoft.Azure.DocumentDB.Core 1.2.1'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.5,Profile=Profile7', but the package does not contain any assembly references or content files that are compatible with that framework.
Any ideas? thanks in advance.
The Core package actually targets NetStandard 1.6, not .Net Core specifically.
NetStandard is a library that acts as API for different runtimes and it's much more powerfull than PCL because it's platform-agnostic:
This means that the DocumentDb.Core package can run on .Net Core 1.0, .Net Framework, Xamarin and UWP.
If you are creating a PCL, I would recommend you to create a NetStandard library instead.
It will let your library support a much wider universe of platforms and the great thing is that, if a new platform comes along that supports NetStandard 1.6 (for example), your library will work without needing to recompile or republish it.
This error message tells us that this assembly Microsoft.Azure.DocumentDB.Core is not supported on portable library. From this assembly nuget site, we know that This client library enables client applications targeting .NET Core to connect to the Azure DocumentDB service. If you want to use Azure DocumentDB library, please try to see if this assembly works Install-Package Microsoft.Azure.DocumentDB
I am using Autofac in a project that is being obfuscated using Dotfuscator. the dotfuscator fails saying it cannot find mscorlib version 2.0.5.0
Is there a way to tell Dotfuscator how to obfuscate Autofac with portable Dll?
Is Autofac team planning releasing autofac with reference to .NET 4.0?
Any other suggestions?
I don't know what version of Dotfuscator you're using, but it does seem that at least as of 4.9.9000 they "know" about Portable Class Libraries. If you aren't at that version and can't upgrade, you might need to contact Dotfuscator support to find out a solution. (Another question of similar nature also pointed to updating Dotfuscator as the answer.)
A similar sort of issue occurs with FxCop analysis and SecAnnotate. To get around those issues with those tools, you need to tell them to ignore version information on certain assemblies (like System.Core and mscorlib). You may need to use an option like that on Dotfuscator if such a thing exists.
PCL can also cause challenges on machines that don't have all the latest .NET patches. Make sure you're patched up.
There is no plan to release an Autofac tailored just to .NET 4.x Autofac is a Portable Class Library so it can support multiple platforms without conditional compilation, making for easier testing and development. It switched away from platform-specific builds as of 3.0 and there's no plan to go back.
If upgrading Dotfuscator and patching your machine doesn't fix the issue, your best bet is to find the Dotfuscator mechanism for ignoring assembly version.
I am using VS2010 with SP1 (also have VS2012 installed on the same machine). Moles 1.0
The project is using .NET 4
I added moles assembly to system.dll and get the following error on compile
Error 46 The type or namespace name 'IReadOnlyList' does not exist in the namespace 'System.Collections.Generic' (are you missing an assembly reference?) [C:\Test\obj\Debug\Moles\s\m.g.csproj] C:\Test\m.g.cs Test
IReadOnlyList .NET 4.5 as far as I know.
Anyone else got this issue?
Updated Solution
I was able to get Pex to run in VS 2010 with .Net Framework 4.5 installed. Maybe others have explained that this is the solution but my issue (being new to Moles and Pex) is that many of the explanations were vague. Thanks to the author of these posts because they got me headed in the right direction:
http://feherzsolt.wordpress.com/2013/02/13/moles-and-net-4-5/
http://www.daedtech.com/using-moles-with-the-system-assembly
So the solution is to create a new .moles file (System.moles) in the test project at the same level that Pex created the yourAssemblyUnderTest.moles file and add the following to the file.
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System" ReflectionOnly="true" />
</Moles>
You may have to clean (or manually delete the obj folder contents) and rebuild but this solution worked for me. I also noticed that the first build would report build errors, but the errors would go away on subsequent builds.
Alternative Solution
I know this isn't THE solution but it is a (poor) workaround that allows Pex to run...plus this was too long for a comment. If anyone knows how to get PEX to run on a machine with the 4.5 .Net Framework PLEASE respond.
This was my scenario. I have a machine with the .Net Framework 4.5 and I have Visual Studio 2010 and 2012 installed. I installed Pex (en_visual_studio_2010_pex_0.94.51023.0_power_tools_x64_598803.exe) and could run Pex in a VS 2010 project that was targeting .Net Framework 4.0. I could run Pex and it identified issues...but once I promoted issues to Unit Tests the unit test project wouldn't compile because of the following build error
The type or namespace name 'IReadOnlyList' does not exist in the namespace 'System.Collections.Generic' (are you missing an assembly reference?)
After much searching, and reading that Pex or Moles was replacing 4.5 .Net Framework assemblies with 4.0 versions I decided to uninstall 4.5, install 4.0, and give it a try. Running on 4.0 works just fine and I didn't need to define Mole type filters to get it to work. Then I tried tried to upgrade to the 4.5 Framework again...but sadly I end up right back where I started with the IReadOnlyList namespace issue.
I'm building an ASP.net application using Visual Studio Web Developer 2010 Express and have followed the Nerd Dinner tutorial for a large part. The problem is that when I try to build, it is constantly giving me a build error saying:
Error 43 Could not load file or
assembly 'System.Data.Entity,
Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system
cannot find the file specified.
This error is coming from the file "ASPNETCOMPILER" apparently. Some things that I have already checked are:
There is a reference to System.Data.Entity in the project references already.
I have .Net 4.0 installed on the system.
Any ideas on what could be wrong?
Try copying the System.Data.Entity.dll into your bin folder, or target your system to use .NET 2.0, as that should copy it over automatically.
Posting back for community goodness, the first comment in this thread by "DonSleza4e" seemed to solve my problem.