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.
Related
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
An ASP.NET application (running on Windows server/IIS 7) has to transfer big size files uploaded by current user to an external SFTP server. Due to the file size the idea is to do this asynchronously.
The idea is that the ASP.NET application stores the uploaded file on a local directory of the Windows server. The current user can continue his work. A Windows service or a Quartz job (other tools(*)/ideas?) is now responsible to transfer the file to the external SFTP server.
(*) Are there existing tools that listen on changes of a Windows directory and then move the files on a SFTP server (incl. handling communication errors/retries)?
If there is no existing solution, do you have had similar requirements? What do we have to consider? Because the connection to the SFTP server is not very stable we need an optimized error handling with auto retry functionality.
To watch for changes in a local directory in .NET, use
the FileSystemWatcher class.
If you are looking for an out of the box solution, use the keepuptodate command in WinSCP scripting.
A simple example of WinSCP script (e.g. watch.txt):
open sftp://username:password#host/
keepuptodate c:\local_folder_to_watch /remote_folder
exit
Run the script like:
winscp.com /script=watch.txt
Though this works only, if the uploaded files are preserved in the remote folder.
(I'm the author of WinSCP)
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.
I'm writing an Adobe Air HTML app. I want to write to the application storage directory during installation, and thought you could point me in the right direction.
I've got a set of example "profiles" (text files) to include with our application. I would like to put the examples into Application Storage (or Document Storage), since the user is free to delete them, modify them, etc. Also, I don't want to re-write the files during Updates, only an initial installation.
But as far as I can figure out, the installer only writes to the application directory. Is there a simple command line change to ADT to send files to the application storage directory?
Here's my thought so far for a workaround:
Include the files in the application directory "Examples"
On startup, check if the "Examples" folder is in the Application Storage/Document Storage directory
If it doesn't exist, copy app:/Examples folder into the Application Storage/Document storage directory
But it would be a lot easier if this was part of the installer. Let me know if any other information would be helpful. Thanks!
There isn't any way to customize the normal AIR installer. Your workaround is the way to do it.
Is there a way in which I can export my server settings from WAS (running under RAD 6) such that other developers will be able to use the same script to set up their environment?
To do this manually in RAD 6.x, simply right-click the server name in the "Server" view and choose one of:
Export server configuration to server
Import server configuration from server
The choice of wording here is potentially confusing. An import takes a configuration from the already-configured server and imports it into your workspace as a Configuration Archive (.car) file. An export asks for the location of a Configuration Archive (which must be in your workspace) and exports the settings it contains onto your server.
Yes, I agree that this sounds completely backwards.
Fortunately, the names are much more sensible in RAD 7.x. The options are:
Server configuration -> Backup...
Server configuration -> Restore...
These behave just as you'd imagine (Backup creates an archive file and Restore imports settings from an existing archive file.)
Important note: This process will not export service integration buses. However, I have had success including buses with the following steps:
Export a CAR file
Rename to .zip file for easy viewing
Manually copy the following files from your server profile into the archive:
cells/<cell_name>/buses/*
cells/<cell_name>/nodes/<node-name>/servers/server1/sib-engines.xml
Rename the archive back to .car
Note that this process is probably highly dependent on my specific configuration, but seems worth mentioning, since it has saved me a lot of trouble.
Another tip: Any files and folders you place inside the CAR will be dumbly copied into your profile directory whenever restoring a server configuration from that archive. This is convenient, because you can include necessary third-party libraries in the CAR file and reference them via WAS variables relative to your profile directory, resulting in one less thing for developers to download or configure.
You can export and import the profile with all its configuration using AdminTask export and import commands with the wsadmin scripting tool. If you are really serious also at the same time about how you release the applications to production environments you should probably create wsadmin scripts for deploying all your required settings in any case.
Also you might want to consider distributing virtual machines or simply copying the server installation otherwise from a reference installation.