Referenced assembly 'filename' is a localized satellite assembly (why it's not wise to ignore warning al1056)
Usually you should fix all warnings you see when building your code right away and personally I'm a big fan of treating warnings as errors. Here is one more reason:
Marking an assembly with the AssemblyCulture attribute using a non-empty string will make that assembly look like a satellite assembly. Even if it isn't. So, although the metadata says that an assembly is a satellite assembly it can still contain code (although it should only contain resources) and if you actually manage to load the assembly you will be able to call the methods in it. However, loading the assembly can become a problem. Let's say you have a Visual Studio solution containing a class library project with one source file and the following code:
[assembly: System.Reflection.AssemblyCulture("en")]
public static class Foo
{
public static int Add(int i1, int i2)
{
return i1 + i2;
}
}
Compiling this code will result in an assembly that appears to be a satellite assembly according to its metadata. Let's add a second project to the solution, a console application. We then add a project reference to the library to the console application, paste in the following code and rebuild the solution.
class Program
{
static void Main(string[] args)
{
System.Console.WriteLine(Foo.Add(42, 23).ToString());
}
}
It builds fine except for the warning "Referenced assembly 'filename' is a localized satellite assembly" which is warning al1056 of the assembly linker. According to the assembly linker warning and error reference the full explanation for this warning is:
"An assembly created using the AssemblyCultureAttribute attribute was referenced in the creation of the current assembly. The AssemblyCultureAttribute attribute indicates the file is a localized satellite assembly and it is not normal to reference a satellite assembly. You should probably reference the main parent assembly instead. "
In our case we have to remove the AssemblyCulture attribute that shouldn't be there in the first place because when we try to run the console application it will crash with a FileNotFoundException exception stating: "Could not load file or assembly 'assemblyname, Version=0.0.0.0, Culture=en, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." But why? Visual Studio happily ignores the AssemblyCulture attribute and copies the assembly into the bin folder (ConsoleApplication1\bin\Debug\) when building the console application. At runtime the CLR on the other side will try to load what it thinks is a satellite assembly which by definition has to be located in a specific subfolder. You can simply verify that by moving the class library assembly into the correct subfolder (ConsoleApplication1\bin\Debug\en\). After that the application will work as excepted.
This posting is provided "AS IS" with no warranties, and confers no rights.