I am trying to upgrade my project. My earlier project had the 32 bit exe and now it is using 64 bit exe.
While upgrading it ts giving following error:
WIN64DUALFOLDERS: Substitution in
'C:\Program Files (x86)\SHAKESPEARE_INC\Othello\'
folder had been blocked by the 1 mask argument (the folder pair's
iSwapAttrib member = 0).
I searched and found this link, but could not find the solution for the problem.
Does anyone know any possible solution for this?
Consider setting the option 64 bit component to true in your component that deploys the exe.
Related
This question already has answers here:
Qt 5.1.1: Application failed to start because platform plugin "windows" is missing
(22 answers)
Closed 3 years ago.
I read a lot of questions and answers related to this issue. However, none of them solved my problem.
I would like to point out that i am using the 5.12.2 of Qt. In addition, i tried to generate .exe files using windeployqt command (Calling it via the cmd).
So, i have two different qt application (2 .exe files). I transfer them in a different windows machine with no Qt installation. One .exe file is running correctly however the other one gives me back the error related to the qt platform plugin "Windows".
I would like also to point out, that the running exe is produced using Qt 5.12.2 (MinGW 7.3.0 64-bit). For the problematic exe, the 5.12.2 (MinGW 7.3.0 32-bit) is used.
Do you know what will be the problem?
PS. i double check that the qwindows.dll is in the platforms folder. I also tried to put this dll in the same folder as the exe file as well as in a sub-folder called plugins (based on some answers find around the web.)
Thanks a lot,
I encountered this issue with PyQt5 5.11.3, Windows 10, Python 3.7.3; I got a similar error message:
qt.qpa.plugin: Could not find the Qt platform plugin "windows" in "
This application failed to start because no Qt platform plugin could
be initialized. Reinstalling the application may fix this problem.
I set the following environment variable and then run the application. This Method had solved my question, I hope it is helpful for you:
name: QT_QPA_PLATFORM_PLUGIN_PATH
value: C:\Users\"your own user
name"\AppData\Local\Programs\Python\Python37\Lib\site-
packages\PyQt5\Qt\plugins\platforms
Are these exe files in the same folder ? If so you need to put the in 2 different folders as they will not use the same DLLs (including qwindows.dll). One exe needs 32-bit DLLs and the other one 64-bit DLLs.
If they are already in 2 seperate folders, make sure you have run the correct windeployqt on each of them.
You need to use the windployqt.exe from your "Qt 5.12.2 (MinGW 7.3.0 64-bit)" installation on the 64-bit exe. And use the windployqt.exe from your "Qt 5.12.2 (MinGW 7.3.0 32-bit)" installation on the 32-bit exe.
Also be sure to copy the Qt5Core.dll using windeployqt and not by doing a manual copy/paste. The reason is that windeployqt patches Qt5Core.dll when copying it so that it searches plugins relatively to your exe.
We are attempting to install a clean build of the newest version of Kentico (12) on Azure, using Kudu, in DEBUG configuration. We traditionally accomplish this by setting SCM_BUILD_ARGS to -p:Configuration=Debug, and all is well. But for some reason in this newer version, the project fails to compile, and I see that this is the command being run:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" "C:\Users\User\Documents\GitHub\Project\CMS\CMSApp.csproj" /nologo /verbosity:m /t:Build /t:pipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="C:\local\Temp\8d6d315018f5ff9";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release;UseSharedCompilation=false /p:SolutionDir="C:\Users\User\Documents\GitHub\Project\.\\" -p:Configuration=Debug
Notice both Configuration=Release and Configuration=Debug. The compilation errors are things like Invalid expression term 'string' on the following line of code:
bool licenseOK = LicenseHelper.CheckLicenseLimitations(FeatureEnum.Ecommerce, out int skuCount, out int maxSKUCount);
This doesn't highlight at all in Visual Studio in Debug or Release mode. I am also able to reproduce locally (as shown in my paths above), and if I change the two configurations to both be the same (regardless of whether I choose Debug or Release), it compiles just fine.
What I know I can do is create my own custom deployment command script file as a work-around, but I guess I don't understand why the above MSBUILD command isn't working in the first place.
Any ideas as to why this would work great for all of my ASP.NET projects prior to this one? One thing I know is that Kentico recently included the Roslyn compiler, which I am unfortunately not that familiar with - could that be part of the issue?
UPDATE #1: It appears all of the compilation errors have to do with code that is only valid in C# 7.0. That could be a clue.
It all came down to the fact that the newer versions of Kentico had code that was only valid in C# 7, and required MSBuild 15 to compile. Here's how I was able to set up Kudu:
Add a file named .deployment in the root of my repo, containing only the contents below. This tells Kudu to use a custom deployment script.
Download the deploy.cmd file from my Azure App Service via FTP to the root of my repo, and update it per https://github.com/projectkudu/kudu/issues/2350#issuecomment-373817740 to use the MSBuild 15 path. Details below.
.deployment file contents
[config]
command = deploy.cmd
deploy.cmd updates
1 - Add -MSBuildPath "%MSBUILD_15_DIR%" to nuget call. Example:
nuget.exe restore "{your .sln file path}" -MSBuildPath "%MSBUILD_15_DIR%"
2 - Replace %MSBUILD_PATH% with %MSBUILD_15_DIR%\MSBuild.exe in both occurrences under step 2. Build to the temporary path
This was all that was needed in order to get the build to complete.
As Keith mentions, it was a compatibility issue with C# 7.0 that Kentico 12 uses. This SO thread mentions that you need to run MSBuild version 15 for C# 7.0 code. I ran a similar debug command for my local Kentico 12 project using MSBuild 15, and it succeeded.
I have a problem with my qt deployment under windows 10. I'm using QtCreator 4.5.1 and Qt 5.11 on Windows 10. I execute my application in release mode. Then I open the command line by running Qt5.11.0 for Desktop(MinGw 5.3.0 32 bit). There I give the path of the release folder (where my exe file exists):
C:\Qt\workspace\build-CanSaveLog2FilterError2DataExploreClass6-Desktop_Qt_5_11_0_MinGW_32bit2-Release\release
After that I type this line:
windeployqt.exe --quick .
and all the necessary .dll files and platforms and plugins will be generated.
When I do this to a simple qt project, it works fine and my exe file can be executed correctly. Whereas when I do the same to my desired project, I can't execute my exe file and I get this error:
This application failed to start because it could not load the Qt platform plugin "windows"
in "", even though it was found. This is usually due to missing dependencies which you can find by setting the env variable QT_DEBUG_PLUGINS to 1.
Available platform plugins are: windows.
Reinstalling the application may fix this problem.
I tried to find dll file by executing it in dependency walker. When I did this, it showed a lot of dll files missing such as "API-MS-WIN-EVENTING-CONTROLLER-L1-1-0.DLL" which doesn't exist even in bin folder of mingw. While if I put the exe file in the bin folder of mingw it works fine.
So I tried to find all the main dll files whose their sub dll files were missing and copied them to the release folder. For example for API-MS-WIN-EVENTING-CONTROLLER-L1-1-0.DLL, I copied Qt5core.DLL to the release folder. But it didn't work again.
I can't understand where the problem is. Could you please help me to resolve it? Since yesterday morning I'm searching and can't find the solution.
My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.
I have a system running 64bit windows 7. I'm doing a project using JMF, which I found works best (or only) with 32 bit jdk. I'm using a 32bit eclipse. I also have a 64bit JDK installed. right now I have set classpath (JAVA_HOME and Path) for the 32bit JDK.
The problem is it becomes hectic to switch between the 64bit and 32 bit JDK(i have to change classpaths everytime). Is there any easier way to do that?
You can have multiple JREs registered with Eclipse, and associate a project or run configuration with a specific JRE. These are different from the JRE you use to run Eclipse in.
Eclipse doesn't need to depend on JAVA_HOME or PATH. You can specify the JVM to be used to run Eclipse in the eclipse.ini file, and specify the path(s) to the target JVM(s) via the Eclipse preferences.
If you have to run both 32 and 64 bit Java from the command line, you should invest some time in writing shell scripts, aliases, etc.
You could write a script (to be executed using ".") that will switch the settings of PATH and JAVA_HOME.
I prefer the approach of writing simple wrapper scripts or aliases to automate the build or run steps for the software you are developing. You can embed local overrides of PATH and JAVA_HOME in these scripts.
I would suggest just keep one JDK installed on your machine.
If you are working with JMF and Eclipse 32 bit then uninstall 64bit JDK
As per Oracle.
To run 64 bit eclipse without change environment variable
Simply copy 64bit jre to your eclipse(64 bit) root folder and rename it as jre.