I am writing to ask about --disable-features=SameSiteByDefaultCookies feature which was part of chrome earlier.
I am working with IT MNC and recently we promoted very important functionality to Production. We have started charging customer for this. It is legacy application .
This application can't be tested locally anymore! Earlier we could point out application to lower environment with custom settings in project's config.js file and disabling #same-site-by-default-cookies in Chrome and application could be tested locally. But now we can't!
We tried many different settings and debugged but it could not help !!
It is noted that these settings no longer work in Chrome 94+. These flags are removed entirely.
As per my analysis it is found that application still can be tested locally if we get the portable Chrome. Or older version of Chrome installed in our System. However as per the compliance policy of company and client, we can't get old or portable chrome in system. We have latest version only.
Earlier we used to perform following to run it locally:
Open CMD
cd to Chrome path ( Till Application )
Fire the following command:
chrome.exe --disable-web-security --user-data-dir=C:\XXXX\XXXX\localwlp --disable-features=SameSiteByDefaultCookies"
This would open a new window of Chrome ( Close all before firing the command) and then we could test the application locally.
Anybody is aware about the alternative for this? That would be really helpful. We can't test the application locally so for even small changes, we require to deploy on lower environments which takes a lot of time and also code will work or not can't say.
I look forward to hearing from you all guys.
Thanks,
Kailash Nirmal.
I have developed a hybrid framework using a maven project, POM, TestNG, etc. It's running fine now I wanted to copy the entire project from one laptop to another laptop so on first laptop I can continue with my work and second laptop I can use it just to execute the scripts which will same my lot of time.
On daily basis I take backup on OneDrive. I have some questions:
Can anybody guide me how to copy the entire project? Do I need to have the same version of Java and Eclipse on second laptop? Anything else need to be installed?
On a daily basis how do I get the backup data from 'OneDrive' to a second laptop?
This sounds like you want a repository. Use Github, Gitlab, Bitbucket, just.. git in general. That's exactly what this is for.
As for your Java and Eclipse versions, you need to look at your running version of selenium, what packages you are using, etc, and determine for yourself what Java version you should be running. The latest version of the jdk is going to have everything the earlier ones had, so it's usually a safe bet to use the latest stable version. Your Eclipse version should always be the latest as well as it is just an IDE and shouldn't have any impact on how your program runs.
Another option is to use a virtual environment (a virtual-env) and upload that to your git repository, this is a localized version of java present inside the project, that can be carried along with it, although this bloats your repository massively.
Try using git and github and you don't have to take backup and need to work on a specific laptop
I have created a WPF application. I have used the microsoft.sharepoint dll to get some data from lists.
I created a deployment package . When i run the setup i get the following error
unable to install or run the application. The application requires
that assembly Microsoft.HTMLTrans.Interface version 12.0.0.0 be installed first
in the global assembly cache.
I commented the SharePoint method calls and instead accessed sharepoint lists using the Sharepoint web service approach.
It resolved the issue.
I recently inherited a C# Winforms application that communicates with Quickbooks via their QBFC interface. The application contains a reference to the COM Server Interop.QBFC7.dll. The application works fine in our test environment and in several of our client's environments. Although, yesterday when I attempted to install it on a new customer's system I continued to get the following error:
Could Not Load File or Assembly 'Interop.QBFC, Version=8.0.0.87, Culture=neutral, PublicKeyToken=...' or one of its dependencies. The system cannot find the file specified.
I know that we have several customers running this application on various versions of Quickbooks (i.e. Quickbooks Pro, Premier and Enterprise between 2008 and Enterprise 11.0). To my knowledge, this is the first customer that we have attempted to deploy this application that has Enterprise 12.0.
I have attempted the following to resolve the issue with no success:
1) Install the QBFC7_Installer from the Intuit Developer Network Site
2) Install the Quickbooks SDK 10 Installer from the Intuit Developer Network Site
3) Verified that the Interop.QBFC7.dll file is present on the file system.
4) Attempted to manually register the COM object Interop.QBFC7.dll via the command prompt: regsvr32 Interop.QBFC7.dll (This fails as well and windows returns an error stating that it cannot find the object).
Does anyone have any suggestions or feedback about additional things that I can try to resolve this issue? I get the same error on 3 different machines at their site running different operating systems (i.e. Windows Server 2008, Windows 7, and Windows Vista)? I have also tried compiling in both x86 and 64-bit configurations to no avail.
Thanks in advance for any help.
First of all, you should be targeting an x86 build only. The QuickBooks SDK won't work if you target Any CPU or x64. Your main problem, though, is that you are looking for the wrong version of QBFC. Notice the version stamp on your error message:
Could Not Load File or Assembly 'Interop.QBFC, Version=8.0.0.87,
Culture=neutral, PublicKeyToken=...' or one of its dependencies. The
system cannot find the file specified
This is QBFC8, not QBFC7. So you should be able to fix the problem with the QBFC8 installer.
The version of QuickBooks should not make a difference, since QBFC 8 (or 7, for that matter) will work with the 2008 and Enterprise 11 or 12.
You should look into using a setup project to install your application in order to avoid this problem in the future. A setup project should detect the QBFC dependency automatically. Once you see this happening, go to SearchPath property of your setup project and add the MergeModule directory from the SDK that is installed on your machine. Once you do this, you should see that the QBFC and Xerces merge modules are added to your project automatically as dependencies. Of course, you'll also need to update your code to a more recent version of QBFC, but that's probably a good idea in any case.
What's the best way to determine if the version of the JRE installed on a machine is high enough for the application which the user wants to run? Is there a way of doing it using java-only stuff? I'd like the solution to work on Windows/Linux/MacOSX - if the JRE version is too low a message should be displayed. Currently I'm getting an exception if i try to run it on Java 1.5 (the app is built for Java 1.6). If there's no universal solution, what's the best way to do it on Windows?
You could do this using reflection and two compilers. Compile a main class with the oldest java version you want to be able to run at all with. It checks the version using System.getProperty("java.version"), or whatever, and then uses reflection to load your real main class if that check passes, possibly even loading the jar directly. The JRE shouldn't load any classes that weren't referenced by your outer main class at compile time.
You might consider Java Webstart. Even if the name implies something like applets, it's about standalone-applications. Webstart is a launcher, that checks a JNLP-file (a simple XML-file, where you configure the download-location of your app, the needed Java-version and some other metadata) and starts your app with the correct JRE. It even updates the application, if a newer version is available. The downside is, you have to write a JNLP-file. Here is an example:
<?xml version="1.0" encoding="utf-8"?>
<!--
###############################################################################
#
# #(#)draw.jnlp 1.6 02/09/11
#
# JNLP File for Draw Demo Application
#
###############################################################################
-->
<jnlp spec="0.2 1.0"
codebase="http://java.sun.com/javase/technologies/desktop/javawebstart/apps"
href="draw.jnlp">
<information>
<title>Draw 4 App</title>
<vendor>Sun Microsystems, Inc.</vendor>
<homepage href="http://java.sun.com/javase/technologies/desktop/javawebstart/demos.html"/>
<description>A minimalist drawing application along the lines of Illustrator</description>
<description kind="short">Draw Demo Short Description</description>
<icon href="images/draw.jpg"/>
<offline-allowed/>
</information>
<resources>
<j2se version="1.3+" href="http://java.sun.com/products/autodl/j2se"/>
<j2se version="1.3+"/>
<jar href="draw.jar" main="true" download="eager"/>
</resources>
<application-desc main-class="Draw"/>
</jnlp>
A second possibility is to use a launcher-program. An example is the Apache Commons Launcher. You can also write some launcher app yourself, but that's usually not worth the effort.
You might also consider using Commons-Launcher, which allows you to setup various environment settings, or perform pre-checks before calling your application.
http://commons.apache.org/launcher
Generally, we've approached this with a C or (when unix-only) shell wrapper. Not sure this will really work for you.
We also approach this by embedding the JRE in our product. Takes care of 99.9% of the cases (the other 0.1% of the time is a user explicitly changing our configuration to use a different JVM). Again, not sure that this is a reasonable solution for you.
In our case, there is significant amounts of native code (JNI and otherwise), so tailoring an installable image for each platform we support is required anyway. But if you're dealing with a pure-Java solution, you may simply have to document your minimum and tell people to get with the program (no pun intended) if they're to run your stuff. It's sorta like people complaining that my Mac won't run MSVC, or that my Linux box is having problems running World of Warcraft. That's just not the (virtual) machine the software is targeted for - you need to switch. At least in the Java world, we really can call this an upgrade, though, without hurting anyone's OS-religious feelings. (Try telling the Mac user to "upgrade" to Windows XP to run MSVC - there's a beat-down waiting to happen.)
You can require a Java version when running the Java command, e.g. java -version:1.6* com.me.MyClass. Not sure if this works on all releases of Java, but it works OK on 1.6 anyway.
An application built for a higher-version JRE will not run on a lower-version JRE. So you wouldn't be able to just add code to your application to check the JRE version - if the JRE version was incompatible, your JRE-version-checking code would not run in the first place.
What you'd have to do is have some sort of launcher application that is built for a lower-version JRE (1.3?) that checks the version and then launches your app if necessary. This sounds kind of kludgy to me.
What about checking the version during installation? Are you installing the app in a way that allows you to check environment variables, or do any sort of scripting?
For the launcher - Check the version in there.
Inside the APP; as above use System.getProperties();
Properties sProp = java.lang.System.getProperties();
String sVersion = sProp.getProperty("java.version");
sVersion = sVersion.substring(0, 3);
Float f = Float.valueOf(sVersion);
if (f.floatValue() < (float) 1.4) {
System.out.println("Java version too low ....");
System.exit(1);
}
...
Have a launching class compiled for Java 1.2 which invokes the real main() in your 1.6 classes. If an unsupported class exception is thrown them catch it and display a nice error message.
Here is the code to get the JRE version installed in a system.
var list = deployJava.getJREs();
var result = "";
result = list[0];
for (var i=1; i<list.length; i++)
{
result += ", " + list[i];
}
document.write("jre version : "+result);
System.getProperties() gives you a listing of JVM properties including the different version ids of the JRE, JVM and specification. This implemented for all versions of Java so should work regardless of version compiled in and version run in, or the implementation.
If you write a basic class to test the version, you can call this first in your main() launching class. It must really be basic functionality though or you might risk breaking it.
Hmm .. call me a boring guy, but what's wrong with using Launch4J or any other native launcher, for instance.
Use a native launcher to check the JVM version before actually running your code. Java only solutions (in my book) only make sense when you deal with developers; once you hit end-users, you'll realize that they dont care about Java or its technical details at all. If you would have written your application in GW-Basic they would not care less as long as your application works.
If Java 1.6 is not installed, lauchner4j will point the user to the download page for JDK 1.6. Thats probably more suitable for your problem than doing magic in Java.
I find that WinRun4J works quite well for me (but then again I may be biased since I wrote it:-)). This lets you specify a minimum and/or maximum version of java allowed. It will pop up a message box to the user if a suitable JRE version is not found (and the message is customisable).
All those above is too damn complicated.
Just go:
Properties props = System.getProperties()
props.list(System.out)
And you will see everything about your JVM, JRE, JDK and staff.
Or get a specific value by using:
//full list of possible props you can see if u run code above
String props = System.getProperty(prop)