Is it possible to configure DPI Awareness value using cmake or some script?
Create a manifest file (.manifest is important) with the following content:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:application>
<asmv3:windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>
see https://learn.microsoft.com/en-us/windows/win32/hidpi/setting-the-default-dpi-awareness-for-a-process
Then add it to your binary target in CMake using:
target_sources(your-binary PRIVATE path-to-the-file-above.manifest)
You'll need CMake 3.4 or newer, see https://cmake.org/cmake/help/v3.4/release/3.4.html#other
There is no internal manifest support in CMake, but you can use it, there are couple of hints on this site (e.g. people using manifest e.g. because of UAC etc.).
About DPI, search other topic on SO e.g. here
I found this helpful. Applying manifest using cmake.
https://gist.github.com/bjornblissing/6fc452fe7ec1fdfe3419
Related
I am using macOS 10.15.2 Catalina and am trying to debug a Hello World C++ program in Eclipse.
I have set up gdb debugger by installing it from Homebrew and signing the certificate by following the procedure in the below link.
https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/
The debugger does not get starts.
I have set gdb settings in the Eclipse as mentioned in the below screenshot.
When I debug the project, I am getting error: Configuring GDB Aborting configuring GDB (its screenshot is also provided below).
Which versions of gdb and Eclipse are you using?
I'll try to mention some aspects with which I had problems in the past.
In case you installed gdb with Homebrew, try setting the "GDB debugger" field to the actual path, something like /usr/local/Cellar/gdb/8.3/bin/gdb instead of the link /usr/local/bin/gdb.
Where is your .gdbinit file located? In the tutorial, it is located in the user home folder, so in the Eclipse debug configuration the GDB command file is set to ~/.gdbinit. The value in your screenshot doesn't specify an absolute path, it might be looking for it in the wrong place.
Is your gdb certificate part of the System Keychain (rather than the login Keychain)? During the signing have you passed the entitlements file as argument?
I faced a similar problem, and I had to do two steps to fix it. I'm not sure if they are both needed or not:
Make sure your debug configuration has an absolute path to .gdbinit. You need to have a .gdbinit file in your user folder with the following content:
set startup-with-shell off
My debug configuration in eclipse pointed to this file, but it wasn't reading it until I changed the path to be absolute.
Set up the permissions with extra entitlements like the ones from this guide: https://www.thomasvitale.com/how-to-setup-gdb-and-eclipse-to-debug-c-files-on-macos-sierra/
Create a gdb-entitlement.xml file with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
<key>com.apple.security.cs.debugger</key>
<true/>
<key>com.apple.security.get-task-allow</key>
<true/>
</dict>
</plist>
Then, open your Terminal prompt, go to the directory where you saved the xml file and run:
codesign --entitlements gdb-entitlement.xml -fs gdb-cert $(which gdb)
Where "gdb-cert" is the certificated you created before for code signing.
After those steps and setting the GDB path correctly on Eclipse, debugging worked again.
I am developing a Windows 10 UWP App with a desktop bridge writen in C++
(Compiled with /ZW).
The executable has a dependency to the Visual C++ Runtime.
When I add the dependency
<PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.24123.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
to the application's manifest in a release build all works fine. I install the application side-loaded. (MinVersion is the version of the VCLibs package copied into the "Dependencies" output folder during the build)
When I add the dependency
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug.UWPDesktop" MinVersion="14.0.25022.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
to the application's manifest in a debug build (as documented here: https://blogs.msdn.microsoft.com/vcblog/2016/07/07/using-visual-c-runtime-in-centennial-project/, see "For Debugging"), I cannot install the package with the error "Windows cannot install package ... because this package depends on a framework that could not be found. Provide the framework "Microsoft.VCLibs.140.00.Debug.UWPDesktop" published by ...".
When I skip adding the dependency at all I can install the application, but as expected the desktop bridge process fails to start with the error "vccorlib140.DLL was not found" (or vccorlib140d.DLL in case of a debug build).
However, manually installing the Microsoft.VCLibs.140.00.Debug packages from the build output "Dependencies" folder does not change anything.
When I add the dependency (without the UWPDesktop suffix)
<PackageDependency Name="Microsoft.VCLibs.140.00.Debug" MinVersion="14.0.25022.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
to the application's manifest in a debug build, I can install the application, but it also fails launching with "vccorlib140d.DLL was not found".
How do I get the debug build working?
Of course I can copy the VCLibs-DLLs into the system's System32 directory which works but it would be nice if a debug build also works "out of the box".
I am using a 64-Bit Windows 10 Enterprise version 15063.540.
Regards,
Dominik
In order to test the debug version you will need to install the debug VCLIB appx package manually first. More info can be found here:
https://learn.microsoft.com/en-us/troubleshoot/cpp/c-runtime-packages-desktop-bridge
Currently I have installed MSXML3 and MSXML6 (they also can be found in system32 directory).
When I run windows command line tool MSXSL with help option -?:
I get a message stating that
-u version Use a specific version of MSXML: '2.6', '3.0', '4.0'
Even If I try to use '6.0' - I get an error.
My question is:
Is it possible to use MSXML6 with MSXSL command line tool? If yes, then how?
Which version of sl4j is used in Jetty8. There is no sl4j provided with the Jetty8.1 distribution and several attempts to get a compatible version of sl4j for this has failed. Is there a link from where this compatible sl4j can be downloaded. As of now sl4j in the current setup that I have created sl4j is not used at all. But I want to use this.
Define in jetty-project pom.xml in version 8.0.0.M3 :
<slf4j-version>1.5.11</slf4j-version>
The slf4j version is 1.6.1 as you can see in the POM for version 8.1.7. Use maven and you won't have problems with dependencies.
Traditionally, nunit-console.exe has been included in the repository and on the build server (or any other machine) this EXE was called from some build script.
Now that the NUnit.Runners package is available I wonder how this could be used from a psake build script. It is a solution-level package so it doesn't leave any trace in packages.config and cannot be auto-restored as other project-level packages so I guess one would need to call Install-Package from the psake script, wait for the download and then execute the unit tests? Hopefully this download can be run only once and it will not slow down the build every time it runs. Or will it?
Just ran into this myself. Quite easy to fix as follows:
Get latest version of the Nuget Package Manager extension. I'm on 1.8 at the moment.
Add the Nunit.Runners package to your solution
Copy the element related to the runner from packages.config under your .nuget folder into the packages.config file of your unit test project
From now on, when you build, Nuget will pull down the Nunit.Runners packages if it is not on the machine. I then reference the Nunit runner from the package in my command line build.
I have this working in a little project I did for a TeamCity build light on Github. Packages.config in the unit test project has been modified as discussed above. You can look at the MSBuild file to see how I run tests from the command line. (build.proj, which references some targets and properties contained in the repository's tools\msbuild folder). You will need the latest Nuget Package Manager installed before you try to build in VS.NET or from the command line (clicktobuild.bat).
You should be able to port the idea of how to run Nunit console from the right location into psake quite easily.
I have created an issue with nuget developers, and proposed a fix.
Modify the nuget.targets file with the following changes:
In <PropertyGroup Condition=" '$(OS)' == 'Windows_NT'"> add this element:
<SolutionLevelPackagesConfig>$([System.IO.Path]::Combine($(SolutionDir), ".nuget\packages.config"))</SolutionLevelPackagesConfig>
In <PropertyGroup> add this element:
<RestoreSolutionLevelCommand>$(NuGetCommand) install "$(SolutionLevelPackagesConfig)" -source "$(PackageSources)" $(RequireConsentSwitch) -solutionDir "$(SolutionDir) "</RestoreSolutionLevelCommand>
In <Target Name="RestorePackages" DependsOnTargets="CheckPrerequisites"> add this element before the RestoreCommand for WinNT:
<Exec Command="$(RestoreSolutionLevelCommand)"
LogStandardErrorAsError="true"
Condition="'$(OS)' == 'Windows_NT' And Exists('$(PackagesConfig)') And Exists('$(SolutionLevelPackagesConfig)')" />
This made my msbuild to restore the solution level packages.
This doesn't answer your question, but may be of use to someone facing a similar problem. I ran into the same problem trying to set up a TeamCity build. I worked around this by reverting to an older version of nunit.
NUnit 2.5.10.11092 still has the nunit exe's in the nuget package.