Add CLSCompliant Attribute
From Microsoft:
If your component conforms to the Common Language Specification, it is guaranteed to be CLS-compliant and can be accessed from code in assemblies written in any programming language that supports the CLS. You can determine whether your component conforms to the Common Language Specification at compile time by applying the CLSCompliantAttribute attribute to your source code.
The attribute used to be part of the project. It got removed with be53259f188e39c0965dfe8d36448ddbd706403b.
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.
Codecov Report
Merging #618 (e0d70d8) into master (ff64d0a) will decrease coverage by
0.01%. The diff coverage isn/a.
@@ Coverage Diff @@
## master #618 +/- ##
==========================================
- Coverage 73.84% 73.82% -0.02%
==========================================
Files 68 68
Lines 8353 8353
==========================================
- Hits 6168 6167 -1
- Misses 2185 2186 +1
| Impacted Files | Coverage Δ | |
|---|---|---|
| ...Code.SharpZipLib/Zip/Compression/DeflaterEngine.cs | 85.66% <0.00%> (-0.38%) |
:arrow_down: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update ff64d0a...e0d70d8. Read the comment docs.
I think adding it back to the assembly would be fine, as I don't think there are any non-CLS features being exposed, but what is this trying to solve?
Beeing CLS-compliant allows apps written in other languages (F# or VB) to consume the assembly. By adding the attribute, the assembly is guaranteed to be CLS-compliant.
Is there any chance this will be included in the v1.4 version?
Yeah, sorry. What is it you are trying to solve with this? I know what the attribute does, but it's not needed for VB and F# usage afaik. Do you have a specific problem?
We do have a specific problem: We use SharpZipLib in one of our legacy libraries. Unfortunately, it exposes a few classes of SharpZipLib through its public interface. Our library and its consumers are all CLS-compliant. SharpZipLib was compliant too, until the update from 0.86.0 to 1.3.1. Since then, every consumer of the legacy library gets compiler warnings for the exposed, non-compliant classes. Surely, we could solve our problem by changing the public interface and hiding the non-compliant classes behind a new level of abstraction. But these changes come with risks, whereas reintroducing the attribute is a low-risk operation.
Okay, this should be fine then. Could you fix the merge conflict? I cannot do it through Github since it will directly commit to master.
using System;
using System.Runtime.CompilerServices;
[assembly: CLSCompliant(true)]
[assembly: InternalsVisibleTo("ICSharpCode.SharpZipLib.Tests, PublicKey=0024000004800000940000000602000000240000525341310004000001000100b9a14ea8fc9d7599e0e82a1292a23103f0210e2f928a0f466963af23fffadba59dcc8c9e26ecd114d7c0b4179e4bc93b1656b7ee2d4a67dd7c1992653e0d9cc534f7914b6f583b022e0a7aa8a430f407932f9a6806f0fc64d61e78d5ae01aa8f8233196719d44da2c50a2d1cfa3f7abb7487b3567a4f0456aa6667154c6749b1")]
Thank you, the merge conflict is resolved.
Before accepting this pull request, have a look at the interface ITaggedData in ZipExtraData.cs.
The interface is not CLS-compliant, it declares a property of type ushort.
There will be compiler warnings because of this.
How would you like to proceed?