Well its certainly true that we don’t sign all of the DLLs we include - there seems to be some pretty conflicted arguments for and against doing that. However we do sign all EXE files - including the two you have mentioned going down the list.
So I wonder if defender is configured to only accept a set of predetermined certificates, or something like that.
I can try to investigate that in detail this week. It’s odd that it’s now complaining about older versions of .NET 4.0 file signatures. Tried downloading the latest 4.0 but says that’s already installed, same with .NET 4.8. I’m assuming (as my compiling experiences with the windows platform just isn’t up to par like it was in the olden days of UNIX) that Xibo has been complied with 4.0 which is why 4.8 isn’t being used? (that one I also checked if it was the latest version)
Ok, this is weird, for the heck of it I tried installing v4 of the client on one of these failing Windows 11 computers. I got the same HRESULT error 0xD0000003 but with alot more info. And some reference to some User directory named User (doesn’t exist on my system). I know this is going off on a tangent but may be worth looking at. I was hoping this new client would work, then I would just put my efforts into upgrading to v4 instead.
We target 4.7.2, although perhaps in hindsight we should have started targeting 4.8 with v4.
Yeah I did add quite a bit more logging to the error - its the same error we found back in July, but exposed in the form and with a bit more info:
Stack Trace: at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
at System.CodeDom.Compiler.FileIntegrity.MarkAsTrusted(SafeFileHandle safeFileHandle)
at Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch(CompilerParameters options, String[] sources)
at Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch(CompilerParameters options, String[] sources)
at System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource(CompilerParameters options, String[] sources)
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.GetSerializersFromCache(XmlMapping[] mappings, Type type)
at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Type type)
at System.Web.Services.Protocols.SoapClientType..ctor(Type type)
at System.Web.Services.Protocols.SoapHttpClientProtocol..ctor()
at XiboClient.xmds.xmds..ctor()
at XiboClient.OptionsForm..ctor()
at XiboClient.App.OnStartup(StartupEventArgs e)
So that is this constructor: xibo-dotnetclient/Logic/RequiredFiles.cs at develop · xibosignage/xibo-dotnetclient · GitHub which is making a “web reference” we use to connect to XMDS here: xibo-dotnetclient/Web References/xmds/Reference.cs at develop · xibosignage/xibo-dotnetclient · GitHub.
The web reference is built automatically by visual studio which is why I think you’re seeing C:\User references.
I’m really not sure why that is being blocked!
Gave up, re-installing Windows 10 LTSC 2019, at least the EOL on this version is 2029.
I completely understand - we will carry on working on it and hopefully find some solution.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.