System.SerializableAttribute appears in Autofac.dll

[forX01]

I got conflict with autofac 4.0.0.0 for .net4.5.1 .
why there's a System.SerializableAttribute inside the librairie?

[tillig]

Can you be more specific about the error message you're seeing? For example, if it's a build time error, what's the full error? If it's a runtime error, what's the exception with stack trace?

The attribute we have is a polyfill that allows us to mark exceptions with the [Serializable] attribute whilst still targeting .NET Core.

If you are seeing that attribute in the Autofac assembly you've referenced it's because your NuGet process executed incorrectly and has added a reference to the lib/netstandard1.1/Autofac.dll or lib/uap10.0/Autofac.dll. You will see the polyfill in those. If your project is targeting a full version of the .NET framework (e.g., 4.5.1, 4.6, etc.) then NuGet should add the reference to lib/net451/Autofac.dll which does not contain that attribute.

Bad references can sometimes happen if you already have a NuGet package added to your project and you change your project's target framework after that. Sometimes you have to remove and re-add your packages to ensure the assembly references and bindings are set up correctly. It can also happen if you don't have the latest tooling for Visual Studio and NuGet. Especially within the last year with the .NET Core work and new .NET target framework moniker changes, using old tooling can inadvertently cause issues.

I tried setting up a standard .NET console app targeting .NET 4.5.1 and a dotnet CLI app (project.json) targeting .NET 4.5.1. In both cases I tried using the [Serializable] attribute and was unable to reproduce any issue.

Check your project references and verify things are referenced correctly. Also make sure you're up to date on your VS and NuGet patches. If you are positive that everything's in order, please post a reproduction of the issue somewhere that we can see and figure out.

[forX01]

You maybe right, I will look tomorrow why there's a system.* into autofac librairie.
I try an empty project and there's no system.s*

my problem was:
when I try myself to add serializable, it said that I have a conflict between autofac.system.serializableattribute and the original system.serializableattribute.
your dll contain a version of system.s*

[forX01]

noget create a reference to netstandard1.1 instead of net451. just need to change manually and problem solved.

tank you

[jahmai-ca]

This is broken for Xamarin.Android and Xamarin.iOS projects. SerializableAttribute exists in mscorlib.dll on those platforms and so it conflicts with the polyfill defined in Autofac.dll.

[tillig]

What versions of Xamarin and VS are you using? The walkthrough article specifies VS 2015 with Update 3 and Xamarin 4.1.2.

I'm also curious if this is a bug with Xamarin. .NET Core and other netstandard projects don't reference any mscorlib.

[jahmai-ca]

I'm using Visual Studio 2015 Update 3 and Xamarin 4.2.0. I've added another netstandard project (Reactive 3) successfully, but cannot add Autofac due to the duplicate definition of SerializableAttribute with mscorlib.

The reference to mscorlib is on the project itself, not a package dependency. If I try to remove the reference from my project, it breaks just about everything.

[tillig]

OK, I reopened the issue due to the Xamarin problem and we'll see what we can do.

[jahmai-ca]

Thanks!

[alexmg]

@jahmai Is the Xamarin project referencing Autofac.dll in the netstandard1.1 or net451 lib folder?

[jahmai-ca]

packages\Autofac.4.1.0\lib\netstandard1.1\Autofac.dll

[jahmai-ca]

Just chiming back in to say this is even bad practice even if you have only PCL's. If Autofac defines System.SerializableAttribute and another genius PCL decides to do the same, then suddenly you have a conflict even at the PCL level.

[rockfordlhotka]

Count me among the (hopefully short) list of "PCL genius" types who defined this in CSLA .NET. And of course there are mutual CSLA/Autofac users, so that's an issue: MarimerLLC/csla#407

[tillig]

I'm guessing what this means is we need to wrap all uses of [Serializable] with compiler preprocessor directives. IIRC the whole reason that shim is in there is to allow us to use it while still targeting netstandard.

[jahmai-ca]

@rockfordlhotka Sorry, didn't mean to fire shots, just frustrated at dealing with consumption of this library in Xamarin which invovled setting assembly aliases, doing using extern statements, and then fully qualifying the real System version in order to work around the issue.

I'm not sure what it's meant to achieve. Types names are localised to an assembly, so just defining it in the System namespace is only going to make it compile (and break consumers) and not actually work. Also, there is no SerializableAttribute support in PCL land, so other PCL consumers can't take advantage of it.

If what you want is true [Serializable] support on platforms that do support it, then I think what needs to happen is that you wrap the use of the attribute in preprocessor defines to exclude it from the PCL or refer to an internal version of it (which would be useless but slightly less effort to achieve the same goal), and then bait-and-switch to dll's with it compiled in on platforms that do support it.
(Edit: By compiled in I mean referring to the real System.SerializableAttribute, not a shim)

