Automapper 3.0 - This type is not supported on this platform IMapperRegistry

Question

I updated my project to use Automapper 3.0.0 and now my TFS build is not succeeding. The error is the following:

"...System.PlatformNotSupportedException: System.PlatformNotSupportedException: This type is not supported on this platform IMapperRegistry."

Is there anyone that can help me resolve this issue. In the mean time, I am going to revert to previous version since that one seems to work fine.

Chainman

Answer 1

We had the same issue on our build server. MsTest seemed to remove DLLs it deemed unnecessary (note : this claim is only an educated guess). To fix it, add an explicit call to something in AutoMapper.Net4.dll. For instance, with the class ListSourceMapper :

var useless = new ListSourceMapper()

Adding this to a project which is shared by all other projects fixed it for us. Where to put this line of code may vary.

Solvent

Thanks for this, I had to do this as well. @JimmyBogard FYI in case this data helps. – Pow

Stupid that you have to do this kind of thing. But annoyingly, it worked for me. Thanks! – Familist

I agree that this is a lame fix, but all my tests started passing again after adding this, so it works. – Insectivore

Answer 2

Make sure you add a reference (or add a NuGet package reference) in your application to both AutoMapper and the AutoMapper.Net4 assembly in your main application. Visual Studio has a problem with copying references that it won't copy references that it doesn't think are being used.

For example, if you have projects: - Core - UI

And Core references AutoMapper, make sure you add a reference in UI as well to BOTH assemblies. NuGet does this automatically, but MSBuild will NOT copy all references from Core to UI. The easiest way to fix this is to simply add the AutoMapper package reference in UI.

Gascony

Yeah, seems to be a lack of reference to AutoMapper.Net4 assembly. My project works fine executing within VS2012 (debugging or not) but when executing standalone not, our script used to copy the app to the executing environment forget to copy the new assembly AutoMapper.Net4.dll to the app folder. – Caryloncaryn

This looks to me like both assemblies should be combined in the AutoMapper build as I would gather alot of people are using AutoMapper in 'service layer' assemblies and not in their web probject which would manifest the problem. Is this possible? I'm not much of a 'reference nazi' but needing to add automapper "unused" in upstream dependencies seems like there could be a better solution. – Cessionary

For me - I had to install-package Automapper to my unit test project and my unit tests worked again. HTH – Whin

@jimmy-bogard MsTest still fails with this method. I had to use the explicit reference in the other answer to make MsTest behave. – Lynnette

With AM 3.1.1 I had still had problems in my unit-tests in both the R# testrunner and MS Test Explorer. Deleting *.sln.DotSettings.user and *.suo fixed it. – Shaky

Answer 3

I had the same issue with some mstest integration tests I created.

I would recommend using the DeploymentItem attribute on your test class instead of a direct reference in code. For example, this is what I have:

[TestClass]
[DeploymentItem("Unity.config")]
[DeploymentItem("EntityFramework.SqlServer.dll")]
**[DeploymentItem("AutoMapper.Net4.dll")]**
public class MyFancyIntegrationTests
{

You also need to add a reference, as mentioned above, using nuget, to automapper in your test project.

To troubleshoot this, view the bin directory of your mstest project. You should see both Automapper.dll and AutoMapper.Net4.dll if you have automapper referenced in the project. Prior to adding the DemploymentItem attribute to your test class, You won't see AutoMapper.Net4.dll in your TestResults[MyLatestTestRun] folder. But add the attribute and you will.

MSTest does not play well with injection...

Bebel

Answer 4

Updating to AutoMapper 3.1.1 fixed this issue for me

Update-Package AutoMapper -Version 3.1.1

Henn

Answer 5

I had the same problem using Team City to run MSTEST and found no resolution.

It turns out that I needed to use the Visual Studio Test Runner.

I found more information in this blog post.

In Team City 8.1 there is a Build Step for VSTest.Console Tests.

This worked for me. I did not need to use the PowerShell script in the blog above.

Kobe