I am attempting to build a uno-platform app and, immediately, I get an error
Error CS1929 'ILoggerFactory' does not contain a definition for 'AddConsole'
and the best extension method overload 'ConsoleLoggerExtensions.AddConsole(ILoggingBuilder,
Action<ConsoleLoggerOptions>)' requires a receiver of type 'ILoggingBuilder'
UnoTest.Droid, UnoTest.UWP, UnoTest.Wasm, UnoTest.iOS, UnoTest.macOS
I have package microsoft.extensions.logging.console version 5.0.0 installed, as well as microsoft.extensions.logging.filter version 1.1.2.
And the source code does have using Microsoft.Extensions.Logging;
I have the suspicion that there may be some backwards compatibility issue with the referenced API.
Uno Platform isn't compatible with versions of Microsoft.Extensions.Logging.Console above 1.1.1. The reason is that later versions use threading APIs which currently don't function on WebAssembly (which is single-threaded only).
If possible, downgrade the installed versions of Microsoft.Extensions.Logging.Console and Microsoft.Extensions.Logging.Filter to 1.1.1.
Related
I built a qt c++ application on a Linux system which uses network requests as part of its functionality, and on the system which it was built on it works alright, after I deployed it (using cqtdeployer), and ran the application on a different Linux computer, the GUI opens up and everything, but when it tries to perform HTTP requests it logs the following error to the console:
qt.tlsbackend.ossl: Incompatible version of OpenSSL (built with OpenSSL 1.x, runtime version is >= 3.x)
My question is - can Qt be built with modern OpenSSL versions, or do I have to manually install OpenSSL1.x on the computer which tries to run the program? Maybe I can just provide a bunch of libraries to the deployment folder?
Thanks.
OpenSSL is generally binary incompatible between major versions, especially with version 3, which is a major API change.
Perhaps it will be a good investment of time for you to take this opportunity to learn how to use your Linux distribution's package manager, (rpm/dnf on Fedora-based Linux distributions, and dpkg/apt on Debian-derived distributions) which exists precisely to solve these kinds of problems.
Most major Linux distributions still include an additional compatibility package for code that's built with OpenSSL 1. If you use your Linux distribution's package manager and prepared an appropriate package, the compatibility package would've gotten installed, automatically, by the package manager together with your package. That's what the package manager is for.
It's also a fair chance that the version of Qt is different too, and there's also a high chance of an incompatibility between your code that's compiled for one version of Qt and the different version that's installed on the computer in question, even though it seemingly runs. If you used the package manager it would've figured it out too, and alerted you.
I need to use the NuGet package OPCFoundation.NetStandard.Opc.Ua in a .NET Framework 4.7.x class library.
So far my class library was .NET Framework 4.7.0. It worked OK, although the OPCFoundateion.NetStandard.Opc.Ua package (.NET Standard 2.0) generated a HUGE bunch of shim system DLLs in the bin folder. Not good at all, but it worked.
Because I found all those dozens of shim dll's very annoying I made some research. According to various articles I learned that all those DLLs should go away once I upgrade my class library to version 4.7.2.
Well so I did, but things only got worse.
If you try this:
Create a brand new solution (VS2017, fully updated)
Create a blank 4.7.2 class library
Import the OPCFoundation.NetStandard.Opc.Ua package into the class library
the following happens:
Still 83 system.* (and other) shim packages are being downoaded,
installed and stored in the Packages folder
25 warnings pop up, saying: "The referenced component
'System.xxxx.xxxx' could not be found"
If I ignore those warnings and try to use the package nevertheless, I get runtime exceptions saying that various DLLs are missing.
What is going on? Why doesn't it work with 4.7.2 while it works with 4.7.0?
I urge you to try it out for yourself, it is very, very easy to reproduce.
I use packages.config for NuGet handling, mainly because I cannot get our TeamCity build server build the project if I use packageReferences.
.net 4.7.2 library referencing standard 2.0 NuGetPackage does not work
This is a known issue Issues with .NET Standard 2.0 with .NET Framework & NuGet, those warning messages were added from .net framework 4.7.1 by MS to remind the user to know that this issue exists. That is the reason why it does not work with 4.7.2 while it works with 4.7.
But the warnings are innocuous and merely present in the IDE, but may be annoying.
To resolve those warnings, you can remove those System.* references from your project, since you can not use packageReferences.
See Adding .NET Standard libraries to 4.7.1 lib adds loads of references, some broken for some more info:
Hope this helps.
I’m a C++ application developer on Windows system. I’m developing an application using EGL 1.4 and OpenGL ES 2.0.
In a certain kind of a OpenGL32.DLL version, I found that a PVR error message occurred. The versions of OpenGL32.DLL that cause this problem are 6.3.9600.16384 on Win8.1 and 4.0.1379.1. And the message says :
PVR Message
PVR: VFrame attempted to use one of these functions:
PVR: wglChoosePixelFormatARB
PVR: but they are not present on you machine.
Ignore?
This message appeared when I call eglChooseConfig() or eglGetConfigs() functions in EGL API to get system configs.
I think this problem occurred because OpenGL32.dll versions mentioned above don’t support wglChoosePixelFormatARB() function.
Most of versions that I tested worked well. List of working version is :
5.2.3790.3959
6.1.7600.16385
6.3.9600.16384(1000kb)
10.0.10130.0
And list of not working version is :
4.0.1379.1
5.1.2600.1280
5.1.2600.5512
6.3.9600.16384 (720kb)
To solve this problem, I want to include this dll file in my product for a commercial use. I want to know that distributing a working version of OpenGL32.dll is possible. And can you know me the list of OpenGL32.dll version without this error and license information about OpenGL32.dll?
The issue is not about the opengl32.dll (in fact its inner working hasn't changed since Windows NT-4 some 19 years ago). Your system is simply missing a graphics driver with full OpenGL support:
The graphics drivers that are installed by default on Windows (and Windows Update) have only a very limited, stripped down OpenGL support (in fact they hardly support GPU acceleration). To get proper, full OpenGL support you must download the driver package for your GPU from the GPU vendor's website and install it manually.
Using Windows standard, automatic driver installation and Windows Update will not give you proper OpenGL support.
Background:
I have an existing code that uses functionality provided by Microsoft, to post XML data over HTTP. Specifically, IServerXMLHTTPRequest (included in MSXML3 and up) from msxml4.dll (COM).
The Problem:
In the possible eventuality, were MSXML4.DLL is missing on the client workstation, the described POST operation will simply fail. More information about MSXML versions.
The current code:
#import "msxml4.dll"
using namespace MSXML2;
…
IServerXMLHTTPRequestPtr spIXMLHTTPRequest = NULL;
hr = spIXMLHTTPRequest.CreateInstance(__uuidof(ServerXMLHTTP40));
Alternatives:
Hard code to MSXML6 (instead of MSXML4). Not a good solution as we do not know what MSXML version is installed on the workstation. Also, the code will break again if Microsoft will release the next DLL version.
Dynamically load the latest from the registry:
Find MSXML version from registry and
Dynamically load a function from a DLL
Use the type library instead?
I would be happy to hear additional alternatives
The question:
What is the simplest and most robust way to change my code to be MSXML version agnostic? That is, use IServerXMLHTTPRequest regardless of the MSXML version actually installed on the client machine. If no version of MSXML is installed, prompt the user and exit gracefully.
Need additional information? Just let me know
Thank you!
From MSDN:
MSXML version 3.0 was the last version of MSXML to support version-independent GUIDs and ProgIDs. Starting with version 4.0, MSXML is installed on your computer in side-by-side mode. This means that, for example, installing MSXML 5.0 for Microsoft Office Applications does not replace any previously installed version of the MSXML parser on your computer. This is done to protect the quality of applications that are currently using earlier versions of MSXML. Side-by-side mode also allows you to decide which version of the parser to use in your code.
This means that there is no COM class installed which you can instantiate expecting that most recent installed version will be picked up, or otherwise someone else will decide for you whether to load MSXML 4 or 6 depending on availability or another criteria.
You are expected to use specific version and depend on respective runtime to be available or installed. Or you can switch between MSXML versions in your code as you already discovered.
First some back story:
I dont know what im doing.
Thats a lie, I know a bit about what I'm doing. I'm a web developer so looking at code isn't all gibberish, but trying to use Xcode is a new book for me. Anyway, I designed a game that was compiled in C++ using SFML on Windows, and now we are trying to bring it over to OS X (I am the only one of the group with a Mac).
Using Xcode 4.6.1 and SFML 2.0 I've been trying to get this damn application to build, and so far it's been nothing but headaches. The current state of getting this thing to work is not so bad, it finally builds with no errors but the build stops and this shows up:
dyld: Library not loaded: #executable_path/../Frameworks/freetype.framework/
Versions/A/freetype
Referenced from: /Users/Eric/Library/Developer/Xcode/DerivedData/
Test-haconqzbewevbwgukppsacykkpml/Build/Products/Debug/Test.app/
Contents/Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics
Reason: Incompatible library version: sfml-graphics requires version 17.0.0 or
later, but freetype provides version 16.0.0
I just dont understand this error. I have the most updated version of FreeType. I'm not even sure what that version number is referring to considering FreeType is at 2.4.11. I can't seem to find this error anywhere else either, any ideas?
The version numbers mentioned in the error message refer to the compatibility version of the library. This is a version number that's baked in to a given dynamic library at the time it is built. When another binary is linked against that library, the compatibility version is copied in to the LC_LOAD_DYLIB load command that tells dyld at runtime which dynamic libraries need to be loaded. When a library is loaded by dyld, the compatibility version is checked and if the program's version is greater that the library's version, it is an error.
When you run otool -L freetype.framework/Versions/A/freetype you'll see that it reports its compatibility version as 16.0.0. If you run it on sfml-graphics.framework/Versions/2.0.0/sfml-graphics you'll see that it reports a compatibility version of 17.0.0 for freetype.framework. So you're hitting the error case described above.
The most common cause of an error like this is running your application against an older version of a framework than the version you built it, and any linked frameworks, against. Note that "older" in this sense refers to the compatibility version and not any other version number associated with the framework (e.g., the marketing version).
Without knowing the origin of the two frameworks involved (e.g., if you built them yourself, or where you got the binaries from), it's not completely obvious where you've gone wrong. I will note however that the SFML git repository appears to have a version of freetype.framework with the appropriate compatibility version (17.0.0), so if you're using a binary of sfml-graphics.framework provided by the SFML folks then picking up their FreeType framework may be your solution.