E.g.

#if !PCL
[Serializable]
#endif
public class MySerializable {}

or

[Serializable]
public class MySerializable {}

#if PCL
namespace System
{
    internal class SerializableAttribute : Attribute {}
}
#endif

[rockfordlhotka]

@jahmai I've been doing this for 20 years, I have a tough skin 😄

In the case of CSLA the Serializable attribute is actually used by the framework - we have our own serializer for platforms where BinaryFormatter/NDCS don't exist (which is most of them now). This includes .NET Core.

I used to require people to use different [Serializable] attributes on a per-platform basis. That was a PITA, since the whole point of CSLA is that you get 100% reuse of your code across all platforms where C# exists, and pushing that nasty detail into 1000's of people's business classes was really unfortunate.

So I consciously chose to do what I did to make people's lives easier when they try to reuse code across all 11 platforms I support. I knew at the time that there was some risk of a conflict occurring like we're seeing here, and chose to accept that risk.

Obviously autofac chose to accept the same risk, so here we sit.

[jahmai-ca]

@rockfordlhotka I can understand your use-case. Really, Microsoft should have created a netstandard nuget package containing this attribute to avoid this pain for everyone.

[alexmg]

I don't mind removing the polyfill and just keeping the Serializable attribute on our DependencyResolutionException when the target is net45. We had the attribute on the exception in the past and had to drop it when migrating to PCL. When it was added back as a polyfill it wasn't clear exactly what targets we would end up with in our NuGet package. Given that we have a specific net45 target hopefully that will cover full .NET Framework scenarios where we can actually be sure the attribute is present. For .NET Standard we might just have to wait and see what the future brings.

[tillig]

I updated Autofac by removing the polyfill. Version 4.1.2-350 is on our MyGet feed for you to try out.

[tillig]

It looks like this will be going out as 4.2.0 when it goes since we've added a new feature as well as just bug fixes.

[tillig]

Published as 4.2.0 to NuGet.

[dkehring]

As I commented on Rocky's CSLA.NET repo here, I don't necessarily see this as bad practice to have incorporated a well-known namespace like System in Autofac or CSLA for that matter. I understand the reason behind both inclusions. One cannot guarantee that there won't be namespace collisions somewhere between two libraries. That's why .NET included the ability to alias a namespace. However, this functionality does not exist in .NET Core at the moment, so for me, this inability to alias a namespace is the real problem.

[gordon-matt]

This has just become an issue for me too. I just updated some nuget packages and now I get this:

Error CS0433 The type 'SerializableAttribute' exists in both 'Autofac, Version=4.0.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da' and 'System.Runtime.Serialization.Formatters, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

Please remove the SerializableAttribute from Autofac or put it under a different namespace.

[tillig]

@gordon-matt if you read the whole issue you'll see this was fixed and released as 4.2.0. Simply upgrade and you'll be set.

[gordon-matt]

@tillig , Thanks for your response. However, version 4.2 does not show up. At least, not for Autofac.Extensions.DependencyInjection (https://www.nuget.org/packages/Autofac.Extensions.DependencyInjection/) if that's what you are referring to? I am using the latest published version for .NET Core : 4.0.0. I noticed there is another Autofac package (https://www.nuget.org/packages/Autofac/), but I assumed that was for regular .NET.. However, reading the description, I can see it does seem it's for .NET Core as well. Is Autofac.Extensions.DependencyInjection now an obsolete package?

[gordon-matt]

OK Nevermind.. I can see Autofac.Extensions.DependencyInjection has the other Autofac package as a dependency... I've been using VS2013 and the old nuget package manager until recently... I didn't realize some package dependencies were "hidden" in the new one.. As such, the dependency "Autofac" does not show up in the "Updates" tab in nuget even though there are new releases. I have just updated and it seems fine. Thanks

[juniormayhe]

I managed to solve this issue by adding Autofac.Extensions.DependencyInjection v4.4.0 and Castle.Core 4.3.1 packages at my Domain.Core project which serve as reference for a netcore 2.0 application. Domain Core has an custom IInterceptor and now it is finally building!

The error was not showing up in this netstandard, but in a second netstandard project which has [Serializable] attributes decorating custom exception classes and no Autofac packages installed on it.

• Domain.Core (netstandard with Autofac + Castle Core)
• Presentation.Messaging (netstandard with no autofac packages)
• Presentation.WebAPI (netcoreapp 2.0, references Domain.Core and Presentation.Messaging)

Now I will have a look of what packages I should add in Presentation.WebAPI Startup to enable that interceptor.