iajtin / ismbios Goto Github PK

I was trying to use this in a UWP app that I am working on. and Windows App Cert kit give this message about iSMBIOS assemblies are built in debug mode. is there something wrong with the build pipeline?

got a system that's on SMBIOS 3.1, the program crashed when trying to get the property for Type0.

at iTin.Core.Helpers.SentinelHelper.IsTrue(Boolean expression, String message)
at iTin.Core.Helpers.SentinelHelper.IsTrue(Boolean expression)
at iTin.Core.Int32Extensions.GetByte(Int32 value, Byte onebyte)
at iTin.Core.Int32Extensions.GetByte(Int32 value, Bytes onebyte)
at iTin.Core.Hardware.Specification.Smbios.SmbiosType000.get_ExtendedBiosRomSizeUnits() in C:\iSMBIOS\src\iTin.Core.Hardware\Specification\SMBIOS\Structures\SmbiosType000 [BIOS Information].cs:line 347
at iTin.Core.Hardware.Specification.Smbios.SmbiosType000.Parse(Hashtable properties) in C:\iSMBIOS\src\iTin.Core.Hardware\Specification\SMBIOS\Structures\SmbiosType000 [BIOS Information].cs:line 550
at iTin.Core.Hardware.Specification.Smbios.SmbiosBaseType.get_Properties() in C:\iSMBIOS\src\iTin.Core.Hardware\Specification\SMBIOS\Structures\SmbiosBaseType.cs:line 84
at iTin.Core.Hardware.Specification.Dmi.DmiClass.get_Properties() in C:\iSMBIOS\src\iTin.Core.Hardware\Specification\DMI\DmiClass.cs:line 48

I checked the function, it seems the logic is throwing exception intentionally?

Hi,

There is a BIOS value named 'IdentificationCode', ref https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-bios. But I cannot see that the iSMBIOS library retrieves this value?

Best,
Stein J. Gran

var structures = DMI.Instance.Structures;
            // type 0
    BiosVersion = GetSmbiosProperty(structures, DmiProperty.Bios.BiosVersion);

private static string GetSmbiosProperty(DmiStructureCollection structure, IPropertyKey key)
    {
        string result = null;
       
        result = structure.GetProperty(key).ToString();
            
    
        return result;
    }

the first time structure.GetProperty was called, it will throw exception....

According to this MSDN document: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

One important aspect of strong naming is that it's viral: a strong named assembly can only reference other strong named assemblies. If your library isn't strong named, then you have excluded developers who are building an application or library that needs strong naming from using it.

The benefits of strong naming are:

The assembly can be referenced and used by other strong-named assemblies.
The assembly can be stored in the Global Assembly Cache (GAC).
The assembly can be loaded side by side with other versions of the assembly. Side-by-side assembly loading is commonly required by applications with plug-in architectures.

non-strong naming assemblies can reference strong naming assemblies, but strong naming assemblies can only reference strong naming assemblies.

to allow most users to be able to use this library, I recommend use a snk file to sign the assembly projects. what needs to be done here is to create a snk file and share across the projects that are being packing into nuget package.

All other popular .net nuget packages are using this approach now.

recently when debugging an issue, I found that nuget 1.1.0 and 1.0.9 are identical.

--> this means the nuget 1.1.0 is actually the same as 1.0.9 in the end.
and I found that none of the libs carries version information, they are all 1.0.0.0
which will make it a bit difficult to track which version is in use when not looking in the source code.

my suggestion would be to create a build pipeline and mark the release versions during build.
any thought? @iAJTin