How to save the testcafe studio run configuration into a JSON - testcafe

Is there a way to save the run configurations into a JSON file?
I maintain the run configuration in a .testcaferc.json file and would like to extract the configuration into a JSON file.

TestCafe Studio stores its settings in JSON, but it uses its own format to store them, including all run configuration settings. You can't migrate settings from one product to another by coping their setting files.

Related

Using Configuration File instead of System Registry

The Portal UI React application makes use of the Registry settings instead of a local settings.json file in order to run the application on the local environment.This is a pain for the developer because everytime a Registry is updated the system needs a restart which is not a advisable kind of approach in this fast moving development world. There is less flexibility and more dependency while using the Registry settings instead of a local json based configuration file.
I propose to move all the configuration files into local json file and checkout the file in the applications repository.
If there is any other approach which would make this easy to use scenario then pls share your thoughts.
Thanks
Iftekhar

How to upload a CSV file in a microservice deployed in cloud foundry

I am new to cloud foundry. I am currently working on a requirement where I have to upload a CSV file (via JSP UI) into a service deployed in cloud foundry and persists its data in service.
The issue is from UI, I only get a local path of that CSV file and when I am trying to parse that CSV via this path the file is not recognized. I guess the reason is service is already deployed in CF, so it does not recognize this local machine path.
Can you please let me know how can I parse this CSV file in local machine and where to parse this CSV.
Thanks in Advance!
There is nothing specific to Cloud Foundry about how you would receive an uploaded file in a web application. Since you mentioned using Java, I would suggest checking out this post.
How to upload files to server using JSP/Servlet?
The only thing you need to keep in mind that's specific to Cloud Foundry is that the filesystem in Cloud Foundry is ephemeral. It behaves like a normal filesystem and you can write files to it, however, the lifetime of the filesystem is equal to the lifetime of your application instance. That means restarts, restages or anything else that would cause the application container to be recreated will destroy the file system.
In short, you can use the file system for caching or temporary files but anything that you want to retain should be stored elsewhere.
https://docs.cloudfoundry.org/devguide/deploy-apps/prepare-to-deploy.html#filesystem

Windows Universal Apps: storing configuration

i come from web development where apps can have multiple config files for storing things like db connection strings, remote server endpoints, passwords and so on
so you have files like base.config, development.config, production.config, local.config and so on
according to the environment the app is running in the correct config file is loaded
is there any such system for Windows Phone and Windows Store apps?
if so, how can i define different configs for diffrent runtimes such as debug and production?
i would really like to avoid storing runtime config in code and then using crazy ifs
There isn't a built-in system for this, but it's pretty easy to mock up. Create and read a file with your config information then create different files for the different configurations. Create a pre-build step which copies the appropriate file for the desired configuration.
I'd probably name the files all the same but put them in different directories named for the $(Configuration) then copy from the $(Configuration) dir in my pre-build.
See Pre-build Event/Post-build Event Command Line Dialog Box on MSDN
There isn't an easy way to switch this at runtime since you can't write to the appx package after it's signed and deployed.

How can I change XSD Path in deployed SSIS Package

I am new to SSIS packages. I have an SSIS package Solution in my local machine.
It has an XML Source component which uses an XSD file in my local machine.
When I deploy this on my SQL Server, How can I set the path to a new location on server ?
Thanks
Create the XSD path using a Configuration variable. In this case, whenever you will change the configuration it will pick the new path accordingly.
I think this guide is what you're looking for:
http://fuzzy-group.blogspot.co.uk/2013/01/ssis-create-dynamic-xsd-source-file-for.html
It allows you to store your xsd in a database where it is configurable, and then loads it dynamically at run time.
I'm not sure exactly how much of an xsd change this can handle, but I think this is the closest you can get without dynamically generating the whole package.

Can someone suggest a better way to use configuration files in multiple environments

I want to standardize and parameterize values across multiple environments and not have to change the dtsx files at any point.
The pattern I am deciding to use is to run all packages from the DTEXEC program and to specify configuration file on the command line and put that all in a batch file. with a different batch file for each environment.
One requirement is the location for the configuration file cannot be in the same physcial drive location, ie all config files are in D:\SSIS\config files. The main reason is that the production machine has an E drive mapped and this is where the ssis packages live and operate from. And, the staging machine does not, and cannot have a drive mapped to E.
Also, we want all files to reside in same pattern across all environments. config files in one place, archive files in another, etc. And, to try to use one medium, meaning the file system is where we store the packages, config files and batch files, as opposed to having data and artifacts in the registry and environment variables.
Does anyone see a more direct approach that satisfies all the conditions?
There may not be one and I thank you for your time...
That's how we're doing it - all config files on the file system, running packages using batch files that call dtexec, and passing config file locations to dtexec via parameters.
Watch out for a possible nasty gotcha, though. As this Books Online article points out, dtexec's behavior regarding command-line configurations changed between SSIS 2005 and SSIS 2008.