In my opinion, treating compiler warnings as errors is a best practice. If and only you are absolutely certain that those warnings should not be appearing, then you can suppress them using "In Source Suppression (ISS)", #pragma or the VisualStudio menus. You can see more info here. I never did.
Having this in mind, the "Warning al1056". Marking an assembly with the AssemblyCultureAttribute using a non-empty string will make that assembly look like a satellite assembly. Even if it isn't. Take a look at the following code:
In the AssemblyInfo.cs we said that the AssemblyCulture was "pt" (Portuguese). If you look at the metadata for the generated assembly, it will look like it's a satellite assembly, despite the fact that it's just a class library. Just like any assembly, you can reference it and loaded at runtime. Now, if we create another Visual Studio Project (e.g.: Console App), reference the above assembly and call the "GoToSleep" method, it will successfully build as expected:
However, it will show the "Warning al1056", stating that the "Referenced assembly 'cAfonsoWorker' is a localized satellite assembly". According to the assembly linker warning and error reference:
"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."
When you run your application you will get a "FileNotFoundException" stating that "Could not load file or assembly 'cAfonsoWorker, Version=220.127.116.11, Culture=pt, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified." This happens because Visual Studio happily ignores the AssemblyCultureAttribute and copies the assembly into the bin folder (Debug and Release) when building the console application. However, at runtime the CLR will try to load what it thinks is a satellite assembly which, by definition, has to be located in a specific subfolder. In this case, if we move the linked assembly to the specific culture subfolder (Debug\pt or Release\pt), it will work as expected.
You can read more info here: Dennis Dietrich's Blog