conda-forge/staged-recipes#13417 (comment)

Copying relevant comments for more info:

When you build a shared library for xxx on Windows, two files are generated: xxx.dll, which contains the code to execute, and xxx.lib which contains the exported symbols, use to link with.
The issue is that if you build a static library for xxx with the default options, you also generate a xxx.lib (not the same content as the previous one, but the same name and same location). If you install both shared and static packages, the latter.lib file overwirtes the former. Therefore, you need to use different names for static and share libraries.
Besides, applications linking with a static library should use the same runtime as that of the static library. It is therefore a common pattern to specify the runtime of the static library in its name.

Personally, I don't think it is a huge problem to change static libraries to have other names, however, could you point us to a sample project that's using different names for static/dynamic libraries? Also, is there a universally adapted pattern for dynamic/static library names?

Maybe @JohanMabille knows more about the name pattern?

There is no single stadard naming convention; one I often see is libname-mt-s-version.lib or libname-mt-s.lib (here the mt part means multi-threaded, opposed to md used for building DLL, s means static linking).

@Jinming-Hu I don't have a problem with this. What do you think.

Fine by me.

BTW, if we do that, how would it change the way customers consume the static library? They have to explicitly import libname-s.lib instead?

I think so, yes.

They have to explicitly import libname-s.lib instead?

Yes

We welcome community contribution on this, the name should be azure-storage-lite-s.lib given the dynamic linking library's name is azure-storage-lite.lib